Software development topics I've changed my mind on

>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.

it's the best comment in the entire post IMHO and made me LOL

With ChatGPT I am enjoying Typescript development and learning a lot. Unfortunately with ChatGPT being - in JavaScript terms - decades behind the state of the art. It becomes a little challenging to get it to do what you want. But it gets me 80-90% of the way there 70% of the time. Which is a huge win.

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.

5-10 years ago I was just skipping Webpack and Babel, and raw-dogging React.createElement in personal projects in order to be happy and maintain sanity. At work I would just push hard for alternatives like Parcel or Brunch.

Now, with Vite I just don't mind the toolchain anymore, it just helps me instead of getting in the way. Similar to Go.

All the problems I have now are of my own creation.

Both of his blogs mention Java at least once. It's a good bet this factors heavily in his day to day.

I know what you meant, but that phrasing reminds me of the gag from Anchorman, "60% of the time, it works every time."

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.

I'll be the Steve Ballmer saying "I love JavaScript" but man it is great, I have made so many apps in different forms: web, deskop, mobile. If I needed to I can go into XCode and work on Swift. I have stuck with one stack though just ReactJS/NodeJS/ReactNative/ElectronJS or PWA. I prefer including SASS styles.

I still think TS is annoying to work with but I'm coming around since I have to use it at work and libraries like React Native are using it by default. Swift/C++ has typing but yeah, I like plain JS for speed development and typing can get annoying especially for a personal app.

dumb question from someone re-entering the FE world: why is Vite necessary?

My understanding is it basically strips the type information using Go (IIRC) where your typechecking is then a separate step (without transpilation). So feedback is more rapid.

But, with tools like Deno or ts-node, where the type checking is apparently also off the hot path, why does Vite still exist?

Is it because it connects file monitoring with a dev server? Because it also somehow works non-js artifacts like CSS and image imports?

Ultimately, I've found the world of Vite + ESNext imports to be a world of frustration and pain. And, I really want to like Deno, and a lot of it is magical, but ultimately, there's just some splitbrain stuff going on with Deno's concept of a monorepo and their inability to commit to their public projects (e.g. Fresh) leaves me concerned it's risky to build on top of.

(ok, that turned into a rant, but there are some questions in there.)

If there is anyone here who has time to explain to me (or link articles about) why functional components and hooks are considered to be better than class components, please enlighten me.

