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

1–10 of 189 posts

Re: The Deep Roots of JavaScript Fatigue

#2

Post by officialchicken »

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 typical JS fatigue issues which aren't really discussed.

I'm not as optimistic as the author about the future. The fatigue is real - and the value proposition of having to throw code away every year isn't that great. The JS build toolchain and steps are just plain old insane; and neither durable nor resilient. 4-6 month old code bases become antiquated vs a few years ago when you could expect 4-6 years max.

BTW, I'm pretty sure C had the same kind of explosion 30+ years ago... Obj-C started off as a set of macros in the late 80's/early 90's. But it wouldn't be proper JS engineering if a wheel wasn't reinvented along the way.

Re: The Deep Roots of JavaScript Fatigue

#5

Post by sosuke »

Since the huge influx of new JavaScript developers happened we've entered a Wild West of development. Almost any combination of code is a great choice right now. It will settle down but open source stacks last only as long as their supporters. If you want to avoid all of the churn in JavaScript stacks then just write straight JavaScript, ES5 or if you want to just support bleeding edge browsers ES6. Then rely on a traditional backend framework with full page reloads. It won't be bleeding edge but it won't fail anytime soon either.

Re: The Deep Roots of JavaScript Fatigue

#7

Post by julie1 »

well javascript is evolving at a fast pace.

Wheat still grow on a seasonal base. Tourism is still yearly based. A car will last you years. telco CPE are lasting for years. Bank terminals are for years. Robots in factories last decades. Peacemakers are intended to last ages. Users do not really like to have their interface changed without any reasons to do simple tasks.

Browser ecosystem is just running amok in terms of speed diversity and complexity.

At the end, when we code it is for a business value. And for businesses web technologies are mostly expenses that grows faster and increase faster than economical growth. At one point this is condemning software business value in times of recession when people need to cut on costs to survive.

JS fast pace == a lot of manpower to keep application just up to date. It is a continuous growing bleed in the budget.

It is not the fatigue of the coder or sysadmins one should fear. But the fatigue of the business customers bored to pay for diminishing returns. Individual customers may still follow. But losing business customers will happen first.

Plus like it or not, updating browsers is not always as easy as you think it is. We all know of these legacy application that requires to keep a certain browser, and of new application requiring different one and the complexity of handling all these browsers. I used to have 6 browsers to code and test.

This is killing the business of coding and there is no "magic library" that will change the seasonality of the activity and the need for companies to keep their costs in control.

Industry out of IT requires for boring stable LTS technologies. The opposite of the offer of modern IT.

When offer does not meet demands ... company fail.

If ever USA or Europa, India, China announce a recession in 2016 or 2017 there will be blood in the IT.

It is all about costs and prices and making benefits at the end.

Re: The Deep Roots of JavaScript Fatigue

#8

Post by zdragnar »

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…

> Which version of Babel, 5? or 6

I'm not really familiar with any popular build toolchain libraries written for 5 that haven't been updated to work with 6. It's not like a Python 2/3 scenario, or even an Angular 1/2.

Re: The Deep Roots of JavaScript Fatigue

#9

Post by woah »

julie1 wrote: post #7

well javascript is evolving at a fast pace. Wheat still grow on a seasonal base. Tourism is still yearly based. A car will last you years. telco CPE are lasting for years. Bank terminals are for years. Robots in factories last decades. Peacemakers are intended to last ages. Users do not really like to have their interface changed without any reasons to do simple tasks. Browser ecosystem is just running amok in terms…

When was the last time an existing application stopped working because of new JS features?

Re: The Deep Roots of JavaScript Fatigue

#10

Post by cptskippy »

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…

I've stopped using fancy framework or tools and stuck with pure JavaScript, CSS, HTML5 for personal projects and I'm loving it. I know that isn't always possible, especially with legacy applications, but it's incredibly liberating to have full control over a page and not have to dance with shitty partners.
Post reply on HN