4 ms·

>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 + Typescri

by dtquad 2y ago

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

kovacs 2y ago
it's the best comment in the entire post IMHO and made me LOL
pinoy420 2y ago
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.
- knodi123 2y ago
  I know what you meant, but that phrasing reminds me of the gag from Anchorman, "60% of the time, it works every time."
phailhaus 2y ago
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.
- jghn 2y ago
  Both of his blogs mention Java at least once. It's a good bet this factors heavily in his day to day.
- zelphirkalt 2y ago
  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.
  - phist_mcgee 2y ago
    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.
    - zelphirkalt 2y ago
      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.
      - phist_mcgee 2y ago
whstl 2y ago
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.
- dfee 2y ago
  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.)
  - ericyd 2y ago
    > 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.
  - dcre 2y ago
    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/ https://rolldown.rs/ [1]: https://rollupjs.org/ https://rollupjs.org/ [2]: https://reactrouter.com/home#react-router-as-a-framework https://reactrouter.com/home#react-router-as-a-framework [3]: https://tailwindcss.com/blog/tailwindcss-v4#first-party-vite-plugin https://tailwindcss.com/blog/tailwindcss-v4#first-party-vite...
ge96 2y ago
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.
kflgkans 2y ago
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.
- rimunroe 2y ago
  > 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.
settsu 2y ago
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.
jolt42 2y ago
"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.
- phist_mcgee 2y ago
  These days web/mobile is implied by frontend. I'd say a very large proportion now work on these two compared to desktop.
tobyhinloopen 2y ago
I've been seeing Vite everywhere. Why do we need Vite now? I don't want to switch to another build system again

by dtquad 2y ago

kovacs 2y ago

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

pinoy420 2y ago

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.

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

phailhaus 2y ago

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.

jghn 2y ago
Both of his blogs mention Java at least once. It's a good bet this factors heavily in his day to day.
zelphirkalt 2y ago
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.
- phist_mcgee 2y ago
  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.
  - zelphirkalt 2y ago
    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.
    - phist_mcgee 2y ago

whstl 2y ago

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.

dfee 2y ago
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.)
- ericyd 2y ago
  > 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.
- dcre 2y ago
  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/ https://rolldown.rs/ [1]: https://rollupjs.org/ https://rollupjs.org/ [2]: https://reactrouter.com/home#react-router-as-a-framework https://reactrouter.com/home#react-router-as-a-framework [3]: https://tailwindcss.com/blog/tailwindcss-v4#first-party-vite-plugin https://tailwindcss.com/blog/tailwindcss-v4#first-party-vite...

ge96 2y ago

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.

kflgkans 2y ago

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.

rimunroe 2y ago
> 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.

settsu 2y ago

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.

jolt42 2y ago

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

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

tobyhinloopen 2y ago

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