Hacker News Reader

Comment by WD-42 | Hacker News Reader

Many others including myself have made this observation. I think I've finally formulated why there seems to be such a stark difference between FE and BE/systems cultures.

The backend and systems programmers are still writing code in a programming language.

So much of FE dev now is stringing together other people's declarative frameworks. When programming is done it's mostly glue. So if you exist in this paradigm you're going to have very strong opinions about whatever framework/tech you are using because it's so hard to operate outside of it. You also gain a vested interest in the survival of whatever you've chosen.

This is why I've been slowly trying to make the transition out of web dev, at least FE. I don't want to deal with this crap anymore!

View on HN

Webdev is a different culture for sure. I think it brings a lot of newer devs in, which is fine, but then their lack of experience makes them vulnerable to groupthink, choosing easy over simple, demagoguery ("it's different this time!" seems true if you don't have prior experience) and needing to jump to the newest flashy thing. I'd also argue that this shift implicitly devalues the actual building of things (which is hard to assess and requires expertise) in favor of social clout (which is easy to assess), but this could just be coincidental with the rise of social media. Regardless, there is brand-building you can do and people routinely conflate social clout with technological prowess.

I gave up on webdev when this started to set in. Honestly, it felt like a bunch of kids chasing thoughtful engineering out by simply making more noise. Everyone wanted a magic library that relieved them of thinking, but the only way to make decent software is to think deeply about what data flows where, and how it gets there.

I've since rekindled an interest in it after finding some tech that did click with me: Quarkus + Renarde, htmx, Svelte. All of these are off the beaten path and have users that choose to use them, versus those that have to do, and I really think it makes a difference.

> This is why I've been slowly trying to make the transition out of web dev, at least FE.

Systems/backend dev is a lot more friendly to thoughtful engineering IMO. Check out Java, Golang, and Rust and see what libraries/users you click best with.

Pretty cool, I hadn't heard of Renarde and it looks promising. Around 8 years ago, I really wanted Aurelia to win the SPA wars but they're still pretty niche even though they've been growing lately. But honestly, after playing with everything over all these years, I still believe a server-side framework with minimal amounts of JS is ideal for most projects, especially all those internal corporate web apps but also for B2B stuff and even the average consumer-facing app. People say consumers are more demanding now, but how many developers are really working on something that caters to the most demanding consumers? Unless you need the most snazzy UX ever, just don't.

And honestly, using Rails or other server-side frameworks, you can get very far with way less effort than those expensive front-end teams by simply using Hotwire:

https://hotwired.dev

Sending down rendered HTML using Hotwire Turbo requires far less time, and HTML over the wire is in reality no heavier than sending down JSON. If you absolutely need a bit more interactivity on the front-end while avoiding a server roundtrip, it's easy to drop in little Stimulus JS controllers as-needed. From my journeys to and fro in the real world, I've seen most projects do not need more than that, and are arguably wasting budget trying to use heavier tools than that! For most sizeable projects, you can do more in Rails & Hotwire with fewer developers than a 6-person team using their favorite server side language and React. I'm not saying you have to use Ruby on Rails. I'm saying I wish the dev world would embrace this paradigm in whatever their favorite language/frameworks are.

Beware that backend has plenty of those declarative frameworks also... Kubernetes, terraform, most CI environments, CMake. (I'd add SQL but since it's the only one that doesn't drive me crazy, I don't like to think of it as declarative)

I don't know FE development enough to speak on it but I agree with your sentiment in general. When I see "declarative," I think "learn by memorization and trial and error rather than reason and intuition."

> Beware that backend has plenty of those declarative frameworks also

Thankfully, they don't take over your application code, though they eat a considerable amount of brainspace, especially in the collective discourse.

Discretion and focus remain key skills in tech these days.

I don't know, I'm a backend programmer myself (although I dabble in front-end, and indeed, don't love it), but "the frontend programmers aren't really writing code in a real programming language" claim just sounds like an old greybeard writing in assembley complaining about how programmers that don't know and write in assembley are lazy and don't really know how to program. Iterate and repeat with every new development technology.

Don't get me wrong, the front-end certainly seems like a mess to me too. Although I think it's actually not quite as bad as it used to be, maybe over the hump one can hope.

Backend code lives together better too. It's trivial for me to set up a frontend web server that points one URL to a handler in Python, another in Go, another in Java, and whatever else I like. Said frontend can also do a lot of useful abstraction over things like login and authentication, and even to a limited extent authorization. Backend does not compose perfectly but it composes together reasonably well. This architecture may be problematic for other reasons, but it isn't intrinsically a huge problem right out of the gate.

Frontend, you largely have to pick a team. Trying to run multiple frontends in the same page has a number of problems, if nothing other than each of them gets so large that even just one can impact performance, but they will also fight over events, and you can't cross the streams, etc. The whole structure is more winner-take-all, by its nature.

Ah, this makes a lot of sense to me. Thank you.

Interestingly, I think this problem exists in areas of back-end work. I know people who mostly do systems integration, where they're customizing some enterprise behemoth. But since that world is anchored both by the big vendors and by your company's choices of them, it seems saner to me. People may identify as a SAP developer or whatever, but they don't have to advocate for it or have a quasi-religious belief in it.

Backend, the land of no frameworks. Not a Rails, Django, Spring, or Laravel in sight!

I see BE coding more and more in configuration files nowadays YMMV.

Reply on news.ycombinator.com