6 ms·

> Perhaps you can write a tiny web app that loads instantly and still retains a full set of features, but most of the world cannot. I've long been skeptical of

> Perhaps you can write a tiny web app that loads instantly and still retains a full set of features, but most of the world cannot. I've long been skeptical of this line of thinking emanating from major thick client JS framework authors. I think they underestimate what people are capable of. > Over time, Ember will become like gcc -O3 for web apps, intelligently optimizing them and delivering them as fast as possible, piece by piece, to your user’s browser. I've been observing these trends for years and what I'm seeing is this: ever since these new thick client JS frameworks became so trendy, web performance has dramatically decreased, not increased. This one-two combo punch of framework authors condescending their users as "our target audience is devs who can't hand code" while simultaneously promising performance that's just as good as hand coding and perpetually failing to deliver is a toxic stew that is crippling web performance.

twblalock 10y ago
Which frameworks claim to target "devs who can't hand code"?
- mikekchar 10y ago
  To a certain extent all of them do. "devs who can't code" is hyperbole, but the whole point of a framework is to provide a framework that allows you to fill in the details without building all the plumbing underneath. This is distinct from a reuse library where you write the plumbing while someone else has written the details of some functionality. Often you get these super-frameworks that do all the plumbing for you and throw in veritable kitchen sinks of reuse libraries with the intent that you glue it all together to match your business logic. Very frequently this is the stated aim of these super-frameworks -- reason only about your business logic and leave all the details to us. It is a compelling story, but usually one that doesn't have a happy ending. The devil is in the details. Your business logic usually requires you to hack something that the framework/library authors didn't anticipate. That hack leads to 10 more as you route around the "it isn't supposed to be done this way, but what could we do" mess. Over time it degenerates. Then you hire old guys like me who are willing to accept money to grind out all the problems without quitting in a huff and running to the new shiny ;-) (only because our legs are tired from running after shinies when we were young). There are lots of reuse libraries and even minimal frameworks who specifically say, "You're going to have to wire this up yourself. We're not going to make it easy for you. That's because we can't anticipate the problems you will run into and we are trying to give you as much space as possible to figure out how it should be done". I like frameworks and libraries like that. I don't like the other ones, even though they generally pay my salary.
sotojuan 10y ago
Unfortunately a lot of us in HN make our living writing thick clients that ultimately perform worse than server-rendered apps with little benefit. It's just too easy to find a front end dev job that pays well, at least where I live.
- haimez 10y ago
  Maybe you should find any of the websites that profit from faster load times and argue the business value. Because that's most of the places.
  - mercer 10y ago
    I've suggested just that at multiple companies, and even if the business value was acknowledged, the usual (informal) response boiled down to "it won't impress my boss as much as new feature <x>, and there's no reason for me to argue with them about this". And so we'd put another ad somewhere on the page to increase revenue, instead of decreasing the page load time down from 5-10 seconds with some truly trivial low-hanging fruit type adjustments (lazy-loading anything but the 'core' images, etc.). Or we'd do another redesign. Or add a widget somewhere. What bothers me most is that these kinds of jobs were generally the highest paying and lowest in stress and 'friction' with the client. And I'd do them, telling myself that with the money I was 'saving up future time', all the while feeling incredibly depressed whenever I came home from work or had a moment to think about the current state of my life. I always pitied the (shockingly high) number of employees in these companies, predominantly managers, who absolutely hated their jobs and constantly talked about 'one day I'll quit and do <x>' while never doing it because, well, the money and stability. Ever since I realized I was basically doing the vey same thing, I've been trying a little harder to find a balance between 'saving up'/stability and enjoying my day to day. And in my field that should be possible.
