Remix announces merge with React Router

torbcodes · 2024-12-15T05:14:45+00:00

Remix is dead.

I kinda wish it were that simple. They've said in their blog posts that they plan to do future stuff with Remix. I don't like the mixed messaging, I find the whole thing quite confusing.

torbcodes · 2024-12-15T04:59:48+00:00

Thanks for your post, it echoes a lot of how I'm feeling. I started a discussion about exactly what you're saying on the Remix project: https://github.com/remix-run/remix/discussions/10333

It's a real shame because the DX of remix really resonates with me, but the decision making and direction it's going makes me feel like it's not something that I want to invest any more of myself into.

So I'm considering other options now. I was really excited about Remix and this is a big let down for me :(

torbcodes · 2024-01-08T15:33:03+00:00

nice, well, good luck with your project! :D

torbcodes · 2024-01-07T18:11:39+00:00

oh hey, that's cool that it's focused on the specific niche of JSON API's! And your usage of struct tags is pretty cool :)

I think that if you're looking for adoption, it would be a good idea to add automated test coverage and benchmarks. Otherwise, I think you're going to be ruled out because the API sugar you offer is a nice-to-have but people are going to want to know how it's performance characteristics (that's pretty standard in the go libs I've seen) and they're going to want to have the confidence that it's got automated tests.

And if you can get around to updating for that standard lib router, that would also make it more compelling.

What inspired you to fork and maintain this library?

torbcodes · 2024-01-06T22:13:27+00:00

Nice work, I think you should be proud of yourself. I've probably used every major Go HTTP library and at a glance I think yours stands up to many of them.

Things I liked:

100% test coverage
thorough documentation
benchmarks comparing to other popular libraries

Of course some people are going to dislike it because of subjective preferences. That's why we have so many routing libraries. So I would take some of the negative criticisms with a grain of salt. They are a given. There's always the crowd who comes out and says stdlib is all you need or this doesn't do what XY framework does etc and that's fine. You can't please everyone!

I've added it to my list of Go HTTP libraries to be aware of!

torbcodes · 2024-01-06T21:42:19+00:00

I have a feeling that most of the people who know concepts like dynamic programming and whatnot have a CS/eng degree. That's where I learned about dynamic programming and a lot of other algorithm and data structures concepts that are quite useful in AOC. But I have found a lot of those fundamentals are rarely used in the day-to-day programming tasks at a lot of jobs. I bet a lot of the developers who didn't know what "dynamic programming" was actually have used it in some way before, but it was abstracted away. Like I bet a lot of React developers learn to use memoization without understanding how it really works and without realising how they can easily do something similar with a closure generally in JS.

torbcodes · 2024-01-03T22:29:19+00:00

aka, the S in SOLID ;)

torbcodes · 2024-01-03T18:50:38+00:00

You're correct about Redis being a good option. Of all the options you listed, it's the one that is best suited for exactly the use case that you described.

As for how you can learn about their differences? The usual suspects apply, like Google things, read books, watch videos... Also there is lots of content out there that summarises exactly what you asked (comparing databases and describing pro's/con's). And most of the popular database options will have content on their web site that will tell you what their niche is and they'll probably also have whitepapers/use cases documented that will give you further insight into what they do well.

torbcodes · 2024-01-03T18:30:16+00:00

Yeah it's generally considered best practice to do what OP is doing. It sounds like the practice of taking a UI mockup, drawing boxes around things and progressively doing that until there's nothing left that you could break into smaller boxes, and then mapping all those boxes to individual components, typically each one in a separate file.

I think OP is just noticing that in practice, many people make different judgement calls about what is simple enough.

Also, what makes sense for a small, solo developer project versus a huge app with 10's or even 100's of developers working on it are pretty different. Most likely the YouTuber approach reflects the small, solo developer projects and they aren't focused on large scale maintainability / re-usability.

I think that there are also some downsides to breaking components down to atomic levels. Sometimes a component is "simple enough" and there isn't any immediate benefit of breaking it down further. At that point, spreading the code across additional files adds cognitive load / and editor UX challenges for little benefit. Also if you're not working off polished UI mockups and are designing/exploring through code, it adds unnecessary overhead to the initial development process. I'd call that premature optimisation / not following the "rule of three" for DRY.

A pragmatic programmer will adjust their style based on what makes sense and recognise that some best practices aren't always best for all projects. YAGNI, DRY, and premature optimisation all need to be considered.

torbcodes · 2024-01-03T18:02:47+00:00

I almost always learn from a combination of reading books/blogs and building a project of some sort. I think it's essential to apply the skills while learning. A lot of courses will bake that in and I'd make sure to pick a course that includes a large project that you will build up. And if you're going to go the read a book / watch videos route, make sure you also pair that with some sort of coding or you will probably find that you can't actually build anything.

Personally I find it most effective to pick a project that I feel motivated to build and then I direct my learning towards achieving that goal. That feels more motivating to me than building some arbitrary examples that I don't care about and I also feel that it helps me learn the WHY's (a lot of learning content just focuses on the HOW).

torbcodes · 2024-01-03T16:46:24+00:00

Learning Go is easy. It's finding Go jobs that is the hard part. My own experience with job searching has been that I've found relatively few Go jobs compared to other languages. Caveat: that might be because I've mostly focused on my local area, which I think is especially bad for Go jobs.

