Hacker News Reader

I suspect the cultural issues with JS primarily boil down to the fact that every org needs JS, which in turn results in 1) a glut of junior/mid devs and 2) it naturally being ground zero for hype cycles. At this point I honestly wonder if most orgs should even hire for JS skills, or if they would be better served by hiring backend engineers and training them to write progressively enhanced UIs.

It depends on what you want to build. If you want to build impressive B2C software, this sounds like a recipe for disaster. I've worked with many backend engineers masquerading as full stack engineers who couldn't carbon copy a simple mockup design into a working UI if their life depended on it. Yet they never seem to notice how bad their implementation is, sometimes not even if you point it out to them even if the end users would notice; I think these engs are so enamored with their work they're in some kind of denial about the shortcomings. And that's just the visual parts. There's also skill required to take accessibility and conformance with web standards into account (HTML/CSS/JS stack is devious in that it lets you do things in ways that are "wrong"), which you can't easily fix later on by tweaking a bit here and there. So without this understanding, you end up with a crappy UI that's overengineered for what it is. Of course that all won't be an issue if you're building software you can sell even if the UI makes its users depressed.

Not saying your typical frontend engineer is flawless either. It's probably true that they're, on average, not as skilled sw architects as backend engineers, simply because a lot of their work focuses on details instead of architecting, and, again, the HTML/CSS/JS stack is incredibly flexible, in good and bad.

It's fair to point out that there is real skill involved in that kind of work. However, I don't trust the average "frontend developer" to do pixel perfect implementations either. Many of them don't even seem to know CSS anymore. And not to discount your experience, but being able to implement a design is something that is easily testable when evaluating candidates. Because I come from the multimedia agency world, most of the candidates I've hired were actually for that kind of role. Accidentally hiring people who can't do the work points to a competency issue with management. As I've pointed out elsewhere, I have the awards to speak authoritatively on this. But perhaps me focusing on average skill is just an unfair way to look it, since I'm never really looking for average anyways.

The thing is brilliant UI engineers will stun you with incredible UI. It's almost like not investing in AI, you will get blind sided by products that just look and feel better. Your backend engineers are never going to cut it. This is true for backend engineers too, if you try half ass it with "full stack" devs, brilliant backend devs will stun you with things and your products will be inferior.

For example, we all got stunned by the machine learning people. We have to pay attention to everyone.

backend and frontend engineers aren't as distinct from each other as they are from ML or something like embedded development. It is very normal to be able to build a web interface end-to-end, and frankly something I expect of every competent developer in that space. Someone who is a high-performing frontend engineer should also be able to perform at a high level in backend, and vice-versa. I'm talking about the industry as a whole though, and specifically that I wouldn't trust the average "frontend developer" to be making wise engineering decisions. Saying this coming from a background of working with designers on webby award winning projects and having a high degree of respect for the platform.

I totally get your point. I'll just give you a little color about where I'm coming from. Most products don't need a team of over five frontend/backend devs (so imagine a team of 10 people). Most teams have been over staffed. When you are overstaffed, that's when everyone needs to be cookie cutter with cookie cutter expectations (e.g backend should do ui, frontend should backend). On non-overstaffed teams, the core group compliments each other very well and brings extreme expertise. No one on such a team ever goes "I can do what that guy does", because it's not a run of the mill mass market team.

I think in the age of AI we'll see more concentrated teams since everyone can hit up AI and do anything. It's going to be very important to build tight teams, and I don't think it's going to happen by continuing our factory farm level recruitment.

That's an interesting point about team composition. Companies originally split frontend from backend to scale up the number of developers they could put on projects. The idea was that each system could be a black box to the other team, and you may only need one person that understands it all end-to-end. The problem was that by splitting monoliths into multiple services they basically lost most of the advancements the industry had made to increase developer velocity. If your org was trending towards hyperscale, then you would have been transitioning to a multi-service architecture anyways, but for everyone else the move to SPAs resulted in a massive loss of productivity.

Listen, how impactful LLMs will be largely depends on the type of code teams are writing. If you're already building in a highly declarative manner, where your libraries are automatically handling most of the glue for you, then you may not have much of a need for writing code more quickly. These are the teams that are actually fast. Teams that already spend a bunch of time writing glue code will likely see significant improvements in velocity, because LLMs are good at regurgitating existing patterns. What they probably won't do is refactor your project so that your team starts operating on the level of the formerly described one.

I've also experienced the other end. As a pithy saying goes, "it takes a lot of skill to write Java in every language."

Maybe hire BE devs and use htmx.

Doesn't help. I just cannot center that div or make it look pretty.

> Which somehow affects Go library developers stance on compaitbility and breaking things. The code written 10 years ago perfectly compiles and work on latest Go version, and it's such a wonderful experience.

I'm assuming you mean against go stdlib? Because sure as hell that's not my experience upgrading random go dependencies. Mostly use go in the Kubernetes/cloud ecosystem and upgrading the dependencies is an extremely painful exercise as most libraries seem to keep renaming and shuffling their APIs.

I think that culture will happen somewhere anyway, and FE being the battle ground is probably because it's the most visible part of the experience.

I mean: some people will want to reinvent the wheel, and preferably carve their name in some monument while doing so. And there will also always be an impulse to create busywork as it's the tide that rises all the boats, inflating the workforce in the field.

The staggering costs of breaking APIs is to some a feature, not a bug, and the field will attract more and more like-minded people who then accelerate that trend.

To note, BtoB focused startups usually go for a completely different FE stacks, including long deprecated ones, or even plain staticly generated sites wherever they can get away with it.

> But this culture of "breaking package is fine" creeps in into Dart ecosystem as well, and it's annoying as hell.

It’s almost like this has nothing to do with technology and is more result of a barrier of entry that is one step about nocode solution.

What are you talking about? Websites from ten or twenty years ago are still working. If there's one technology with good backwards compatibility, then it's JavaScript.

Definitely not talking about vanilla js.