←back to thread

873 points belter | 4 comments | | HN request time: 0.001s | source
Show context
dtquad ◴[] No.42948592[source]
>Frontend development is a nightmare world of Kafkaesque awfulness I no longer enjoy

As a backend/systems engineer I recently had to look at a React + Typescript + MobX app from 2019/2020. It is true that that some things, especially the webpack config and Typescript loading, were outdated but the overall design and architecture of the app was still understandable and modern. With some help from ChatGPT it took very little time to migrate to Vite and update dependencies. By 2019/2020 React Hooks had already been out for some time but there were still some class components in the app. They were easily migrated to functional components + Hooks using ChatGPT.

replies(9): >>42948755 #>>42949267 #>>42949480 #>>42949689 #>>42951645 #>>42952358 #>>42953864 #>>42954167 #>>42960182 #
phailhaus ◴[] No.42949480[source]
Yeah I wonder if his experience is mostly using JavaScript, which is absolutely impossible to maintain at scale. Most of my team comes from primarily backend-dev roles and they've all grown to love TypeScript over Python.
replies(2): >>42949690 #>>42951196 #
zelphirkalt ◴[] No.42951196[source]
I have done frontend as well as backend and moved to backend only, because the endless hype traing jumping, cv driven development and config and library churn was just too much of a comedy. And it is still happening. Now it is people switching "routers" and version upgrades for nodejs and version upgrades for typescript and deployment platform and ... The list goes on.

This kind of thing is much much less pronounced in the Python ecosystem, but also existent, while many packages are written based on bad conceptual foundations, just like many (majority?) of NPM modules are.

replies(1): >>42954624 #
1. phist_mcgee ◴[] No.42954624{3}[source]
You don't have to follow hype when doing frontend, you can pick whichever technologies you want and stick with them for years.

Part of being a good frontend lead is personally is not falling for the hype, and only adding packages I know will a. be supported for the foreseeable future, b. have an exit plan if those technologies aren't supported, and c. keep an eye on my juniors/seniors to make sure they're writing sensible long-term code.

The gnashing of teeth over the "upgrade cycle" I think speaks to poor team planning/leadership than it does for the actual tech now.

replies(1): >>42956402 #
2. zelphirkalt ◴[] No.42956402[source]
Yeah, you don't have to follow the hype, unless of course you got coworkers blinded by the hype and managers, who do not know how to discern who actually knows something and who is just jumping on bandwagons. Suddenly you will seem like the backwards guy, who does not want to learn the new shiny thing. Then suddenly you do have to follow the hype, even though you warned them.

As a full stack developer, your chances of being or becoming the frontend lead are reduced, as you don't have focus like a frontend only person, who will play that card subtly, that they are the specialist and you are not. And frankly, as a full stack developer, why would I even want to become a frontend lead and sacrifice the part of development, that is much saner? For the frontend lead it also pays well to follow the hype, raise the frontend to "modern level" and get paid senior salary.

replies(1): >>42958607 #
3. phist_mcgee ◴[] No.42958607[source]
>why would I even want to become a frontend lead and sacrifice the part of development, that is much saner

That's your choice, but myself personally, I like the deep focus on one thing along with guiding my team. I think we perform at a pretty high level and we are a happy productive team by all reports.

Our frontend is sane and that was because I was given the scope to make it sane. Others will have different experiences, and I agree that full-stack would have less sane by default, due to the lack of time or care for it.

replies(1): >>42960849 #
4. zelphirkalt ◴[] No.42960849{3}[source]
What I am pointing out is, that one might have an idea how to build a FE in a sane way, but as soon as it becomes a team decision and people don't trust your experience or knowledge, then it often quickly becomes a game of who can represent the next modern hyped thing best, repeating the arguments heard elsewhere, rather than staying with a maintainable solution. If later they need to hire 2 more FE only roles, just in order to maintain the thing they built, they will still not see how silly the decision was and think, that this must be so. Work that could be done by a single person in a few months turns into work done by 3 people working FE only, just to maintain the thing built with the next hyped framework, while all they needed was static content rendering, with tiny sprinkles of JS for some dynamic check boxes.

Besides that, people tend to jump to the extremes in FE. Want some component (in terms of React component)? Immediately they think the whole site(!) has to be a whole React FE, because they like using sledgehammers. Most people don't even think about serving dynamic widgets only on the very few pages/parts of a platform, where they are needed, using frameworks which have this capability for many years now (for example VueJS), and keep the rest of the entirely static website just that. Static. Workable on by any capable software developer or engineer. No. They must build themselves a FE moat! Make things ever more complex, to justify their roles. When you step back and look at what their site actually does, it is extremely laughable, how much time it took to get there and how much time still goes into it, maintaining it.

The examples I wrote about earlier are not just imagined. I have personally witnessed multiple FE people taking 3 weeks to switch out an app router for a pages router (or other way around) in a nextjs project. This is a problem entirely of their own making. 3 weeks for 3 people, that is 9 work weeks. Someone please transfer 2 months of salary onto my account!

I know how to make completely responsive and well accessible websites, more responsive than 99% of websites that call themselves responsive. More responsive than what most FE people cook up with their JS frameworks and non-standard component systems. That is because I care when I build things and I inform myself about how to do things in standard conform ways and use HTML in the way its elements are meant to be semantically used. I have done FE stuff before. In 20 years my site will probably still work just the same, and it will be simple to maintain, because it uses standard HTML and CSS. Meanwhile their frameworks will be long abandoned for the next shiny thing by then. They will rebuild and rebuild and churn and churn.

Still, managements will rather trust a FE(only) dev to build a convoluted mess, because they label it as "modern" and want to jump on the hype trains. FE devs are often like drug dealers figuratively speaking. The incentives are just like that. The more complex a thing they build, the safer their job. Same is true for backend btw. There are lots of grifter out there.