lcw 10y ago
As software developers I think its easy for us to jump on this bandwagon that if you hand code all the things then you can make a super fast site and the internet would be such a wonderful place; and then thinking its all those heathen script kiddies using these junk JS frameworks slowing our browsers down. I know I'm guilty of this line of thinking so I'm not judging, but I also think many companies big and small are actually making rather rational decisions when it comes to site performance and the use of JS frameworks. For instance where I work its common for us to knowingly slow down performance on a given page because the feature makes the company X money that offsets the performance loss and the time and money it would take to make it perform better. This compounds over time, but all along the way the business is making reasonable decisions. Frameworks like Ember allow great developers to add powerful features quickly for the businesses to monetize on. I don't think we should write off performance initiatives in these frameworks just because we know they won't live up to a vanilla JS implementation. I also don't think its fair to disparage the movement of thick JS frameworks on these grounds. Many of start-up's and large companies wouldn't be able to lift off products as quickly as they have without the head starts that frameworks such as Ember have given them.
- Bahamut 10y ago
  I think we see many here pump up their abilities that they could homebrew an excellent implementation of [insert special feature] better than [insert framework/library]. Truth is, I don't trust most software engineers to do that without a vetting of some sorts, and open source software provides that. I consider myself pretty good, having done some serious open source work in the frontend world, but if I had to homebrew a framework like React and all of the pieces to make it work (or Angular, even with my intricate knowledge of it), I would not be able to match everything with performance, flexibility, and good API signatures. Most developers are not experienced with thinking about all 3 factors in tandem, and it shows with the code that is written on a typical basis.
- kethinov 10y ago
  The bandwagoning is disproportionately on the side of those leaning towards big frameworks. Look, I've been on the inside of large companies making framework choices and rarely is the decision rational. Often it's based on what's popular and based on the assumption that popular things are popular for good reasons. Biased metrics get thrown around to justify preconceived notions, and off to the races we go. Years later, everyone sees the old stack as "old and outdated" and a strong desire to throw it all away and rewrite it with the new hotness takes hold. Then the entire irrational process repeats itself. I'm not saying the big trendy thick client JS frameworks are the wrong tool for every job. But in my experience they do seem to be the wrong tool for an alarming number of jobs they are presently being used for. And I'm not just spitting rhetoric here. I'm more than happy to put my money where my mouth is. If you want to know specifically when I think a big thick client JS framework might be the right tool for the job and when it probably isn't, this article does a good job of outlining that: https://www.sitepoint.com/javascript-dependency-backlash-myth-busting-progressive-enhancement/ https://www.sitepoint.com/javascript-dependency-backlash-myt... As for the tradeoff associated with developer productivity vs. performance, there is some validity to that. However, I think people overestimate the developer productivity gains the frameworks offer. You only get productivity gains if your whole team is already fully trained on the framework. And in addition to the performance tradeoffs, you also risk your codebase having a shorter lifespan because the framework may make breaking changes to its API some day (e.g. Angular 1 -> Angular 2), whereas a vanilla JS implementation that relies on smaller, single purpose JS libraries will age considerably better.
jeanlucas 10y ago
> I've been observing these trends for years and what I'm seeing is this: ever since these new thick client JS frameworks became so trendy, web performance has dramatically decreased, not increased. I am in the Emberjs community, I do not observe this in that framework.
- kethinov 10y ago
  Well I have observed it. I've worked on many projects that used one of the big frameworks (including Ember.js projects) that would've been better off with vanilla JS and a collection of small JS libraries instead. I'm not going to name names, but they're out there. It's a tool that does get misused, like any other.
  - andylei 10y ago
    yes, but there are plenty of projects that would not be better off with vanilla js
    - scaryclam 10y ago
      And there are also plenty that would be better without any js at all
  - zackthehuman 10y ago
    Recent releases of Ember actually reduced the output size (sometimes in the high double-digit percent) and Glimmer 2 improved rendering performance. Sometimes the needle moves back after work internal to the framework.
    - kethinov 10y ago
      Yep. And to play devil's advocate for a moment, I've really been impressed with fastboot too. I think it's a great idea. Overall things are certainly heading in the right direction, but I just wish we hand't sunk so low from a performance and robustness (progressive enhancement) standpoint first.
