3 ms·

> You can still write vanilla html + js if you don't need hashed assets, css isolation, routers, linting, types, complex state, etc. It won't scale much Why wo

> You can still write vanilla html + js if you don't need hashed assets, css isolation, routers, linting, types, complex state, etc. It won't scale much Why won't it scale? The point of static content/client side work is that the load server side is minimal. It will scale as high as the webserver supports. > The problems normally start when you want to "just add a comment section" to your content but then you don't want to reload the page and you discover that it becomes complex soon and writing SPAs comes at a cost. We've had `XMLHttpRequest` since the early 2000s. It would be incredibly easy to add this in vanilla JS. You could build 95% of websites out there on a standard LAMP stack from 2004 using vanilla JS or at a push jQuery. The sentiment against frontend complexity (from my observation) seems to be mostly from greybeards who look at big, bloated, high dependency and complex to build solutions for simple web content. Although I don't personally feel forced, the way markets and industries work you may be "forced" based on what the status quo is in industry at the time.

curtisblaine 2y ago
It won't scale in complexity. At a certain point, your mutable state will become really hard to maintain, so you will need some form of state manager. Then your code will grow and accumulate a lot of bad practices, so you will need a linter. You won't be able to keep the whole codebase in your mind, so you will need more help from your IDE, and you'll end up using Typescript. Your teams will keep overriding each other's CSS, so you will introduce CSS Modules in your build step. The product managers will ask about deeplinking without reloading the page, so you will install a router. Your mutable DOM manipulation code will become full of ifs and special cases, so you will feel the need of abstracting out your components in a declarative way etc. I'm not saying you need all of this from the start, but you will need parts of it pretty soon if your application is heavily interactive.

curtisblaine 2y ago

It won't scale in complexity. At a certain point, your mutable state will become really hard to maintain, so you will need some form of state manager. Then your code will grow and accumulate a lot of bad practices, so you will need a linter. You won't be able to keep the whole codebase in your mind, so you will need more help from your IDE, and you'll end up using Typescript. Your teams will keep overriding each other's CSS, so you will introduce CSS Modules in your build step. The product managers will ask about deeplinking without reloading the page, so you will install a router. Your mutable DOM manipulation code will become full of ifs and special cases, so you will feel the need of abstracting out your components in a declarative way etc. I'm not saying you need all of this from the start, but you will need parts of it pretty soon if your application is heavily interactive.