Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Deep Roots of JavaScript Fatigue

segment.com

Post reply on HN
Print view View original

21–30 of 189 posts

Re: The Deep Roots of JavaScript Fatigue

#21

Post by [deleted] »

cgh wrote: post #20
nly wrote: post #19

Earlier quoted context omitted.

As a C++ developer completely ignorant of everything going on in webdev, except that 'something.js is always the new hotness', neither do I. I've basically ignored the boom in the web ecosystem for 10 years and have even less interest in getting in to it than 10 years ago.

Hear, hear. I wrote gui applications fifteen+ years ago in MFC and the ATL. Front-end programming was boring then and it's boring now. I can't believe people are wasting so much time re-figuring this stuff out.

[deleted]

Re: The Deep Roots of JavaScript Fatigue

#22

Post by vmware505 »

I still dont understand this fatigue rant around JavaScript. Because I started to work with Ember.js 4 years ago, and it is the solution for everything. The framework evolved nicely and works perfectly. It was not a bet, it was serious choice which based on a real perspective and concept.

Ember is matured and production ready for years now. You can focus on your product. So, as an Emberjs dev never felt that problem than other js developers. Dont experiment, start using the best tool out on the market... no more crying only happiness. ;)

Re: The Deep Roots of JavaScript Fatigue

#23

Post by vmware505 »

I still dont understand this fatigue rant around JavaScript. Because I started to work with Ember.js 4 years ago, and it is the solution for everything. The framework evolved nicely and works perfectly. It was not a bet, it was serious choice which based on a real perspective and concept.

Ember is matured and production ready for years now. You can focus on your product. So, as an Emberjs dev never felt that problem than other js developers. Dont experiment, start using the best tool out on the market... no more crying only happiness. ;)

Re: The Deep Roots of JavaScript Fatigue

#24

Post by pcwalton »

cgh wrote: post #20
nly wrote: post #19

Earlier quoted context omitted.

As a C++ developer completely ignorant of everything going on in webdev, except that 'something.js is always the new hotness', neither do I. I've basically ignored the boom in the web ecosystem for 10 years and have even less interest in getting in to it than 10 years ago.

Hear, hear. I wrote gui applications fifteen+ years ago in MFC and the ATL. Front-end programming was boring then and it's boring now. I can't believe people are wasting so much time re-figuring this stuff out.

> Front-end programming was boring then and it's boring now.

Not if you care about performance (to name one tricky aspect). It's all too easy to write a slow app.

Re: The Deep Roots of JavaScript Fatigue

#26

Post by gcb0 »

pcwalton wrote: post #24
cgh wrote: post #20

Earlier quoted context omitted.

Hear, hear. I wrote gui applications fifteen+ years ago in MFC and the ATL. Front-end programming was boring then and it's boring now. I can't believe people are wasting so much time re-figuring this stuff out.

> Front-end programming was boring then and it's boring now. Not if you care about performance (to name one tricky aspect). It's all too easy to write a slow app.

no it's not. it's very hard to write a slow application if you know the minimum about how the browser/vm handles your data.

very few cases excluded (e.g. scrolling issues on Android of old) it's nothing but a case of bad developers not having a clue. their code will be slow regardless of the framework because they use the wrong data structure, or render on the wrong step. simple as that.

then changing framework means dropping several features until they are ported, which means less code, which means faster code... until all features are back in. then, rinse, apply framework du jour, repeat.

Re: The Deep Roots of JavaScript Fatigue

#27

Post by wonnage »

cubano wrote: post #14
officialchicken wrote: post #2

I thought the article started strong and skipped around serious issues so it could focus on a pretty nice history of JS, but the conclusion was horrible. > Babel has worked it’s way into the standard Javascript toolchain, and now most builders include it as a first-class plugin Which version of Babel, 5? or 6? Because there's a lot of incompatibility issues right there and I think it is just as symptomatic of the typ…

No, I lived the C-explosion of 30 years ago and it was absolutely nothing like what I see these days. It utterly nuts how we are expected a learn a full-stack like Mongo/Angular/Backbone and then 6 months later is like NO we need AWS/React/Redux now! It's my oldman opinion that IT has become too much like fashion and not enough like engineering, but that's what oldmen think so who cares.

You can either shut yourself off from it and cement yourself into "oldman" oblivion, or actually try to understand why these tools exist.

Re: The Deep Roots of JavaScript Fatigue

#28

Post by sdnguyen90 »

Curious questions for those who complain about Javascript fatigue:

What reasons are you're dropping your old libraries/frameworks in favor of the new ones?

If an unstable API is a big problem for your use case, why not just stick with the old library or just not update the dependencies?

Re: The Deep Roots of JavaScript Fatigue

#29

Post by extrapickles »

officialchicken wrote: post #2

I thought the article started strong and skipped around serious issues so it could focus on a pretty nice history of JS, but the conclusion was horrible. > Babel has worked it’s way into the standard Javascript toolchain, and now most builders include it as a first-class plugin Which version of Babel, 5? or 6? Because there's a lot of incompatibility issues right there and I think it is just as symptomatic of the typ…

At least with the C explosion you could check all the libraries into source control or other asset management system (filing cabinet, etc).

Most of the JS library tools seem to encourage keeping code outside of source control which is pure crazy. It might work tolerably for a evergreen SaaS application, but you still have way too common complaints from developers that they couldn't build because someone else's server was down (NPM has trouble weekly). What is even worse is the encouragement to use a library/font/etc that is hosted in a CDN so the uptime of the app is also dependent on the uptime of the CDN hosting the library.

Post reply on HN