3 ms·

The frontend world seems to be drowning in its own accidental complexity, with each new framework trying to solve the ecosystem's self-created problems. I've b

The frontend world seems to be drowning in its own accidental complexity, with each new framework trying to solve the ecosystem's self-created problems. I've been developing complicated full stack apps for years with nearly-vanilla JS, CSS and HTML, plus a helping of basic software design skills, and I have no trouble managing complexity, delivering features fast, etc. I've never related to all these problems the frontend world endlessly frets about like state management, build times (I don't use builds), polyfills (I just use whatever raw JS subset is about 97% supported), server-side rendering (just design your app with an intelligent division of labor between client and server), dependency management (minimize them, and understand the ones you use fully so you can adapt them to your needs), etc. Like this site demonstrates, reasoning for using all this cruft is always vague too - "best practice", "modern", "next gen", whatever. Seriously, the whole frontend ecosystem seems a rube goldberg tower built on pseudo-technical marketing fluff that has everyone chasing their tail and adding more unnecessary layers. I don't get it. If you're deep in this world, I highly recommend: go a layer down. Try implementing your next feature with and without the library / framework du joir. Can you simplify, remove layers, and still accomplish your goals? How much code is it for each version, including the framework? Is the dependency worth all its baggage, like build times, module incompatibilities, leaky abstractions, loss of control, etc.?

sachinraja 4y ago
If anything, Vite is less complexity. It's much easier to use and configure than any other build tool I've used. If you don't have a need/want for Vite, that's fine, but others enjoy using it. I am not fretting over the next build tool, I'm simply switching to something I prefer to use.
selfmodruntime 4y ago
Your entire answer basically becomes moot since this is not a framework. At all. This is a build tool, something like a compiler. And it's been writtes by arguably one of the greatest dev in the current generation to get rid of every problem you discribe. There is almost no configuration involved in getting your projects to "just work", which is why people love it. Give frontend some time. Frontend development, like it exists now, is 10 years old. Backend applications and their architecture have a 30 year advantage.
mmcnl 4y ago
Apparently you have never built a webapp that is more ambituous than a simple website. The superpower of "modern" frameworks (Vue and React are both 5-10 years old) is abstracting away from the DOM to be able to define your view as a function of state. Vanilla JS doesn't help you in that regard.
- QuadrupleA 4y ago
  See reply to woojoo below - not saying I'm the world's best frontend dev, but I've built complex apps with many screens / modes / complex state. Despite what people seem to think, the world doesn't fall apart without a virtual DOM, indeed it usually gets simpler. Vanilla JS gives you all the essentials to make abstractions to fit your task (i.e. functions and structured data).
  - mmcnl 4y ago
    Sure it's possible. You can also program in assembly instead of Java. But you'll soon be creating your own abstraction layer, why not use one that is very thin too and battle tested by millions of users?
