5 ms·

Because in practice there is little value in making easier things easier. While 95% on the web are small projects, 95% of work is done on large projects. Many

by xgb84j 3y ago

Because in practice there is little value in making easier things easier. While 95% on the web are small projects, 95% of work is done on large projects. Many developers also dislike using many different frameworks, because that would require more learning. If you have to choose one technology it's better to use one where you can do everything. Not one where you can do 95% really fast, but 5% not at all. I personally always use "complex" frameworks like Angular or React because sooner or later feature requests come in, where those frameworks pay off. On average it saves time for me to always use those frameworks. That might be different for you depending on the work you do.

codeptualize 3y ago
This. Even for basic websites you benefit from some form of templating/components for example to get the nav & footer on each page.
- timeon 3y ago
  Even basic websites? It is developer vs user then. I think otherwise. I.e.: blog shouldn't be web app just because it's content management is.
  - codeptualize 3y ago
    Not at all. There are a lot of frameworks that support static exports and/or pre-rendering. Often those produce incredibly fast results, in many cases faster than hand rolled solutions. If you use a CMS you have already a templating situation and dynamic content, using a framework, or jamstack like situation is not that different, depending on the specifics it might produce faster results.
- zilti 3y ago
  You don't need a frontend framework for that. Fuck people who do. They're the reason most websites are slow as molasses on my three year old phone, despite them being very basic sites. Just stuffed to the brim with unnecessary bullshit.
  - MrJohz 3y ago
    While I agree that there is probably an overuse of frontend rendering when templating in the backend would be fine, I suspect most of the problems you see have nothing to do with that. In my experience, the number one issue with slow sites is an overuse of trackers and advertising that drags everything down.
    - docmars 3y ago
      Precisely. Using libraries / frameworks like React, Vue, Svelte, etc. adds nearly no overhead to the core functionality of whatever it is you're creating, _especially Svelte,_ since it compiles down to the bare minimum necessary to power any dynamic functionality (it doesn't ship with a complete runtime), and supports static templates and markdown out of the box. I can say with confidence that unless I royally screw something up in my component lifecycles or render loops, everything is just as snappy as ever. No latency. No lag. Just a zippy fast web app with URL/route changes that fly, fetched data populating quickly, and interactions feeling wonderful -- and that's because said apps I'm developing _aren't_ using any heavy tracking libraries. People are too quick to blame slow performance on modern view libraries, and even likelier: they've never used them before.
  - codeptualize 3y ago
    If you statically export you won't even notice, and when navigating it will actually be a lot faster when only the content is replaced.. Have you checked this is the reason? not slow network? and not ads/analytics and blocking assets? That's not exclusive to frameworks btw, and probably less likely as most optimize these things for you. The website that is linked originally has a bunch of blocking assets.. lighthouse score is not amazing either. Just like the original article, you might want to test your assumptions a bit more.
squidbeak 3y ago
Do you have any data to support that 95% claim? As big as FAANG and other huge development teams are, it seems to me it's still only the tip of the pyramid, with the overwhelming majority of people in the industry working full time on small or midsized projects. It'd be interesting to see some concrete info on it.
- josephg 3y ago
  I suspect even at Google a lot more than 5% of effort goes into small to midsized projects. Bazel, ninja, protobuf, grpc, the API documentation website for Gmail, VP9, the Google transcode api, takeout, various corp network tools & services and so on. The big projects are of course important. But even chrome needs a simple little website with a download link.
  - xgb84j 3y ago
    That's a good point. I personally always like Angular and React, because even with most simple projects there is this one feature that is so ridiculously complicated that making it slightly easier to develop and maintain is important to me. I'll gladly write thousands of lines of boilerplate just so I make it easier for me to succeed in developing this one endboss feature. If you do not have at least this one insane feature, Angular and React are definitely overkill.
    - marcus_holmes 3y ago
      I always see this as a communication/management failure. Product folks come up with features. They have no idea how hard those features are to implement. Which in a way is a blessing; they'll come up with the best features if they don't have to consider the implementation details. But because there are always trade-offs in implementation they also don't understand those. A feature that is super difficult to implement, and that therefore has trade-offs on speed, maintainability, etc, should be communicated back to the product folks. If you have to move to a framework just to implement this one feature, then that is either because this one feature is really badly or over-designed, or that one feature is absolutely critical to the entire site, which is stupidly rare and again a symptom that someone hasn't really thought this through enough. The failure in communication is usually "you're just the nerd pushing the nerd buttons, you don't have valid opinions on product design" which is a cause of so, so many problems in our industry.