Bombthecat 10y ago
Yeah! It feels like we are in the 90s again! Where you got flash videos but only a 54k connection. It is not faster...At all. just. slower and slower..
di4na 10y ago
From my pov : welcome to the fact that a huge part of the web still is handled by tons of never finished perl script and old Js stuff, that had to scale and evolve despite noone making it scale and evolve. It is closer to that. We got a ton of new things, but never the budget nor time to go fix the old thing.
stupidcar 10y ago
Purely anecdotal. Got any statistics to back up your opinions?
- kethinov 10y ago
  If you google for stats on the average size of webpages these days, you can see a bunch of studies people have done which show the average file size of website page loads is increasing. Images are the biggest offender, but JS bloat is a significant factor as well. FWIW this is generally common knowledge within the webdev community. People debate whether or not it's a problem, not whether or not it's happening.
sangnoir 10y ago
>> Perhaps you can write a tiny web app that loads instantly and still retains a full set of features, but most of the world cannot. > I've long been skeptical of this line of thinking emanating from major thick client JS framework authors. I think they underestimate what people are capable of Sometimes even when you can, you shouldn't. Any reasonably-sized organisation will have churn; new developers will have to ramp-up and it will take longer to do so on a hand-coded framework with all it's idiosyncrasies. I'll take Ember over Random Jim's framework, even though he is technically brilliant.
- gizmogwai 10y ago
  Thing is, by the time you have to take back this application for maintenance, chances are high that the then mainstream framework will be outdated, newcomers won't even know it, the doc will have vanished in a poor "let's move to this new shiny TLD", and still the business logic of the application will be vastly undocumented as well. I was on your side for a long time, but I've come to appreciate a minimalist, simple, well documented in-house framework over a hype-driven "solve-all-the-thing" one, even free and with a currently big community.
Silhouette 10y ago
>> Perhaps you can write a tiny web app that loads instantly and still retains a full set of features, but most of the world cannot. > I've long been skeptical of this line of thinking emanating from major thick client JS framework authors. I think they underestimate what people are capable of. I am also skeptical, but for a slightly different reason. I believe the original statement from the article is true today. I also believe things would be very different if the same web developers we have today spent less time learning new frameworks every five minutes and more time learning the fundamentals of the underlying technologies (JS, HTTP, and so on), broader skills like programming and UI design, and more professional practices like standardisation and backward and forward compatibility. So many tools in web development today are merely papering over the cracks that other tools unwittingly created in the first place. The advocacy of using these kinds of tools to be more future-proof or standardised than building with solid fundamentals is one of the greatest ironies in programming history.

twblalock 10y ago

Which frameworks claim to target "devs who can't hand code"?

mikekchar 10y ago
To a certain extent all of them do. "devs who can't code" is hyperbole, but the whole point of a framework is to provide a framework that allows you to fill in the details without building all the plumbing underneath. This is distinct from a reuse library where you write the plumbing while someone else has written the details of some functionality. Often you get these super-frameworks that do all the plumbing for you and throw in veritable kitchen sinks of reuse libraries with the intent that you glue it all together to match your business logic. Very frequently this is the stated aim of these super-frameworks -- reason only about your business logic and leave all the details to us. It is a compelling story, but usually one that doesn't have a happy ending. The devil is in the details. Your business logic usually requires you to hack something that the framework/library authors didn't anticipate. That hack leads to 10 more as you route around the "it isn't supposed to be done this way, but what could we do" mess. Over time it degenerates. Then you hire old guys like me who are willing to accept money to grind out all the problems without quitting in a huff and running to the new shiny ;-) (only because our legs are tired from running after shinies when we were young). There are lots of reuse libraries and even minimal frameworks who specifically say, "You're going to have to wire this up yourself. We're not going to make it easy for you. That's because we can't anticipate the problems you will run into and we are trying to give you as much space as possible to figure out how it should be done". I like frameworks and libraries like that. I don't like the other ones, even though they generally pay my salary.

