5 ms·

Having spent a decade in the late 90s / early aughts doing PHP web development (including Bootstrap), I can't for the life of me figure out why modern framework

Having spent a decade in the late 90s / early aughts doing PHP web development (including Bootstrap), I can't for the life of me figure out why modern frameworks need hooks and a shadow DOM and a component model. I dabbled for a bit about a decade ago, and the first and last JS framework I worked with was Angular2 (which was in beta); this was right about the time Typescript was getting started (in fact, I distinctly recall that a substantial number of popular JS libraries didn't even have TS bindings at that time). I think I didn't really want to look stupid by asking in public on HN, but given recent events, I think that ship has sailed :) Other than analytics, what in the world do we need all of this JS for? I used jQuery (sparingly I might add), and it did its job. Most web forms don't even have that many components. I honestly don't mean to insult anyone, and I know I must just be naive about something. Because otherwise, HTML/CSS aren't that complicated. Messy? Sure. Large? Yup. Duplicative in areas? 100%. So what am I missing? What exactly does React do so well that the added complexity and resulting slowdowns become an acceptable tradeoff?

krab 2y ago
You split your app into components and separate it from the backend using an API. This allows you to build a bigger development team. The result will be less efficient but more featureful, more polished, will have someone on call and a better bus factor. It's a trade-off.
- caspper69 2y ago
  I don't mean to be obtuse, so let me make sure I have this right (and please afford me some leeway on my gentle ribbing, I assure you it's all in good fun and nothing personal): A framework will allow me to separate the app from its backend? The web, by its very nature, runs on a client/server architecture, so it has long been possible to separate the front from the backend via an API (we can argue the level of difficulty involved, but I would say the friction was substantially reduced with the introduction of XMLHttpRequest). So aside from separation via API, according to your list, that leaves us with (1) a bigger development team; (2) a less efficient result; (3) a potentially more polished result (I added possibly, because I'm dubious about the claim that a JS framework makes the result more polished- does it make the browser render the HTML components in a higher resolution or higher color bit-depth?); (4) someone on call (like an employee or group of employees who have to be on call at all times? or am I misunderstanding?); and (5) a better "bus factor" which is a term that I am actually unfamiliar with (is this jargon, or is it an actual technical term/concept?). Which of these are technical in nature, or rather I should say, which of these factors has anything to do with software (in the abstract) or actual code or markup (in the concrete)? Now for my more serious follow up: just level with me; is this all bs? Do people use these frameworks because they don't know any other way to do it? Is it a code / organizational issue? Did people take the "separate all code from all HTML/CSS" advice too far and adopt it as dogma? Do people find the event model in JS to be too complex or unreliable? Is it an issue of people getting hooked on frameworks while JS was in flux so they needed the polyfills? Is it that people fell in love with TS, which naturally led to framework-itis? I feel kind of like I went to the future, and everybody rides exercise bikes everywhere they go to stay in shape, but since exercise bikes don't go anywhere, they have to be put in the bed of a pickup truck first, you know, to actually go places, but then there was a gas shortage, so it was decided to save gas we'd all carpool by putting 5 pickup trucks on a single semi-truck flatbed. Because that's just how things evolved. So now you're explaining to me why I see people riding exercise bikes on top of pickup trucks that are themselves being pulled 5 at a time on the back of a semi truck, and you're looking at me like I'm out of touch because I can't figure out why you guys can't just walk the 250 feet to the store across the street.
  - chillfox 2y ago
    "bus factor" is just a side benefit of having a larger dev team. The idea is if someone gets run over by a bus then you still have someone who "knows" the code to train the replacement.
    - caspper69 2y ago
      I like it. I will add it to my lexicon. Thanks!
      - arkh 2y ago
        More exactly, the bus factor = number of people who'd have to be hit by a bus to stop development. So the bigger your bus factor, the more secure your dev.
  - gigatree 2y ago
    Hilarious analogy that honestly doesn’t seem that far off. But in that reality, you probably wouldn’t be able to walk to the store, much less anywhere else, because there would be all these semi trucks driving everywhere and a road-dominated country. That’s basically a dev trying to get a job today, which means they’re just gonna focus on learning that whether it’s the best solution or not. Most devs don’t use React because it’s the best tool for the job, they use it because it’s the best tool for getting a paycheck.
    - caspper69 2y ago
      Well we can all relate to that. We've all got to eat (and stay warm & dry). I think I'm just getting to the "old man yells at cloud" stage of my career. I think of all of the things that we could have built over the years, and understand, I say this not to detract from all of the great software that has been built, but to lament the fact that devs spend so much time spinning their wheels these days (when not reinventing them, or trying to fit a square one on a race car) that we have spent so much opportunity cost that could have been the next big thing or the better version of an old thing. I would just implore people to go back and look at the history of computing, and the things we had back then (even if they were research demos or ahead-of-their-time pipe dreams), and remember that we have 100,000-1,000,000x the compute (or more) than we had when these older things were built. We can do better. And remember, not every abstraction is a useful one, not every appeal from authority should be taken as gospel, that creating software can be one of the most creative and expressive endeavors one can undertake, that there is no greater joy than seeing people use the things you build (or help build), and that there's no such thing as perfect software (but we should always strive to get as close as reasonably possible).
- arkh 2y ago
  > The result will be less efficient but more featureful, more polished Not sure about polished. Just see the Atlassian wasteland: lot of features, I'm sure huge and numerous teams. Ages to load a page or anything. Multiple API documentations depending on what you need. The integration between tools is mostly random. "Simple" feature asked for a decade ago never got implemented.
Zanfa 2y ago
In my experience, a lot of developers have a very limited grasp of what the browser can do for you without React. If all you know is React, everything looks like a single-page application.
- emayljames 2y ago
  I have a very good grasp on jQuery and a good grasp on SPA frameworks, and as soon as you cross that barrier into a complex application, jQuery is completely unsuitable in maintaining a clean state.
Tade0 2y ago
My career started in the transition period between jQuery everywhere and frameworks everywhere. Much of my work throughout the years was picking up after others who left/were fired. Main difference that I noticed between that time and the present day is that you hardly ever see unfixable monstrosities made by a lone-wolf one-man-army developer any more - at least in the Angular space, where as long as you're familiar with the convention, you'll manage. Much of that is thanks to TypeScript and the possibility to communicate to future maintainers what was your intention without writing paragraphs upon paragraphs of documentation. Of course the tradeoff is that it's all pretty heavy right now, but that's what frameworks like Svelte or SolidJS and generally the concept of Signals try to address. My take is that the moment we get Signals into the JS standard, this will all neatly fold like rows in Tetris.
arkh 2y ago
> So what am I missing? Money and resume driven development. Just being a webmaster integrating a simple design could be done by "anyone" so not paying so well anymore. So came the idea: now we're not doing websites, we're doing webapps. Suddenly fresh-out-of-school engineers can try to implement GUI concepts they vastly misunderstood, but in javascript and limited by the DOM. So that's years of work to maybe get a tenth of the performances of desktop apps: javascript interpreters to optimize, browsers, frameworks and then the apps themselves. Add the rise of smartphone apps and you even get the excuse of "we made an API for the apps, so why not use it for the frontend".
dartos 2y ago
The real reason is because it’s faster (or was in 2014) to diff 2 versions of an optimized in-memory tree than it is to use the dom API to diff live html (where any change might trigger the browser’s layout and rendering pipeline) That’s why react opted for a virtual dom. Many frameworks followed suit. We’re a decade on at this point and JavaScript runtimes are much faster

krab 2y ago

You split your app into components and separate it from the backend using an API. This allows you to build a bigger development team. The result will be less efficient but more featureful, more polished, will have someone on call and a better bus factor. It's a trade-off.

caspper69 2y ago
I don't mean to be obtuse, so let me make sure I have this right (and please afford me some leeway on my gentle ribbing, I assure you it's all in good fun and nothing personal): A framework will allow me to separate the app from its backend? The web, by its very nature, runs on a client/server architecture, so it has long been possible to separate the front from the backend via an API (we can argue the level of difficulty involved, but I would say the friction was substantially reduced with the introduction of XMLHttpRequest). So aside from separation via API, according to your list, that leaves us with (1) a bigger development team; (2) a less efficient result; (3) a potentially more polished result (I added possibly, because I'm dubious about the claim that a JS framework makes the result more polished- does it make the browser render the HTML components in a higher resolution or higher color bit-depth?); (4) someone on call (like an employee or group of employees who have to be on call at all times? or am I misunderstanding?); and (5) a better "bus factor" which is a term that I am actually unfamiliar with (is this jargon, or is it an actual technical term/concept?). Which of these are technical in nature, or rather I should say, which of these factors has anything to do with software (in the abstract) or actual code or markup (in the concrete)? Now for my more serious follow up: just level with me; is this all bs? Do people use these frameworks because they don't know any other way to do it? Is it a code / organizational issue? Did people take the "separate all code from all HTML/CSS" advice too far and adopt it as dogma? Do people find the event model in JS to be too complex or unreliable? Is it an issue of people getting hooked on frameworks while JS was in flux so they needed the polyfills? Is it that people fell in love with TS, which naturally led to framework-itis? I feel kind of like I went to the future, and everybody rides exercise bikes everywhere they go to stay in shape, but since exercise bikes don't go anywhere, they have to be put in the bed of a pickup truck first, you know, to actually go places, but then there was a gas shortage, so it was decided to save gas we'd all carpool by putting 5 pickup trucks on a single semi-truck flatbed. Because that's just how things evolved. So now you're explaining to me why I see people riding exercise bikes on top of pickup trucks that are themselves being pulled 5 at a time on the back of a semi truck, and you're looking at me like I'm out of touch because I can't figure out why you guys can't just walk the 250 feet to the store across the street.
- chillfox 2y ago
  "bus factor" is just a side benefit of having a larger dev team. The idea is if someone gets run over by a bus then you still have someone who "knows" the code to train the replacement.
  - caspper69 2y ago
    I like it. I will add it to my lexicon. Thanks!
    - arkh 2y ago
      More exactly, the bus factor = number of people who'd have to be hit by a bus to stop development. So the bigger your bus factor, the more secure your dev.
- gigatree 2y ago
  Hilarious analogy that honestly doesn’t seem that far off. But in that reality, you probably wouldn’t be able to walk to the store, much less anywhere else, because there would be all these semi trucks driving everywhere and a road-dominated country. That’s basically a dev trying to get a job today, which means they’re just gonna focus on learning that whether it’s the best solution or not. Most devs don’t use React because it’s the best tool for the job, they use it because it’s the best tool for getting a paycheck.
  - caspper69 2y ago
    Well we can all relate to that. We've all got to eat (and stay warm & dry). I think I'm just getting to the "old man yells at cloud" stage of my career. I think of all of the things that we could have built over the years, and understand, I say this not to detract from all of the great software that has been built, but to lament the fact that devs spend so much time spinning their wheels these days (when not reinventing them, or trying to fit a square one on a race car) that we have spent so much opportunity cost that could have been the next big thing or the better version of an old thing. I would just implore people to go back and look at the history of computing, and the things we had back then (even if they were research demos or ahead-of-their-time pipe dreams), and remember that we have 100,000-1,000,000x the compute (or more) than we had when these older things were built. We can do better. And remember, not every abstraction is a useful one, not every appeal from authority should be taken as gospel, that creating software can be one of the most creative and expressive endeavors one can undertake, that there is no greater joy than seeing people use the things you build (or help build), and that there's no such thing as perfect software (but we should always strive to get as close as reasonably possible).
arkh 2y ago
> The result will be less efficient but more featureful, more polished Not sure about polished. Just see the Atlassian wasteland: lot of features, I'm sure huge and numerous teams. Ages to load a page or anything. Multiple API documentations depending on what you need. The integration between tools is mostly random. "Simple" feature asked for a decade ago never got implemented.

Zanfa 2y ago

In my experience, a lot of developers have a very limited grasp of what the browser can do for you without React. If all you know is React, everything looks like a single-page application.

emayljames 2y ago
I have a very good grasp on jQuery and a good grasp on SPA frameworks, and as soon as you cross that barrier into a complex application, jQuery is completely unsuitable in maintaining a clean state.

Tade0 2y ago

My career started in the transition period between jQuery everywhere and frameworks everywhere. Much of my work throughout the years was picking up after others who left/were fired. Main difference that I noticed between that time and the present day is that you hardly ever see unfixable monstrosities made by a lone-wolf one-man-army developer any more - at least in the Angular space, where as long as you're familiar with the convention, you'll manage. Much of that is thanks to TypeScript and the possibility to communicate to future maintainers what was your intention without writing paragraphs upon paragraphs of documentation. Of course the tradeoff is that it's all pretty heavy right now, but that's what frameworks like Svelte or SolidJS and generally the concept of Signals try to address. My take is that the moment we get Signals into the JS standard, this will all neatly fold like rows in Tetris.

arkh 2y ago

> So what am I missing? Money and resume driven development. Just being a webmaster integrating a simple design could be done by "anyone" so not paying so well anymore. So came the idea: now we're not doing websites, we're doing webapps. Suddenly fresh-out-of-school engineers can try to implement GUI concepts they vastly misunderstood, but in javascript and limited by the DOM. So that's years of work to maybe get a tenth of the performances of desktop apps: javascript interpreters to optimize, browsers, frameworks and then the apps themselves. Add the rise of smartphone apps and you even get the excuse of "we made an API for the apps, so why not use it for the frontend".

dartos 2y ago

The real reason is because it’s faster (or was in 2014) to diff 2 versions of an optimized in-memory tree than it is to use the dom API to diff live html (where any change might trigger the browser’s layout and rendering pipeline) That’s why react opted for a virtual dom. Many frameworks followed suit. We’re a decade on at this point and JavaScript runtimes are much faster