14 ms·

I don't really understand how people get so burnt out from frontend frameworks. I started out using jquery and bootstrap, but I don't miss that at all, and love

I don't really understand how people get so burnt out from frontend frameworks. I started out using jquery and bootstrap, but I don't miss that at all, and love the convenience of the modern frameworks.

throwup238 3y ago
As someone who professionally does mostly frontend since jquery I agree but when working on full stack personal projects in Django and other backend frameworks that aren’t Node, I start to empathize. Doubling the yack shaving quotient on a project is not fun. The problem causing burnout isn’t the framework but all the tooling around it. Webpack alone has probably caused as much PTSD as a minor war and if you’re not in frontend you don’t know to just install Vite, copy a tailwind config, and get started. With HTMX you just add a script tag and go. The developer experience for adding some simple dynamic features is leagues better, even if the DSL is esoteric.
- zarzavat 3y ago
  I’d be curious to know what has better tooling than the web? From what other platform are people coming from that they find web tooling to be a downgrade? Coming from a C++ background I will happily write webpack configs for the rest of my life…
  - djbusby 3y ago
    VB6 had amazing tooling. Unified dev environment, easy UI designer, step-debugger, press one button and your App works on all (Windows) devices from Win95 and newer!
    - stavros 3y ago
      Oh man, VB6 was the pinnacle of writing desktop software. The language itself wasn't great, but the overall experience was stellar.
  - theptip 3y ago
    Every modern backend web programming framework? Frontend requires a lot of flexibility and compromise because the runtime environment is so disparate. In the backend you choose and control one runtime so the framework can integrate tightly with the authoring workflow. Concretely, Rails, Django, Spring, Elm, all have great tooling and are much easier to work with than frontend stacks.
  - throwup238 3y ago
    Web tooling on the browser side is amazing, but until relatively recently the build tooling was so bad I'd easily put it on par with C/C++. Not as bad mind you, since package management is better, but otherwise I'd rank both as from the same layer of hell and in the same ballpark in terms of suffering. The only thing that rose to the level of debugging webpack configs for me recently is debugging the build for a QT app that linked against non-system KDE libs. Now if you know what you're doing it's much better now that everyone has converged on ES6 modules and with the latest generation of build tools like Vite, all you need to do is npm install some packages to provide zero-config support for frameworks like React, Svelte, etc. But it used to be so much worse.
- drcongo 3y ago
  I'm professionally mostly in Django and my front end skills have been left to rot for a decade - your comments about Webpack, Vite etc. ring very true. I recently looked into replacing Webpack on a project with something less painfully slow, failed to get Vite working so tried Parcel which is supposed to be idiot proof. I guess I'm more even more idiotic than that. As for HTMX, I've been playing with that on an evening / weekend project and absolutely love it. Getting it working with Django was maybe very slightly harder than with other backend frameworks as Django doesn't have great support for template fragments. Once I'd sorted that though, I had a decent interactive UI on top of my app very quickly, all while being completely new to HTMX. I can imagine being incredibly productive with it with a bit more learning / use.
Zetobal 3y ago
It's probably for people like me who only need to build a web frontend 1-2 times per year.
solardev 3y ago
I think at a certain level of complexity, the frameworks do add a lot of value. Especially if you're primarily a web dev and understand the value of componentization, good tooling, etc., and are OK with Javascript's many idiosyncracies. But if this isn't something you do full time and just occasionally tinker with for a personal blog or something, the ecosystem's signal-to-noise ratio can be very, very low, and it's hard to know the right way to get started, and what's important to worry about or not, or how to resolve obscure errors from some tiny part of the buildchain. 3-4 years ago, it was especially bad, when you had to bundle together a bunch of different things yourself (webpack, eslint, typescript compilers, react, state managers, routers, etc.) all from scratch, and any one of those could cause serious incompatibilities with the other parts. These days it's a lot better with things like Next (for bigger projects) or Vite/Astro for simple sites, since they abstract away all the tooling setup for you (and 1-click deploy on Vercel helps a lot too). But if you're not deep in the frontend world, the differences between all these random projects can be pretty non-obvious. Plus, JS changes so quickly it's impossible to keep up with the bleeding edge... maybe, hopefully, it'll slow down now since all the VCs are shifting to AI instead? And that's just the frontend side. If you need a backend too (as opposed to simple API routes or a headless CMS or something), then you have to deal with all the differences between Node.js vs browser JS, polyfills, different Node versions, serverside vs clientside rendering... it's a lot of mental overhead vs the traditional "business logic lives on the backend, the frontend just handles presentation" model. HTMX seems like a good tool for a heavy backend and a light frontend, which probably isn't the kind of project that most full-time frontend devs would work on anyway. At the end of the day, I think it's cool the Web has still managed to maintain its (relative) openness and tool-independence. You can still make a functional site in anything from an expensive IDE + huge framework to Notepad, and everything in between, and there's never really just "one right answer"... totally depends on your project's needs, your team's skills & resources, and various tradeoffs. I'm not the target audience for HTMX either (the React ecosystem is just far too useful, with NPM and MUI especially), but it's cool that it exists.
- nullindividual 3y ago
  > traditional "business logic lives on the backend, the frontend just handles presentation" model .NET Framework has it's flaws, but the ease of development of ASP.NET WebForms or MVC sites is awesome. The JS ecosystem, not only is it confusing, all too often documentation, forum posts, etc. out of date making the barrier to entry that much higher.