christoph 4y ago
I absolutely agree with you on the surface, as I’m of exactly the same mind. However, I’ve forced myself to use a few shiny new things on projects over the last couple of years and it’s been a mixed bag. Some new frameworks like Vue have absolutely shrunk development times for certain types of projects by a serious order of magnitude, as we are now worrying way less about state and writing far less code overall. Mutating certain changes just cascades down without us worrying too much and writing loads of code to handle those changes/updates. Hot reloads alone have easily saved countless development hours. Other times, I just feel like I’ve been fighting a framework for hours to achieve something that really should have only take a few minutes. IMO, it’s about having as many weapons in your arsenal as possible and always selecting the most appropriate for the task at hand. You can only really do this if you have a good broad working knowledge of as many tools as possible, to understand their unique strengths and limitations. Typically I just avoid the latest shiny new thing entirely for at least a couple of years until it’s stabilised somewhat. I got burnt early adopting Swift and spending countless unbillable hours updating thousands of LOC every time Apple seemed to break the entire thing with each new release.
woojoo666 4y ago
Have any examples of websites or products of yours? Edit: ok so I took a look at the website in your hackernews bio. Some cool stuff there, but honestly in terms of front end work it isn't terribly complicated. So while you might be picking the correct tools for your work, it doesn't really apply for, say, a marketplace website that wants to lazy load long lists of products, or that want to re-use those product cards across different pages, etc. This is where vanilla JS starts to be too low-level, and you start to see the benefits of the structure that frameworks provide.
- QuadrupleA 4y ago
  That site is just smaller side projects - in my paid work I do maintain large apps with dozens of screens, modals, workflows, complex state etc. It's not necessarily trivial, you have to think through your design approaches, but JS is a Turing complete language after all, with all the elements you need to build abstractions to fit your task. I haven't personally found virtual DOM to be a win in my projects (I've experimented plenty with react). Things have always been more performant and simpler without it, and the dev experience is much nicer and simpler and easier to debug without a build step. Of course my projects don't represent everybody's, but I've done a wide variety of them so I'm not speaking from some esoteric niche viewpoint either. There's a certain stockholm syndrome with these tools where people assume they'd be much worse off without them, without actually trying it out.

sachinraja 4y ago

If anything, Vite is less complexity. It's much easier to use and configure than any other build tool I've used. If you don't have a need/want for Vite, that's fine, but others enjoy using it. I am not fretting over the next build tool, I'm simply switching to something I prefer to use.

selfmodruntime 4y ago

Your entire answer basically becomes moot since this is not a framework. At all. This is a build tool, something like a compiler. And it's been writtes by arguably one of the greatest dev in the current generation to get rid of every problem you discribe. There is almost no configuration involved in getting your projects to "just work", which is why people love it. Give frontend some time. Frontend development, like it exists now, is 10 years old. Backend applications and their architecture have a 30 year advantage.

mmcnl 4y ago

Apparently you have never built a webapp that is more ambituous than a simple website. The superpower of "modern" frameworks (Vue and React are both 5-10 years old) is abstracting away from the DOM to be able to define your view as a function of state. Vanilla JS doesn't help you in that regard.

QuadrupleA 4y ago
See reply to woojoo below - not saying I'm the world's best frontend dev, but I've built complex apps with many screens / modes / complex state. Despite what people seem to think, the world doesn't fall apart without a virtual DOM, indeed it usually gets simpler. Vanilla JS gives you all the essentials to make abstractions to fit your task (i.e. functions and structured data).
- mmcnl 4y ago
  Sure it's possible. You can also program in assembly instead of Java. But you'll soon be creating your own abstraction layer, why not use one that is very thin too and battle tested by millions of users?

christoph 4y ago

I absolutely agree with you on the surface, as I’m of exactly the same mind. However, I’ve forced myself to use a few shiny new things on projects over the last couple of years and it’s been a mixed bag. Some new frameworks like Vue have absolutely shrunk development times for certain types of projects by a serious order of magnitude, as we are now worrying way less about state and writing far less code overall. Mutating certain changes just cascades down without us worrying too much and writing loads of code to handle those changes/updates. Hot reloads alone have easily saved countless development hours. Other times, I just feel like I’ve been fighting a framework for hours to achieve something that really should have only take a few minutes. IMO, it’s about having as many weapons in your arsenal as possible and always selecting the most appropriate for the task at hand. You can only really do this if you have a good broad working knowledge of as many tools as possible, to understand their unique strengths and limitations. Typically I just avoid the latest shiny new thing entirely for at least a couple of years until it’s stabilised somewhat. I got burnt early adopting Swift and spending countless unbillable hours updating thousands of LOC every time Apple seemed to break the entire thing with each new release.

woojoo666 4y ago

Have any examples of websites or products of yours? Edit: ok so I took a look at the website in your hackernews bio. Some cool stuff there, but honestly in terms of front end work it isn't terribly complicated. So while you might be picking the correct tools for your work, it doesn't really apply for, say, a marketplace website that wants to lazy load long lists of products, or that want to re-use those product cards across different pages, etc. This is where vanilla JS starts to be too low-level, and you start to see the benefits of the structure that frameworks provide.

QuadrupleA 4y ago
That site is just smaller side projects - in my paid work I do maintain large apps with dozens of screens, modals, workflows, complex state etc. It's not necessarily trivial, you have to think through your design approaches, but JS is a Turing complete language after all, with all the elements you need to build abstractions to fit your task. I haven't personally found virtual DOM to be a win in my projects (I've experimented plenty with react). Things have always been more performant and simpler without it, and the dev experience is much nicer and simpler and easier to debug without a build step. Of course my projects don't represent everybody's, but I've done a wide variety of them so I'm not speaking from some esoteric niche viewpoint either. There's a certain stockholm syndrome with these tools where people assume they'd be much worse off without them, without actually trying it out.