Up until roughly 4-5 years ago I was doing small front-end React apps on the side (I'm a backend engineer) and was feeling very productive with class components. They made sense to me, concerns were nicely separated, and I felt I could reason pretty well about what was called when and how state was manipulated.

Then hooks came around, I tried them a few times, but I just felt so lost. Suddenly everything is intermingled in one function and we're using side effects to react to changes and manipulate state. I could no longer understand when which code was executed, and especially following and manipulating state became impossible for me.

The projects I already, I kept with class components. Haven't done any new front-end projects since then.

I'm glad I'm not alone in that sentiment. I haven't touched react since the move to hooks. People seem to like them though?

I only knew React until my current job, which uses Vue. I'd strongly recommend trying a framework other than React for your next project. After you're past the learning curve, it's much more intuitive.

> Is it because it connects file monitoring with a dev server? Because it also somehow works non-js artifacts like CSS and image imports?

Yes and yes. Also some pre-processing such as compiling JSX into JS.

> I'd strongly recommend trying a framework other than React for your next project.

This gave me a good chuckle (if you read it as next.js)

> If there is anyone here who has time to explain to me (or link articles about) why functional components and hooks are considered to be better than class components, please enlighten me.

Static evaluation of which instance properties are being used in a class instance is much harder than evaluating which variables are being referenced in a function. There's no need to worry about calling context or binding instance methods. Functions minify much better because you don't have to worry about preserving long property names like componentDidUpdate. With class components, sharing logic involving state between components required either functions taking a state setter and whatever slice of state you needed, or--more commonly--higher order components. With function components and hooks, the code responsible for initializing and updating state isn't tied to an instance. Now you can share that code with a plain function without needing to pass an entire slice of state and an update function into it. Instead of needing to shove all your update-related code into the same componentDidUpdate or componentWillUnmount methods, you now split them into different calls to useEffect.

> Suddenly everything is intermingled in one function and we're using side effects to react to changes and manipulate state. I could no longer understand when which code was executed, and especially following and manipulating state became impossible for me.

If you're talking about using useEffect to respond to changes by setting state: that's almost always a code smell and sounds like trying to sync state with props. This was an anti-pattern long before hooks, and was called out explicitly in the docs.

Having worked on a lot of class components and function components, class components offer a lot more opportunities for bugs which can't be statically prevented. On the other hand, most of these bugs can be caught in function components and hooks by a linter, or are just prevented entirely by the design. A frequent question which came up during the class component era was what code belonged in the class's constructor, componentWillMount, or componentDidMount methods. This always came with caveats, because generally component initialization isn't something developers should be thinking about because it can happen many times before anything appears on screen. Function components offer fewer opportunities for this. The useEffect hook forces people to think purely in terms of running effects in response to changes in variables which have been closed over, and about what things need to be done to clean up after the effect has run. Responding to user events (e.g. onClick) is almost exactly the same as it's always been other than cosmetic changes.

I'm not sure how everything being in a single function offers worse organization than everything being within a class. Instead of instance properties you have variables. Instead of methods you have inner functions.

While I completely understand OP's sentiment, after literal decades of web/front-end development, I never quite grasped the depth of disdain for Javascript or CSS until being on a team where more than the same 2 or 3 people were actively coding in them.

"frontend" is the wrong word, he should have said "web". Writing desktop UIs or mobile apps tends to be elegant. And probably "SPA frontend" as server-side UIs are also much cleaner.

These days web/mobile is implied by frontend. I'd say a very large proportion now work on these two compared to desktop.

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.

React's mental model has always been UI = F(data) and in ideal case any component is a pure function. But, of course, in most real apps there are cases when this mental model breaks: internal state, animations and side effects. The old way to provide escape hatches for those cases was to wrap a function into a class, where original function is 'render' method and the cases above are handled with lifecycle methods. The problem was that one piece of functionality often required updating several lifecycle methods, and for a big component that non-locality made things very hard. Hooks are a different way to express non-purity that keep code more local.

Thanks, that makes sense. Interesting perspective on the UI = F(data), I did not know that. I still wish the mechanics were a bit more... intuitive... I guess? Personally, I'm a big fan of The Elm Architecture [1]. I felt that is a very nice way to separate state and logic. But I'm not such a big fan of Elm itself (subjectively).

[1] https://guide.elm-lang.org/architecture/

It is also a bundler and minifier and dead code tree-shaker. It combines all your modules into one file (or a few) for production. In development it doesn’t do the bundling part (for now — with Rolldown[0] replacing Rollup[1] in the future, bundling will be fast enough to do the same in dev and prod).

It also serves as an integration point for other kinds of tooling that involves processing or generating code. For example, the latest versions of React Router[2] (which now integrates Remix's features) and Tailwind[3] are designed primarily to be integrated into projects as Vite plugins.

[0]: https://rolldown.rs/

[1]: https://rollupjs.org/

[2]: https://reactrouter.com/home#react-router-as-a-framework

[3]: https://tailwindcss.com/blog/tailwindcss-v4#first-party-vite...

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.

>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.

I've been seeing Vite everywhere. Why do we need Vite now? I don't want to switch to another build system again

I've tried many of them. They all suck.

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.

There was a great interview on ACM Queue [0] where they explain that paradigm. As a rule of thumb. Try to keep everything functional, and if you want to have state, keep it contained to its component.

[0]: https://dl.acm.org/doi/10.1145/2984629.2994373

Not a crazy take.

Then try something like snabbdom or mithril.js.

No, not really. Some do, some don't. There are valid criticisms to dislike them. I'm on the side that thinks they are bad.