3 ms·

I know this is highly controversial, but I don't understand all this sentiment against js frameworks. You can still write vanilla html + js if you don't need ha

I know this is highly controversial, but I don't understand all this sentiment against js frameworks. 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, but maybe you don't need to scale, you just need to show some simple content with a login page and a "back to top" button. You can absolutely do that without frameworks, and you're better off without. Here comes the controversial part: I feel all this sentiment against "frontend complexity" is essentially non-frontend developers wanting cool, highly interactive web apps for their backend and getting bummed when they discover it's hard, specialized work. It is, the browser is a beast, all the layers are backwards compatible and web apps are essentially i/o heavy programs responding to a huge number of async events, trying to render a complex state in response on millions of slightly incompatible platforms. There's no silver bullet for that: it's complex, and the complexity shows in the tooling. But if you don't need that complexity because you just need the browser's lower-interactivity presentation layer, nobody in the world forces you to write an SPA. 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. Sorry for the rant.

lelanthran 2y ago
> I feel all this sentiment against "frontend complexity" is essentially non-frontend developers wanting cool, highly interactive web apps for their backend and getting bummed when they discover it's hard, specialized work. Maybe it is hard and specialised, but from the viewpoint of someone who just wants to deliver an app, exactly what would I need a client side router for? Or a virtual DOM? Until I am in need of an interface that has the needs of Facebook, I need convincing that these things are adding value. > But if you don't need that complexity because you just need the browser's lower-interactivity presentation layer That's sufficient for 999 out of every 1000 web apps. In practice I see the opposite ratio. Just this past month I yanked out the entire reacy front end from a project and replaced it, functionally, with plain html, js and CDs and the junior tasked with working on it was able to iterate much faster than he had been doing before. At a previous larger contract I just kept the react and powered through, but I kept having the team run into problems because like it or not, the cognitive burden of react very often outweighs any benefits it brings.
- curtisblaine 2y ago
  Agree with the wrong ratio, and the explanations I can find are two: 1) When starting a project, product people always exaggerate the scope, so tech people set it up for scaling from day 0 2) React is industry standard, so it's easier to say "here, this is a React component, you know how it works" rather than re-inventing your "component" pattern that mutates the DOM. That said, complexity is a spectrum: scaling up and down is equally painful. Understanding how to calibrate efforts comes only after a lot of experience.
averageRoyalty 2y ago
> 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.

lelanthran 2y ago

> I feel all this sentiment against "frontend complexity" is essentially non-frontend developers wanting cool, highly interactive web apps for their backend and getting bummed when they discover it's hard, specialized work. Maybe it is hard and specialised, but from the viewpoint of someone who just wants to deliver an app, exactly what would I need a client side router for? Or a virtual DOM? Until I am in need of an interface that has the needs of Facebook, I need convincing that these things are adding value. > But if you don't need that complexity because you just need the browser's lower-interactivity presentation layer That's sufficient for 999 out of every 1000 web apps. In practice I see the opposite ratio. Just this past month I yanked out the entire reacy front end from a project and replaced it, functionally, with plain html, js and CDs and the junior tasked with working on it was able to iterate much faster than he had been doing before. At a previous larger contract I just kept the react and powered through, but I kept having the team run into problems because like it or not, the cognitive burden of react very often outweighs any benefits it brings.

curtisblaine 2y ago
Agree with the wrong ratio, and the explanations I can find are two: 1) When starting a project, product people always exaggerate the scope, so tech people set it up for scaling from day 0 2) React is industry standard, so it's easier to say "here, this is a React component, you know how it works" rather than re-inventing your "component" pattern that mutates the DOM. That said, complexity is a spectrum: scaling up and down is equally painful. Understanding how to calibrate efforts comes only after a lot of experience.

averageRoyalty 2y ago

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