6 ms·

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 ef

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

by krab 2y ago

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.