Live data from Hacker News

The Deep Roots of JavaScript Fatigue

segment.com

71–80 of 189 posts

Re: The Deep Roots of JavaScript Fatigue

#71
post #63
post #57

Earlier quoted context omitted.

You don't have to. The tools which worked 10 years ago still work today. The tools which worked 5 years ago still work today. No one forces you to switch to the new hotness, people choose to.

This is not just about tools still working; it's also about maintenance, evolutions, bugfixes, libraries, available workforce etc. If you happen to use an unpopular tool, then you can't easily leverage other people's work and it's harder to find qualified engineers to work for you.

Exactly, which is why I'm still using Knockout, it's been around for a long time (for a javascript library), values backwards compatbility and is still developed (only a few developers but they are all committed).

It's also just got a lot faster (3.4 had huge speedups) supports HTML5 components and supports IE back to 7 (while that's not a requirement for me it's nice to know the tools you have will work if you need them to).

There are features in newer libraries I like but taken in balance I like been able to grab the code I wrote 2 years ago and have it still work with knockout's latest version, to me that is it's killer feature.

Also there is this http://knockoutjs.com/spec/runner.html

Re: The Deep Roots of JavaScript Fatigue

#72

This is interesting but good lord, I want nothing to do with any of this. How are you supposed to get anything done if you have to spend so much time just ramping up on whatever the new hotness happens to be?

I don't really understand this. The height of confusion was at the beginning of the article when the author's friend regretted using RequireJS > We talked again last night, and he said that he’d chosen RequireJS. By now, his company had built a massive codebase around it –- “I guess we bet on the wrong horse there.” What makes RequireJS the wrong horse? Is it not doing what it was originally doing? Do you need more f…

I've recently been looking at job boards, and "React" turns up a lot. As does Angular, but not as much as a year or two ago.

So it's not so much about whether a given tech works for your project or not (being honest, server-side rendering + dash of jQuery is probably more than adequate for a lot of sites going full-on React+Redux right now) but fear of your skills becoming obsolete. Given the shit-show hiring is right now with its resume filtering and whiteboard hazing (witness every other week on HN) that's not an unfounded fear. So in order to have something on our resume that we used React in our last job, we use React for our current project...and so contribute to the problem.

Re: The Deep Roots of JavaScript Fatigue

#73
post #62

Earlier quoted context omitted.

I can't help but think this is just a whole bunch of people up in arms about not wanting to learn something they think they have to because 'all the cool kids' are. This discussion is often brought up in relation to React/Redux/Babel/Webpack, and people thinking they have to completely master all of them to start making websites, when the reality couldn't be further from the truth. Twitter had an amusing quip of the…

> I can't help but think this is just a whole bunch of people up in arms about not wanting to learn something 'all the cool kids' are. There may be that. There's also: a) Some of us are old enough to have mortages/kids/parents to support/houses needing renovation/desire a balanced life. We value skills that stay useful, and don't have the free time to keep learning variants of the same again and again* b) Companies w…

Fully agree with you.

Coding since the 80's in all types of stacks, frontend, backend, native, web, you name it. Whatever the projects require.

Nowadays doing native development just feels relaxing compared to the chaos of web based frontends.

Re: The Deep Roots of JavaScript Fatigue

#74
post #27
post #14

Earlier quoted context omitted.

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.

We old dogs have seen this movie too many times, hence we learned to wait for the dust to settle, pick up the bodies and get on with our life.

Not worth spending energy in worthless battles using tech that might be dead tomorrow.

Re: The Deep Roots of JavaScript Fatigue

#75

Earlier quoted context omitted.

I don't really understand this. The height of confusion was at the beginning of the article when the author's friend regretted using RequireJS > We talked again last night, and he said that he’d chosen RequireJS. By now, his company had built a massive codebase around it –- “I guess we bet on the wrong horse there.” What makes RequireJS the wrong horse? Is it not doing what it was originally doing? Do you need more f…

I've recently been looking at job boards, and "React" turns up a lot. As does Angular, but not as much as a year or two ago. So it's not so much about whether a given tech works for your project or not (being honest, server-side rendering + dash of jQuery is probably more than adequate for a lot of sites going full-on React+Redux right now) but fear of your skills becoming obsolete. Given the shit-show hiring is righ…

If you see a lot of jobs requiring React, or are fear becoming obsolete, then just learn React. It's very very simple - the API is like 5 functions, and the documentation takes like 20 minutes to read from start-to-end.

Don't learn anything else - just learn plain vanilla-React. The site has a onepager.html 'blueprint' to work from.

If people are getting anxious about this, its more than likely self-inflicted from trying to learn 30 things at once that you don't need.

Re: The Deep Roots of JavaScript Fatigue

#76

I have learned so much from comments on Hacker News. Every time one of these articles gets posted I hope that I will get to see some thoughtful commentary on why the ecosystem looks like this: is it the enormous influx of new talent? Is it the consensus to finally drop IE support, and that we're getting a decade of progress in two years? What business demands are driving this technology? Is this a race to make the br…