andybak 3y ago
The "big" projects can do what the hell they want. They can afford to throw a ton of money at a problem. The small projects are where the people I care about are struggling.
- ceuk 3y ago
  Big project =/= Big company e.g. WhatsApp back before the acquisition Making it easier for people to build big, complex apps doesn't favour large organisations with lots of resources. The opposite in fact.
  - andybak 3y ago
    nb I'm not agreeing with your original hypothesis. However I'm taking about even lower down the food chain than this.
- MrJohz 3y ago
  Are people really struggling at that level, though? It has never been easier to write a complex page with minimal Javascript - there are more and more HTML elements that do what you expect (expandos and modals as some recent examples), Javascript is cleaner and more consistent across browsers (you really don't need jQuery anymore), and CSS is more powerful but also so much simpler (flex+grid solve so many problems). Then if that's not enough, you've got things like HTMX if you're keen on doing everything in terms of html templating, you've got tools like Svelte if you want an isolated chunk of dynamic UI in a mostly static page, you've got bundlers like Vite that just work without any configuration if you get to the point where you need a build step, and you've got a multitude of lightweight frameworks for the next step. And on top of that, pretty much all the old ways still work. The browser is an incredibly stable environment! Outside of a handful of security-related removals, if it got into a mainstream browser, without a feature flag or an explicit "experimental" warning, it's pretty much there for life. So if you want to go back to the old ways, there's not much stopping you - but a whole bunch of quality-of-life development improvements along the way to make things even easier than they were back then.
  - 3y ago
RunSet 3y ago
> If you have to choose one technology it's better to use one where you can do everything. Not one where you can do 95% really fast, but 5% not at all. > I personally always use "complex" frameworks like Angular or React because sooner or later feature requests come in, where those frameworks pay off. On average it saves time for me to always use those frameworks. I wonder whether they ever pay off. First, I don't believe the frameworks you mention really, as you suggest, enable the last 5% of functionality that would otherwise be impossible. No, those frameworks are written in the same language they work in, which means that strictly speaking they do not enable any new functionality. Second, whatever ease / speed of development you use must be weighed against the additional cost borne by the project's users. The time you save (that you might otherwise spend learning to achieve the same result without the framework) could be less than the time spent collectively by users waiting for the framework to load.
up2isomorphism 3y ago
“95% work is done on large project” this perception might just because you have chosen complex frameworks. Remember google and facebook starts with no frameworks at all. Are they small projects? No.

by xgb84j 3y ago

codeptualize 3y ago

This. Even for basic websites you benefit from some form of templating/components for example to get the nav & footer on each page.

timeon 3y ago
Even basic websites? It is developer vs user then. I think otherwise. I.e.: blog shouldn't be web app just because it's content management is.
- codeptualize 3y ago
  Not at all. There are a lot of frameworks that support static exports and/or pre-rendering. Often those produce incredibly fast results, in many cases faster than hand rolled solutions. If you use a CMS you have already a templating situation and dynamic content, using a framework, or jamstack like situation is not that different, depending on the specifics it might produce faster results.
zilti 3y ago
You don't need a frontend framework for that. Fuck people who do. They're the reason most websites are slow as molasses on my three year old phone, despite them being very basic sites. Just stuffed to the brim with unnecessary bullshit.
- MrJohz 3y ago
  While I agree that there is probably an overuse of frontend rendering when templating in the backend would be fine, I suspect most of the problems you see have nothing to do with that. In my experience, the number one issue with slow sites is an overuse of trackers and advertising that drags everything down.
  - docmars 3y ago
    Precisely. Using libraries / frameworks like React, Vue, Svelte, etc. adds nearly no overhead to the core functionality of whatever it is you're creating, _especially Svelte,_ since it compiles down to the bare minimum necessary to power any dynamic functionality (it doesn't ship with a complete runtime), and supports static templates and markdown out of the box. I can say with confidence that unless I royally screw something up in my component lifecycles or render loops, everything is just as snappy as ever. No latency. No lag. Just a zippy fast web app with URL/route changes that fly, fetched data populating quickly, and interactions feeling wonderful -- and that's because said apps I'm developing _aren't_ using any heavy tracking libraries. People are too quick to blame slow performance on modern view libraries, and even likelier: they've never used them before.
