4 ms·

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 intern

by 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.
- 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.

by lcw 10y ago

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.

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.