A lot of js devs came straight to js without any previous language experience. Hence we are seeing lots of ideas and frameworks thrown out there. The worst example is the proliferation of single function libraries, yes, create a js lib for a single function.

It will settle down. Mostly as the devs grow a bit older and wiser, and as the end users start to rebel a bit harder - already non-tech people are publically lamenting js-heavy sites, wondering why so slow to load and run.

Lean js is happy js.

Re: The Deep Roots of JavaScript Fatigue

#77

I have learned so much from comments on Hacker News. Every time one of these articles gets posted I hope that I will get to see some thoughtful commentary on why the ecosystem looks like this: is it the enormous influx of new talent? Is it the consensus to finally drop IE support, and that we're getting a decade of progress in two years? What business demands are driving this technology? Is this a race to make the br…

> I don't believe this is pointless tech churn, akin to fashion.

This is not pointless, but it is pretty uncontrolled. Basically, there is a natural tendency for engineers to want and rewrite old stuff, once all the flaws of once-cherished yesteryear solutions are glaring. Normally, engineers don't have a freehand in ditching old projects and rewriting from scratch, so they have to maintain what exists.

But with all the startups and the site redesigns, now they can, and they do. Why not--it's fun, it replaces old solutions that showed their limits, and the scope is somewhat limited; it's just a website, after all. Moreover, everyone can jump in and create their foobar.js lib or framework; the core node/JS is pretty easy.

> It really feels to me, at least, that there is a direction that the tooling is heading.

It is quite uncertain. Progress is made when you build on previous work, but here it is mosly about saying that the old solution doesn't work eventually, so let's do it this way instead. It looks a lot like infinite recursion, with pretty thin state.

Re: The Deep Roots of JavaScript Fatigue

#78

Earlier quoted context omitted.

I've recently been looking at job boards, and "React" turns up a lot. As does Angular, but not as much as a year or two ago. So it's not so much about whether a given tech works for your project or not (being honest, server-side rendering + dash of jQuery is probably more than adequate for a lot of sites going full-on React+Redux right now) but fear of your skills becoming obsolete. Given the shit-show hiring is righ…

If you see a lot of jobs requiring React, or are fear becoming obsolete, then just learn React. It's very very simple - the API is like 5 functions, and the documentation takes like 20 minutes to read from start-to-end. Don't learn anything else - just learn plain vanilla-React. The site has a onepager.html 'blueprint' to work from. If people are getting anxious about this, its more than likely self-inflicted from tr…

It's not just React, there's a huge ecosystem developing around it that is undergoing constant churn - see react-router or babel for example. And then with Redux you have a whole subsystem around that - redux-form and sagas and react-redux-router (or is it react-router-redux?). Then we have the GraphQL/Relay train leaving the station. Oh, and I've not even touched testing tools yet, or webpack (a whole other ecosystem on its own). Or CSS modules or...

But let's say I did learn all that (in fact, I did recently for a personal side project). It doesn't matter a bit for applying for a job. Why? Because I don't have real work experience using these things. So in order to have that, I have to somehow leverage React into my current job so it can go into my resume.

Re: The Deep Roots of JavaScript Fatigue

#79

In my opinion the current abstractions that are used in web apps are not good enough. Frameworks may be "elegant" in a certain sense but never get intuitive enough for the average developer, and eventually the framework's author will lose interest as well. I predict eventually we'll come full circle and get something like ASP.NET forms with Javascript controls that spans both frontend and backend.

And to get performance good enough we need support from the browser vendors. I think Web Components and related tech might be it. It also offers isolation for both CSS and frameworks. With it you could mix-and-match existing user components easier than now. Many of todays framworks are "this is how the whole app should work", impossible or at least hard and fragile to mix and nest two frameworks with that attitude.

What do you think?

Re: The Deep Roots of JavaScript Fatigue

#80
post #34
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.

Also a C++ developer, I completely agree. If frameworks repeatedly have lifetimes of a year, that suggests to me that a) nobody really knows what they are doing, b) there is no way to do it well in JavaScript, or c) maybe the problem is that a document description language (HTML/DOM) is unsuited for the kinds of things we want to do on our websites. You can pick pretty much any of a number of UI toolkits for inspirat…

I had the luck to ride the first .com wave in the 2000's, that is where I got my web skills.

Then after almost 10 year being busy with server side coding and native UIs, got back to it in around 2009.

Eventually got back to native UIs in 2013. Really happy to be back in native UI land.

It is just plain chaotic the tools aren't up to the tooling level we had already in the 90's with RAD languages like VB, Delphi and C++ Builder.

Using XAML + Blend, Android Layouts or iOS Storyboards is just plain nirvana compared with the chaos of making + CSS + JavaScript pretend they are native UI widgets in a portable way across multiple browsers.

Also having to worry about the build tool of the day is just crazy (npm + bower + yeoman + whatever else is required).

Post reply on HN