throwup238 3y ago

As someone who professionally does mostly frontend since jquery I agree but when working on full stack personal projects in Django and other backend frameworks that aren’t Node, I start to empathize. Doubling the yack shaving quotient on a project is not fun. The problem causing burnout isn’t the framework but all the tooling around it. Webpack alone has probably caused as much PTSD as a minor war and if you’re not in frontend you don’t know to just install Vite, copy a tailwind config, and get started. With HTMX you just add a script tag and go. The developer experience for adding some simple dynamic features is leagues better, even if the DSL is esoteric.

zarzavat 3y ago
I’d be curious to know what has better tooling than the web? From what other platform are people coming from that they find web tooling to be a downgrade? Coming from a C++ background I will happily write webpack configs for the rest of my life…
- djbusby 3y ago
  VB6 had amazing tooling. Unified dev environment, easy UI designer, step-debugger, press one button and your App works on all (Windows) devices from Win95 and newer!
  - stavros 3y ago
    Oh man, VB6 was the pinnacle of writing desktop software. The language itself wasn't great, but the overall experience was stellar.
- theptip 3y ago
  Every modern backend web programming framework? Frontend requires a lot of flexibility and compromise because the runtime environment is so disparate. In the backend you choose and control one runtime so the framework can integrate tightly with the authoring workflow. Concretely, Rails, Django, Spring, Elm, all have great tooling and are much easier to work with than frontend stacks.
- throwup238 3y ago
  Web tooling on the browser side is amazing, but until relatively recently the build tooling was so bad I'd easily put it on par with C/C++. Not as bad mind you, since package management is better, but otherwise I'd rank both as from the same layer of hell and in the same ballpark in terms of suffering. The only thing that rose to the level of debugging webpack configs for me recently is debugging the build for a QT app that linked against non-system KDE libs. Now if you know what you're doing it's much better now that everyone has converged on ES6 modules and with the latest generation of build tools like Vite, all you need to do is npm install some packages to provide zero-config support for frameworks like React, Svelte, etc. But it used to be so much worse.
drcongo 3y ago
I'm professionally mostly in Django and my front end skills have been left to rot for a decade - your comments about Webpack, Vite etc. ring very true. I recently looked into replacing Webpack on a project with something less painfully slow, failed to get Vite working so tried Parcel which is supposed to be idiot proof. I guess I'm more even more idiotic than that. As for HTMX, I've been playing with that on an evening / weekend project and absolutely love it. Getting it working with Django was maybe very slightly harder than with other backend frameworks as Django doesn't have great support for template fragments. Once I'd sorted that though, I had a decent interactive UI on top of my app very quickly, all while being completely new to HTMX. I can imagine being incredibly productive with it with a bit more learning / use.

Zetobal 3y ago

It's probably for people like me who only need to build a web frontend 1-2 times per year.

solardev 3y ago

I think at a certain level of complexity, the frameworks do add a lot of value. Especially if you're primarily a web dev and understand the value of componentization, good tooling, etc., and are OK with Javascript's many idiosyncracies. But if this isn't something you do full time and just occasionally tinker with for a personal blog or something, the ecosystem's signal-to-noise ratio can be very, very low, and it's hard to know the right way to get started, and what's important to worry about or not, or how to resolve obscure errors from some tiny part of the buildchain. 3-4 years ago, it was especially bad, when you had to bundle together a bunch of different things yourself (webpack, eslint, typescript compilers, react, state managers, routers, etc.) all from scratch, and any one of those could cause serious incompatibilities with the other parts. These days it's a lot better with things like Next (for bigger projects) or Vite/Astro for simple sites, since they abstract away all the tooling setup for you (and 1-click deploy on Vercel helps a lot too). But if you're not deep in the frontend world, the differences between all these random projects can be pretty non-obvious. Plus, JS changes so quickly it's impossible to keep up with the bleeding edge... maybe, hopefully, it'll slow down now since all the VCs are shifting to AI instead? And that's just the frontend side. If you need a backend too (as opposed to simple API routes or a headless CMS or something), then you have to deal with all the differences between Node.js vs browser JS, polyfills, different Node versions, serverside vs clientside rendering... it's a lot of mental overhead vs the traditional "business logic lives on the backend, the frontend just handles presentation" model. HTMX seems like a good tool for a heavy backend and a light frontend, which probably isn't the kind of project that most full-time frontend devs would work on anyway. At the end of the day, I think it's cool the Web has still managed to maintain its (relative) openness and tool-independence. You can still make a functional site in anything from an expensive IDE + huge framework to Notepad, and everything in between, and there's never really just "one right answer"... totally depends on your project's needs, your team's skills & resources, and various tradeoffs. I'm not the target audience for HTMX either (the React ecosystem is just far too useful, with NPM and MUI especially), but it's cool that it exists.

nullindividual 3y ago
> traditional "business logic lives on the backend, the frontend just handles presentation" model .NET Framework has it's flaws, but the ease of development of ASP.NET WebForms or MVC sites is awesome. The JS ecosystem, not only is it confusing, all too often documentation, forum posts, etc. out of date making the barrier to entry that much higher.