- codeptualize 3y ago
  If you statically export you won't even notice, and when navigating it will actually be a lot faster when only the content is replaced.. Have you checked this is the reason? not slow network? and not ads/analytics and blocking assets? That's not exclusive to frameworks btw, and probably less likely as most optimize these things for you. The website that is linked originally has a bunch of blocking assets.. lighthouse score is not amazing either. Just like the original article, you might want to test your assumptions a bit more.

squidbeak 3y ago

Do you have any data to support that 95% claim? As big as FAANG and other huge development teams are, it seems to me it's still only the tip of the pyramid, with the overwhelming majority of people in the industry working full time on small or midsized projects. It'd be interesting to see some concrete info on it.

josephg 3y ago
I suspect even at Google a lot more than 5% of effort goes into small to midsized projects. Bazel, ninja, protobuf, grpc, the API documentation website for Gmail, VP9, the Google transcode api, takeout, various corp network tools & services and so on. The big projects are of course important. But even chrome needs a simple little website with a download link.
- xgb84j 3y ago
  That's a good point. I personally always like Angular and React, because even with most simple projects there is this one feature that is so ridiculously complicated that making it slightly easier to develop and maintain is important to me. I'll gladly write thousands of lines of boilerplate just so I make it easier for me to succeed in developing this one endboss feature. If you do not have at least this one insane feature, Angular and React are definitely overkill.
  - marcus_holmes 3y ago
    I always see this as a communication/management failure. Product folks come up with features. They have no idea how hard those features are to implement. Which in a way is a blessing; they'll come up with the best features if they don't have to consider the implementation details. But because there are always trade-offs in implementation they also don't understand those. A feature that is super difficult to implement, and that therefore has trade-offs on speed, maintainability, etc, should be communicated back to the product folks. If you have to move to a framework just to implement this one feature, then that is either because this one feature is really badly or over-designed, or that one feature is absolutely critical to the entire site, which is stupidly rare and again a symptom that someone hasn't really thought this through enough. The failure in communication is usually "you're just the nerd pushing the nerd buttons, you don't have valid opinions on product design" which is a cause of so, so many problems in our industry.

andybak 3y ago

The "big" projects can do what the hell they want. They can afford to throw a ton of money at a problem. The small projects are where the people I care about are struggling.

ceuk 3y ago
Big project =/= Big company e.g. WhatsApp back before the acquisition Making it easier for people to build big, complex apps doesn't favour large organisations with lots of resources. The opposite in fact.
- andybak 3y ago
  nb I'm not agreeing with your original hypothesis. However I'm taking about even lower down the food chain than this.
MrJohz 3y ago
Are people really struggling at that level, though? It has never been easier to write a complex page with minimal Javascript - there are more and more HTML elements that do what you expect (expandos and modals as some recent examples), Javascript is cleaner and more consistent across browsers (you really don't need jQuery anymore), and CSS is more powerful but also so much simpler (flex+grid solve so many problems). Then if that's not enough, you've got things like HTMX if you're keen on doing everything in terms of html templating, you've got tools like Svelte if you want an isolated chunk of dynamic UI in a mostly static page, you've got bundlers like Vite that just work without any configuration if you get to the point where you need a build step, and you've got a multitude of lightweight frameworks for the next step. And on top of that, pretty much all the old ways still work. The browser is an incredibly stable environment! Outside of a handful of security-related removals, if it got into a mainstream browser, without a feature flag or an explicit "experimental" warning, it's pretty much there for life. So if you want to go back to the old ways, there's not much stopping you - but a whole bunch of quality-of-life development improvements along the way to make things even easier than they were back then.
- 3y ago

RunSet 3y ago

> If you have to choose one technology it's better to use one where you can do everything. Not one where you can do 95% really fast, but 5% not at all. > I personally always use "complex" frameworks like Angular or React because sooner or later feature requests come in, where those frameworks pay off. On average it saves time for me to always use those frameworks. I wonder whether they ever pay off. First, I don't believe the frameworks you mention really, as you suggest, enable the last 5% of functionality that would otherwise be impossible. No, those frameworks are written in the same language they work in, which means that strictly speaking they do not enable any new functionality. Second, whatever ease / speed of development you use must be weighed against the additional cost borne by the project's users. The time you save (that you might otherwise spend learning to achieve the same result without the framework) could be less than the time spent collectively by users waiting for the framework to load.

up2isomorphism 3y ago

“95% work is done on large project” this perception might just because you have chosen complex frameworks. Remember google and facebook starts with no frameworks at all. Are they small projects? No.