5 ms·

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 ch

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.

lcw 10y ago
I think your points have some weight to them. Specifically I 100% agree that JS frameworks are at times misused, and in lots of situations are completely unnecessary. However, my point is the valid use cases for these JS frameworks warrant the open source investment that many community members are pouring into them.
- kethinov 10y ago
  That I completely agree with. And to be clear, while I disagree with some of what Tom Dale says sometimes, he's a very talented guy. LinkedIn is lucky to get him and I think it's entirely a good thing to see another prominent open source project get some corporate support.
addicted 10y ago
Large companies almost by definition need to hire a lot of developers. Seems to me that it would be an absolutely rational and sensible choice to use popular frameworks keeping those constraints in mind. 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.
- Ar-Curunir 10y ago
  Probably not; people would just learn Haskell.
  - sjg007 10y ago
    And that would be so amazingly beautiful.
- cocktailpeanuts 10y ago
  Google will hire people who can write good vanilla JS code, not someone who's good at the latest fad js framework. In fact, if you're good at writing vanilla JS, you would probably pick up these frameworks overnight.
  - yoz-y 10y ago
    Pickup a framework overnight results in shoehorning your current knowledge into the framework and late night rants about how the framework sucks.
    - lawik 10y ago
      I'd say it depends on the framework a lot. 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 :)
danenania 10y ago
People focus on frameworks and popularity, but as someone who builds a lot of complex front ends, what really matters to me is architecture--architectural simplicity and architectural scalability. 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.

lcw 10y ago

I think your points have some weight to them. Specifically I 100% agree that JS frameworks are at times misused, and in lots of situations are completely unnecessary. However, my point is the valid use cases for these JS frameworks warrant the open source investment that many community members are pouring into them.

kethinov 10y ago
That I completely agree with. And to be clear, while I disagree with some of what Tom Dale says sometimes, he's a very talented guy. LinkedIn is lucky to get him and I think it's entirely a good thing to see another prominent open source project get some corporate support.

addicted 10y ago

Large companies almost by definition need to hire a lot of developers. Seems to me that it would be an absolutely rational and sensible choice to use popular frameworks keeping those constraints in mind. 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.

Ar-Curunir 10y ago
Probably not; people would just learn Haskell.
- sjg007 10y ago
  And that would be so amazingly beautiful.
cocktailpeanuts 10y ago
Google will hire people who can write good vanilla JS code, not someone who's good at the latest fad js framework. In fact, if you're good at writing vanilla JS, you would probably pick up these frameworks overnight.
- yoz-y 10y ago
  Pickup a framework overnight results in shoehorning your current knowledge into the framework and late night rants about how the framework sucks.
  - lawik 10y ago
    I'd say it depends on the framework a lot. 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 :)

danenania 10y ago

People focus on frameworks and popularity, but as someone who builds a lot of complex front ends, what really matters to me is architecture--architectural simplicity and architectural scalability. 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.