5 ms·

Majority of apps are small, yet they load tens of megabytes of javascript and it's becoming the unwanted norm. You can't browse many blogs without enabled javas

Majority of apps are small, yet they load tens of megabytes of javascript and it's becoming the unwanted norm. You can't browse many blogs without enabled javascript for no other reason than personal data harvesting needs.

zdragnar 3y ago
Those are very different issues. React, Angular, Ember and co don't help you with your data harvesting one bit.
- spinningslate 3y ago
  Agree they're different, but it's important not to miss the first point: > Majority of apps are small I'd like to see some data on it, but intuitively that resonates. The lighthouses of UI frameworks - notably React & Angular - emerged from the needs of big apps, with 100s of people, and structures that delineate front-end and back-end teams. The organisations behind the frameworks - Google, Meta - are very influential in setting industry direction. So those frameworks become "the way to do UI". That doctrine spreads through the community, and the context of origin and use is occluded. If htmx or similar drives a re-think then that's healthy to me. My own experience is with lots of comparatively small apps. Plain old server-side rendering hits the 80/20 for most, and something like htmx might move that indicatively to ~90/10. Which is attractive because it means 1 tech stack and comparatively less requirement for hard delineation of skills in dev teams. It's not saying "throw away React/Angular/..., you never need them". There are clearly situations where they're a good fit. Where fit means both organisational and technical. But they're not a good fit in every case.
  - zdragnar 3y ago
    React actually wasn't built for SPAs; Facebook built it for widgets on a server-rendered page. That is why it has no built in SPA features, like routing, data management, data fetching or other batteries a SPA or PWA might want. Conveniently, it provided a very nice set of primitive and composable APIs so that all of those features can be added on in a way that fits naturally, such as react-router and the rest of the ecosystem. That's all driven by the community, not the "lighthouse", so to speak. AngularJS likewise didn't require using the router, and in fact can just as easily run multiple instances on a single page. I haven't used Angular in years, so I don't know the story there. Same goes for Vue, but that's hardly backed by a "lighthouse". I don't disagree that there's no use for HTMX or server rendering of html. Not everything needs to be a SPA. The problem is the argument is a whole lot less convincing when presented with a lot of incorrect facts
ssijak 3y ago
You can use React and fullstack React frameworks and ship 0 or almost 0 JS to the browser and have a working app.
cqqxo4zV46cp 3y ago
Very much sounds like you’re conflating multiple issues. This isn’t just “things that you don’t like about the internet”.

zdragnar 3y ago

Those are very different issues. React, Angular, Ember and co don't help you with your data harvesting one bit.

spinningslate 3y ago
Agree they're different, but it's important not to miss the first point: > Majority of apps are small I'd like to see some data on it, but intuitively that resonates. The lighthouses of UI frameworks - notably React & Angular - emerged from the needs of big apps, with 100s of people, and structures that delineate front-end and back-end teams. The organisations behind the frameworks - Google, Meta - are very influential in setting industry direction. So those frameworks become "the way to do UI". That doctrine spreads through the community, and the context of origin and use is occluded. If htmx or similar drives a re-think then that's healthy to me. My own experience is with lots of comparatively small apps. Plain old server-side rendering hits the 80/20 for most, and something like htmx might move that indicatively to ~90/10. Which is attractive because it means 1 tech stack and comparatively less requirement for hard delineation of skills in dev teams. It's not saying "throw away React/Angular/..., you never need them". There are clearly situations where they're a good fit. Where fit means both organisational and technical. But they're not a good fit in every case.
- zdragnar 3y ago
  React actually wasn't built for SPAs; Facebook built it for widgets on a server-rendered page. That is why it has no built in SPA features, like routing, data management, data fetching or other batteries a SPA or PWA might want. Conveniently, it provided a very nice set of primitive and composable APIs so that all of those features can be added on in a way that fits naturally, such as react-router and the rest of the ecosystem. That's all driven by the community, not the "lighthouse", so to speak. AngularJS likewise didn't require using the router, and in fact can just as easily run multiple instances on a single page. I haven't used Angular in years, so I don't know the story there. Same goes for Vue, but that's hardly backed by a "lighthouse". I don't disagree that there's no use for HTMX or server rendering of html. Not everything needs to be a SPA. The problem is the argument is a whole lot less convincing when presented with a lot of incorrect facts

ssijak 3y ago

You can use React and fullstack React frameworks and ship 0 or almost 0 JS to the browser and have a working app.

cqqxo4zV46cp 3y ago

Very much sounds like you’re conflating multiple issues. This isn’t just “things that you don’t like about the internet”.