Hacker News Reader

Comment by DHPersonal | Hacker News Reader

I get the point the writer is making: web development is a mess. However, I also think that stepping off that treadmill can make one's impression of the field a bit skewed, because there is no longer an incentive of the writer to keep up with the nuances of the changes. Web frameworks do come and go, but they're also not that different from each other. New ones show up, but that doesn't mean that everyone flocks to them and disrupts everything.

The whole process is definitely still a mess and I am not trying to defend the chaos, but I think it probably appears a lot worse from the outside.

View on HN

I don't know man, I've seen frameworks rise, gain massive adoption and then be abandoned as everyone moves to the next hot thing.

I watched everyone adopt AngularJS and then have to migrated to Angular 2.0 and then everyone migrated to React. During this time, the backend folks wrote java services using SpringBoot and then migrated to SpringBoot and then when that wasn't abandoned, moved to SpringBoot.

Web development feels way too much like a hamster wheel to me.

I'll just pile on my anecdote because I am a backend dev but want to make websites since apparently end users don't like reading and hand-composing JSON or something.

A while ago, a few years I think, I learned react with class components. Hooks were never mentioned, so I don't know if they didn't exist yet or were in some nascent stage. I thought "huh neat this makes writing js not completely awful" - my only "frontend"-related background was in desktop UI development with Swing and Qt and such. As I mentioned, I'm mostly a backend dev.

Anyway, I wrote a small internal app for my job at the time and shipped it and it was neat, all the other backend devs (we had ~no frontend devs) were suitably impressed with how much less awful react was than vanilla JS.

Fast forward... I suspect 3-ish years. Suddenly hooks were popular and class components were not and people were being pushed to migrate (since newer versions of libraries were preferring hooks). My hard-won frontend knowledge is already outdated! And imagine my surprise when I learned SSR was back?? and something about next.js which I guess is still react but it's a server packaging of it as well and that bleeds over into letting you do more stuff on the frontend, something about server-side props? I was disappointed with how much had changed despite the actual product - the websites you can build - still essentially staying the same.

And this is just for React - the winner! I had managed to correctly pick the winner and there's still all this churn. Meanwhile, as you mentioned, rails is still almost exactly the same (all its churn has been trying to pick a not-awful way to integrate javascript, ironically) despite several major versions passing, Spring is the same, etc.

I completely agree with what you've said.

All I want to add is that today React is the winner, last week, backbone/ember was, week before that it was angular.

Even winners are transient and ephemeral.

It doesn't help that a lot of websites / apps have this tendency to "need" a redesign / rebranding every 5-10 years, which developers take as an opportunity to use the next great framework because the old app is an unmaintainable mess.

If anything, new frameworks should be simple to use.

I've had the misfortune to work in an Angular codebase last year, I could hardly make heads or tails from it; I'm sure there's good theory behind it, but it was far too complicated.

Currently working in React, and it's got the annoyances of hooks, callbacks, effects, etc; basically, you as a developer are responsible for a lot of rendering behaviour, using what looks like magic trickery. Don't get me wrong, I like the basics of React, but as soon as it goes beyond simple props it's starting to lose me. I heard Vue solved this better or more intuitively, but it's still a layer on top of JS/HTML.

In parallel I've been working in Go, and while it's wordy and frequently annoying (like when using the correct design patterns, you'll end up copying a database struct to a business logic struct to a HTTP API struct, it's boring, wordy and bug prone code), it's still much more of a joy to work in because there's very little indirection or friction.

Meanwhile Ember has quietly improved and reinvented itself steadily over the last decade-plus, while maintaining compatibility responsibly the entire time. Sure it’s not always been on the cutting-edge (which I guess is why it lost its cachet) but its relative stability through fundamental reworking of its core have enabled me to happily maintain multiple SPAs that I started with as far back as 2015 when everyone was adopting AngularJS.

All this is to say that there are projects and communities that value stability with stagnating so you can still have “nice things” without feeling stuck on a hamster wheel.

Most ironically, Ember's mascot is in fact a Hamster (well, a Tomster). :-)

I started around 2009, and while I certainly felt overwhelmed at several points during the framework craze, I never got tired of it because it was exciting. As soon as I started hearing about hydration though, that was my breaking point. I'm just tired of it all.

That being said, I do love Astro. It's a very nice, easy experience.

And now from client side rendering (CSR) back to server side rendering (SSR). The thing, that we done 20 years ago, but now only more complicated, with more tools, more setups, etc.

I feel like I stepped off frontend the treadmill and haven’t been able to catch up with frontend. React, Angular, Vue, Next, Nuxt, Svelte, Typsecript, Tailwind, Bundlers.

It feels like a mountain to climb to get my head around that lot!

I don’t really understand why people seem to decouple learning from doing. Isn’t it possible to only learn what you need when you need it? It’s not like you even have to learn an entire framework/etc each time you run into a new one, just learn the specific part you need at that time. What am I missing?

This mentality is what leads to paint drip shaped people. It's a very good practice in my experience. Go just as deep as you need to solve the problem.

https://flowchainsensei.wordpress.com/2021/07/28/kent-becks-...

But until you don't know something, you can't use it and, most importantly, you can't understand that you need it.

Like, how can you understand the tradeoffs between react, svelte or vanilla js until you have a basic knowledge of them?

If you're a front-end developer, it shouldn't take long to research the differences between modern front end frameworks. If you don't have any existing front-end skills, you won't have the ability to know what to dive into. True beginners need a solid foundation to build on, but once you have that foundation you should be able to adapt it to new and changing technology very easily. Once you have the foundation, you can dive as deep as you need into specific specialties and jump back out quite easily.

Learning your first programming language is hard. There's a lot of details and idiosyncrasies. The second is a bit easier because you have a base of experience to reference it against. By the time you're picking up your sixth language or front end framework or node API framework, you should be able to much more quickly assimilate the details because you've got so much more experience to draw on.

Most of those are just rehashing of already discovered ideas. It is not like they have much of a secret sauce. Just put some concepts together. If you are a good developer, you can understand what they do in no time. But that makes it even more annoying to see the hype around something that is nothing special. Add to that a mountain of silly configurations and limitations due to design decisions, and you get a "modern" web stack. Take for example "tree shaking". I remember how there was a hype around it. Every second day I would see some post about tree shaking or read some blog or whatever, where people point out tree shaking. Tree shaking! Tree shaking here! tree shaking there! Most of them never stopped and thought about how they shouldn't need to be shaking, but instead should avoid putting that much shakable shit into their trees in the first place.

It almost seems like people are getting off on the fact, that they manage configuration complexity in web projects, as if that makes them somehow qualified. Instead they should be saying:

Wait a minute, why am I configuring all this shit? Why is my web app so big, that using a minifier makes any significant difference? Does my web app really do that much? Couldn't I get by with just rendering templates and add a tiny amount of JS?

But people do not ask and continue riding the hype train and it even makes them more in demand, because way too many people think they need this.

Reply on news.ycombinator.com