sotojuan 10y ago

Unfortunately a lot of us in HN make our living writing thick clients that ultimately perform worse than server-rendered apps with little benefit. It's just too easy to find a front end dev job that pays well, at least where I live.

haimez 10y ago
Maybe you should find any of the websites that profit from faster load times and argue the business value. Because that's most of the places.
- mercer 10y ago
  I've suggested just that at multiple companies, and even if the business value was acknowledged, the usual (informal) response boiled down to "it won't impress my boss as much as new feature <x>, and there's no reason for me to argue with them about this". And so we'd put another ad somewhere on the page to increase revenue, instead of decreasing the page load time down from 5-10 seconds with some truly trivial low-hanging fruit type adjustments (lazy-loading anything but the 'core' images, etc.). Or we'd do another redesign. Or add a widget somewhere. What bothers me most is that these kinds of jobs were generally the highest paying and lowest in stress and 'friction' with the client. And I'd do them, telling myself that with the money I was 'saving up future time', all the while feeling incredibly depressed whenever I came home from work or had a moment to think about the current state of my life. I always pitied the (shockingly high) number of employees in these companies, predominantly managers, who absolutely hated their jobs and constantly talked about 'one day I'll quit and do <x>' while never doing it because, well, the money and stability. Ever since I realized I was basically doing the vey same thing, I've been trying a little harder to find a balance between 'saving up'/stability and enjoying my day to day. And in my field that should be possible.

lcw 10y ago

As software developers I think its easy for us to jump on this bandwagon that if you hand code all the things then you can make a super fast site and the internet would be such a wonderful place; and then thinking its all those heathen script kiddies using these junk JS frameworks slowing our browsers down. I know I'm guilty of this line of thinking so I'm not judging, but I also think many companies big and small are actually making rather rational decisions when it comes to site performance and the use of JS frameworks. For instance where I work its common for us to knowingly slow down performance on a given page because the feature makes the company X money that offsets the performance loss and the time and money it would take to make it perform better. This compounds over time, but all along the way the business is making reasonable decisions. Frameworks like Ember allow great developers to add powerful features quickly for the businesses to monetize on. I don't think we should write off performance initiatives in these frameworks just because we know they won't live up to a vanilla JS implementation. I also don't think its fair to disparage the movement of thick JS frameworks on these grounds. Many of start-up's and large companies wouldn't be able to lift off products as quickly as they have without the head starts that frameworks such as Ember have given them.

Bahamut 10y ago
I think we see many here pump up their abilities that they could homebrew an excellent implementation of [insert special feature] better than [insert framework/library]. Truth is, I don't trust most software engineers to do that without a vetting of some sorts, and open source software provides that. I consider myself pretty good, having done some serious open source work in the frontend world, but if I had to homebrew a framework like React and all of the pieces to make it work (or Angular, even with my intricate knowledge of it), I would not be able to match everything with performance, flexibility, and good API signatures. Most developers are not experienced with thinking about all 3 factors in tandem, and it shows with the code that is written on a typical basis.
kethinov 10y ago
The bandwagoning is disproportionately on the side of those leaning towards big frameworks. Look, I've been on the inside of large companies making framework choices and rarely is the decision rational. Often it's based on what's popular and based on the assumption that popular things are popular for good reasons. Biased metrics get thrown around to justify preconceived notions, and off to the races we go. Years later, everyone sees the old stack as "old and outdated" and a strong desire to throw it all away and rewrite it with the new hotness takes hold. Then the entire irrational process repeats itself. I'm not saying the big trendy thick client JS frameworks are the wrong tool for every job. But in my experience they do seem to be the wrong tool for an alarming number of jobs they are presently being used for. And I'm not just spitting rhetoric here. I'm more than happy to put my money where my mouth is. If you want to know specifically when I think a big thick client JS framework might be the right tool for the job and when it probably isn't, this article does a good job of outlining that: https://www.sitepoint.com/javascript-dependency-backlash-myth-busting-progressive-enhancement/ https://www.sitepoint.com/javascript-dependency-backlash-myt... As for the tradeoff associated with developer productivity vs. performance, there is some validity to that. However, I think people overestimate the developer productivity gains the frameworks offer. You only get productivity gains if your whole team is already fully trained on the framework. And in addition to the performance tradeoffs, you also risk your codebase having a shorter lifespan because the framework may make breaking changes to its API some day (e.g. Angular 1 -> Angular 2), whereas a vanilla JS implementation that relies on smaller, single purpose JS libraries will age considerably better.