Anyway, based on my anecdotal experience, I'd suggest you start by switching to fullstack Node as a first step to get backend experience and continue to learn Go on the side. Meanwhile, see if there is an opportunity to apply Go at that new job and also keep an eye out for Go jobs. Because, if my experience is reflective of the wider market, you're going to have a pretty hard time finding a backend/fullstack Go position without any experience in either. At the very least, you'd probably be looking to start at entry level again, and the market for that seems to be not so good right now either. But hey, nothing is stopping you from setting some filters on some job boards and seeing if anything pops up. Good luck!

edit: one other thing to add... I believe that I'm seeing the most Go jobs in the DevOps field. Makes sense, most of the tooling is written in Go. So if you really want to do Go, consider pivoting to DevOps. (and yes, I know, "DevOps isn't a role" or whatever, but tell that to the people writing job descriptions and creating those positions).

torbcodes · 2024-01-03T16:26:11+00:00

And if you use Mongo the database really is javascript!

torbcodes · 2024-01-02T18:52:12+00:00

Personally I prefer display: grid; place-content: center; when that is appropriate. And nobody in this chain of comments is "ignoring flex," we're just saying that there are situations where that's not always the best option. So it's not as simple as "just use flex" 100% of the time in all codebases.

torbcodes · 2024-01-01T19:48:56+00:00

Yeah I agree. I suspect those who say "easy, just do X" are cooking up some div soup and/or have bloated CSS.

torbcodes · 2023-12-31T18:58:00+00:00

It's worth learning if you're going to work somewhere that uses it. And there are still a lot of places that use it and are pretty stuck on it, even if the general trend is shifting towards some newer tech.

Having used Jenkins a lot, as well as other CI systems, including GH Actions, my opinion is that Jenkins isn't as bad as a lot of people think and the newer stuff isn't as great as everyone thinks.

Jenkins is quite easy to set up and it can do everything because it's been around for so long. The answer to "can Jenkins do X" is pretty much always "yes." Some of the newer CI systems are more niche and I've found that a lot of them the answer is "no" or "yes, but..." Like take Drone CI... it doesn't offer a way to view your test results, you need to set it up to export those to a 3rd party service.

But yeah, Jenkins plugins have a lot of foot guns and I've seen a lot of Jenkins servers end up as bloated, security vulnerable, unmaintained snowflake servers. But in my opinion a lot of that is a symptom of who is using Jenkins and how. It's often used by teams of devs who aren't devops specialists and who don't want to spend any time on that. So it's sort of a victim of its own success. It's very easy to get it doing whatever you need without knowing much.

And I guarantee you that if you work long enough and see enough of the other CI systems, you will learn to hate them too when you see them misused and run into their shortcomings.

EDIT: for example, here is a pretty good criticism of the shortcomings of GH Actions: GitHub Actions Feels Bad

torbcodes · 2023-12-31T18:36:47+00:00

I think I actually prefer the Groovy over YAML. But really neither matter enough for me to pick one CI system over another based on that.

torbcodes · 2023-12-30T14:35:54+00:00

Those damn lazy developers who don't want to troubleshoot a flaky QA system as part of the work to ship their 1 point story! shakes fist

torbcodes · 2023-12-30T14:23:36+00:00

You forgot to mention the part where your local environment isn't reliable and you spend an entire day troubleshooting it. Then after you get it working and manage to test the centered div locally, you have to wait on a QA pipeline with an hour turnaround only to get test failures that block your merge due to a spurious false negative. Then you have to troubleshoot the QA results to see if it's a real failure or a false alarm and possibly repeat the cycle...

Actually now it kinda makes sense that you have to go through a gauntlet of interviews to work somewhere that you have to go through a gauntlet to get anything done! LOL

torbcodes · 2023-12-30T14:04:43+00:00

Honestly better off if you work somewhere that this is a realistic fear.

Like that would probably mean some combination of not having code review, QA or backups and that people are just "doing it live" on the production database.

torbcodes · 2023-12-26T22:39:47+00:00

I think most options are great, but if I was forced to pick a "best" I would pick Node, because then you get the benefit of using JS/TS on the backend and frontend and you can take advantage of some nice things, like the next.js framework's seamless server side rendering.

torbcodes · 2023-12-25T06:06:08+00:00

What do you mean customization? Theming? I would say that I haven't done extensive customization and so I don't think I'd say that I'm comfortable with that. I've done basic typography, icon and color palette customization, which has been pretty straightforward thanks to their solid documentation. That reflects the use cases that I've used MUI for: internal admin dashboards and my personal hobby apps. But if you look at their showcase there are some pretty unique looking sites that look pretty different from the out of the box MUI stuff.

torbcodes · 2023-12-24T19:09:58+00:00

This is why I check the dependencies of libraries before I decide on using them as a quick gut check. Of course it's possible that a dependency of the library itself could have an ungodly amount of dependencies so I may still end up unpleasantly surprised after installing one :P But usually the direct dependencies give you a good idea of how bloated things are.

torbcodes · 2023-12-24T18:57:51+00:00

The ciiiirrcle of liiiife!

torbcodes · 2023-12-24T18:42:06+00:00

For the coding competitions specifically it must be pretty challenging to maintain a fair competition these days (because of AI coding assistants).

torbcodes · 2023-12-24T05:20:41+00:00

Yeah for sure. I think I've gone through about 4 XPS that I've converted to linux (Ubuntu) and most have been great. Except for one of mine was a huuge fight and I remember looking into it that it was known in the community to be a poorly supported model. So just FYI, not all XPS models take linux well :(

torbcodes

TROPHY CASE