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.
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-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.
Google would go bankrupt from a combination of the insane salaries they'd have to pay and the inability to ever fill jobs if its entire stack was based on Haskell.
My point was that unless you're a small startup with very specific need for the tech stack you're using, you probably shouldn't be hiring based on whether the candidate knows certain framework, because that can be learned quickly, as long as the developer has solid foundation.
Many frameworks deeply affect how the code is written and have very specific boilerplate, custom templating and such. And some frameworks simply offer means of doing some things in an easier, usually specific, way with the relevant language.
In my experience it is also highly relevant how your thoughts on architecture match up to the framework's. I'd say you can happen to have a solid affinity for the way a framework is thought out. But in general, I'd agree, overnight is generally not sufficient for anything proper :)
Before trying React/Redux, I was against js frameworks too. They all seemed to add a whole extra layer of unnecessary mutable state to keep in sync, and required lots of cruft and duplication. Just give me coffeescript, underscore, and jquery, thank you very much. I composed nice little modular components that latched on to server-generated html, kept state to a minimum, and used a global event bus to deal with interdependence. It had some warts, but it got the job done and scaled up reasonably well. It certainly beat procedural jquery spaghetti and I thought it beat the current crop of frameworks too--what it lacked in polish, community, and standardization were made up for by modularity and simplicity.
Of course, then I discovered React, and more recently, Redux. I immediately realized that it was the culmination of what I'd been trying to do all along. It was basically the same idea, but battle-tested, standardized, and infinitely more elegant. So why wouldn't I use it? Sure, there was a learning curve while I got used to other people's way of thinking about and expressing these concepts. Rather than designing the system myself and knowing it like the back of my hand, I had to learn a whole new vocabulary and toolchain. But it was so, so worth it in the end. I'm still building apps with an architecture I believe in, and I get all the benefits of a well-supported framework to boot.
So, to finally get back to the central point: never once was popularity an important factor in my decisions, and I suspect this is also the case for many many others who adopt one framework or another. Not everything that's popular is only popular due to a bandwagon effect--sometimes the shiny new thing really is a big step forward.
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.
It is closer to that. We got a ton of new things, but never the budget nor time to go fix the old thing.
> 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.
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.
I am in the Emberjs community, I do not observe this in that framework.
> 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.
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.
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.
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.