jeanlucas 10y ago

> I've been observing these trends for years and what I'm seeing is this: ever since these new thick client JS frameworks became so trendy, web performance has dramatically decreased, not increased. I am in the Emberjs community, I do not observe this in that framework.

kethinov 10y ago
Well I have observed it. I've worked on many projects that used one of the big frameworks (including Ember.js projects) that would've been better off with vanilla JS and a collection of small JS libraries instead. I'm not going to name names, but they're out there. It's a tool that does get misused, like any other.
- andylei 10y ago
  yes, but there are plenty of projects that would not be better off with vanilla js
  - scaryclam 10y ago
    And there are also plenty that would be better without any js at all
- zackthehuman 10y ago
  Recent releases of Ember actually reduced the output size (sometimes in the high double-digit percent) and Glimmer 2 improved rendering performance. Sometimes the needle moves back after work internal to the framework.
  - kethinov 10y ago
    Yep. And to play devil's advocate for a moment, I've really been impressed with fastboot too. I think it's a great idea. Overall things are certainly heading in the right direction, but I just wish we hand't sunk so low from a performance and robustness (progressive enhancement) standpoint first.

Bombthecat 10y ago

Yeah! It feels like we are in the 90s again! Where you got flash videos but only a 54k connection. It is not faster...At all. just. slower and slower..

di4na 10y ago

From my pov : welcome to the fact that a huge part of the web still is handled by tons of never finished perl script and old Js stuff, that had to scale and evolve despite noone making it scale and evolve. It is closer to that. We got a ton of new things, but never the budget nor time to go fix the old thing.

stupidcar 10y ago

Purely anecdotal. Got any statistics to back up your opinions?

kethinov 10y ago
If you google for stats on the average size of webpages these days, you can see a bunch of studies people have done which show the average file size of website page loads is increasing. Images are the biggest offender, but JS bloat is a significant factor as well. FWIW this is generally common knowledge within the webdev community. People debate whether or not it's a problem, not whether or not it's happening.

sangnoir 10y ago

gizmogwai 10y ago
Thing is, by the time you have to take back this application for maintenance, chances are high that the then mainstream framework will be outdated, newcomers won't even know it, the doc will have vanished in a poor "let's move to this new shiny TLD", and still the business logic of the application will be vastly undocumented as well. I was on your side for a long time, but I've come to appreciate a minimalist, simple, well documented in-house framework over a hype-driven "solve-all-the-thing" one, even free and with a currently big community.

Silhouette 10y ago

>> Perhaps you can write a tiny web app that loads instantly and still retains a full set of features, but most of the world cannot. > I've long been skeptical of this line of thinking emanating from major thick client JS framework authors. I think they underestimate what people are capable of. I am also skeptical, but for a slightly different reason. I believe the original statement from the article is true today. I also believe things would be very different if the same web developers we have today spent less time learning new frameworks every five minutes and more time learning the fundamentals of the underlying technologies (JS, HTTP, and so on), broader skills like programming and UI design, and more professional practices like standardisation and backward and forward compatibility. So many tools in web development today are merely papering over the cracks that other tools unwittingly created in the first place. The advocacy of using these kinds of tools to be more future-proof or standardised than building with solid fundamentals is one of the greatest ironies in programming history.