[krab]

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.

[arkh]

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

[caspper69]

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.

[gigatree]

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.

[krab]

Hey I'm not saying it's always a better way or that all apps should be developed in a certain way. But it's a trend, people are doing it for a reason and I think I understand why.

You asked whether some of the reasons are technical. Not in the sense that you can't do it in a simpler way, no.

Look at it from the perspective of a company that has a product and a few developers working on it. It's successful. Now a lot of requests pops up. Some are small, some are related to an obscure integration, maybe a few custom development requests from important customers, bug fixes... The company can now either say no to a big chunk of them (a fine choice), or, if it has money, it can hire more people.

Now, with more people, for them to be somehow effective, you need to create internal APIs and narrow down the focus areas of your teams. Backend/frontend is a separation layer, you're right. But I'd argue it's not that useful for this problem. If the backend emits HTML, what's the frontend work then? Styling? On the other hand, running a thick client in the browser that consumes an API makes it possible to decouple even the release cycle of the frontend from the backend.

Mind you, there are companies that are/were successful with a small team. But most often, the success is supported by large teams at the cost of technical perfection.

[chillfox]

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

[MrJohz]

One thing that I've learned over time is that if I can't understand why people are taking some particularly obtuse or circuitous route, then that's probably because I don't yet understand what they're doing properly. I never really understood why people would use terminal-based text editors until I tried it out for myself, and while I still have my doubts, I understand the tradeoffs much better now. If frontend development feels as insane to you as the analogy you're describing, and yet it's one of the largest sectors of the software industry, then it seems likely that you're missing something, rather than everyone else going mad.

As you say, it has always been possible to build things where the browser-based client is separated from the backend via an explicit API. Consider an application that shows you a list of flights coming into an airport. You want it to automatically update whenever new flights come in, so you need some polling to fetch that data, and some Javascript to clone elements, fill in the details of the new flights, and insert them into the DOM. But you also want sort functionality, so you need to be able to rearrange all the elements as well. And you want to filter, so you need to be able to store all the flight information internally as state, even if those flights aren't currently being shown. And your can click on each flight to expand it and view more details about that flight, so while you're rearranging and rewriting all your flights, you also need to be keeping track of which ones are currently open or not.

This was the exact application where I first realised that all the jQuery-based DOM manipulation techniques I'd learned were not going to be enough, and that there was a lot of value in having a tool that manages keeping the DOM in sync with the application state, allowing you to focus on keeping track of that state.

There are other approaches, but in my experience, they mostly come down to building your own framework, one way or another. They don't have to be as complicated as React, or as heavyweight as Angular, but you need some system in place to help you sync your state to the DOM.

I'm not establishing here that all web development needs to take this approach, just that there are a lot of situations where it is very useful. I've ended up building and maintaining variants in the above filter/sort/details/live updates system three or four times in different contexts and with different parameters, to say nothing of other, similarly complex web apps where the system works have been unmanageable without some sort of frontend framework.

Once this starts, though, you end up with frontend developers who specialise in this kind of development, and I suspect this results in a kind of siloisation, splitting web development into frontend teams and backend teams, who can each specialise further. Backend developers no longer need to worry about that occasional time where they need to tweak some CSS or JS, and frontend developers don't need to understand databases. This in turn develops into frontend developers using their tools in a wider variety of situations, because it turns out they make a lot of web development a lot easier, not just complex state management. It's a bit like how people use git to track their dotfiles. Even though git is designed to coordinate between multiple people syncing complex branches and forks together, it turns out it also works well as a simple backup and rollback mechanism.

The result is that tools like React are probably somewhat overused, but that allows developers to specialise into broad fields like "frontend" or "backend", while also remaining very general within those fields (because most work that is frontend will use similar sorts of tools and layouts, just like how MVC will apply to most backend development, regardless of language or framework). And this also isn't universal - there are still plenty of smaller, more boutique design operations that will build websites in the more traditional way.