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

91–100 of 189 posts

Re: The Deep Roots of JavaScript Fatigue

#91

Post by Udik »

cm2187 wrote: post #51
prewett wrote: post #35

Earlier quoted context omitted.

JavaScript is the only UI environment that has gone through 10 years of solid churn. Pick any other UI environment besides HTML/CSS/Javscript and it is pretty stable. So why is the web so churny? It makes me think there is something rotten underneath.

What's rotten is probably raw javascript. The fact that pretty much no one uses raw javascript and have to rely on all these libraries to abstract the uglyness and inconsistencies isn't a vote of confidence. Javascript is popular by necessity not by its own merits. All new and growing platforms (iOS, Android) have been locked down into proprietary languages / libraries, and javascript is the only language neither App…

So raw C# is rotten too: Visual Studio, Resharper, MVC, nHibernate, IoC containers, nuget, mocking and testing frameworks, etc.

Not to mention the myriad inconsistencies of the language: static typed, with anonymous objects, dynamic objects, expando objects, extension methods, various different ways of creating delegates, keywords that mean completely different things depending on the context... give me the simplicity and logic of JavaScript any time.

Re: The Deep Roots of JavaScript Fatigue

#92

Post by weego »

pjmlp wrote: post #73
porker wrote: 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 '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.

Agree.

The worst issue for me is how unfocused the efforts are. I experienced issues at a large media company where new features to the public site to improve user experience where delayed for entire sprints because someone in the team became obsessed with the notion that their env was wrong because they were using grunt instead of gulp, or they used a particular Sass processor that relied on Ruby and they could use one that was pure JS.

I quite like writing JS and have done on and off for over 17 years, I just don't understand the constant and wilful reinvention and fragmentation in front end development.

Re: The Deep Roots of JavaScript Fatigue

#93

Post by porker »

madeofpalk wrote: post #68
porker wrote: 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 '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…

Why is everyone so anxious about this? That's the part that confuses me. When we introduced a library for a new project (at a Big Old Media Company with a team varying from interns, to working-70-hours-a-week millennials, to 9-5 family people) it was fine. If someone had something to learn about one of the 5 APIs, they read the entire library documentation (which takes like 20 minutes) or just turned around and asked…

> When we introduced a library for a new project

Great, a real data point! From this and previous comments, I'm guessing the library was React? And from another comment on this page, you haven't bolted-on multiple libraries for form handling, routing etc.

A few questions:

    * What is the projected lifetime of the new project?
    * Will the code be updated continuously (vs write once & freeze)?
    * What does your ecosystem around React look like?
    * What library/framework were you using before which you replaced with React?
    * Have yoiu committed to using React on new projects for the next.. 24 months?
It'd be great to learn more, as it sounds like a non-Facebook scale project, i.e. more relevant to most of us...

AFAICT no one in this thread is saying they don't like React, or if $Company paid them to learn it they wouldn't (paid learning time, what's not to love?). It's about the pace of change, reinvention, and expectation to use latest and greatest and be future-proof.

Re: The Deep Roots of JavaScript Fatigue

#94

Post by irahul »

madeofpalk wrote: post #84
irahul wrote: post #81

The JS development landscape is in a state of flux, and it's overwhelming for someone not familiar with it. I was just working on getting a react-redux TODO template ready and number of things I had to read up on was enormous. https://github.com/rahulkmr/react-redux-todo I had to read up on react, then on redux, then on es2015/babel, then on browsrify, then on gulp, then on eslint, then on sourcemaps, then on flow, t…

Why have you added redux for such a small and simple project? What are you getting from react-router-redux - why do you feel the need to sync the the browser's URL into the data store? You didn't 'have' to do any of these, especially for a project of this size. I can now understand why people might feel fatigued when they needlessly create overly complex solutions.

> You didn't 'have' to do any of these, especially for a project of this size

Where did I mention I had to do any of these for a project of this size(or any size), and since when TODO list is a project?

The purpose of the template is to prepare a template(duh) and understand how and where each library fits in.

Re: The Deep Roots of JavaScript Fatigue

#95

Post by cubano »

yoonay wrote: post #43
cubano wrote: 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.

I would just like to say that Mongo/Angular/Backbone is not a really valid stack since Angular and Backbone are pretty much competing technologies. You can probably mix them up but I hope no one really does that. Your second example of AWS/React/Redux is also a little weird since AWS is a cloud platform and it offers around 50 or so products. You can run a CGI based web app programmed with Perl in EC2 if you wish, an…

> I would just like to say that Mongo/Angular/Backbone is not a really valid stack since Angular and Backbone are pretty much competing technologies. You can probably mix them up but I hope no one really does that.

Yes yes, I know :)

I played a bit too fast and loose with that particular example but it was late and it was more to make a rather hurried point then to actually engineer a production stack.

But facts are facts, so I appreciate the correction.

Re: The Deep Roots of JavaScript Fatigue

#96

Post by zeemonkee3 »

nfriedly wrote: post #88
zeemonkee3 wrote: post #78

Earlier quoted context omitted.

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 ecosyste…

> It doesn't matter a bit for applying for a job. Sure it does! When I interview people, I tend to give a fair amount of weight in their side projects, because it's something they were actually interested in.

Maybe you do - and if so, kudos.

But that's not standard industry practice. Nobody looks at your Github - except maybe at the final stages of the process. In the meantime you have to get through a lot of filters.

Re: The Deep Roots of JavaScript Fatigue

#97

Post by hawski »

samcodes wrote: post #44

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…

This industry (and most things where many people are involved) is very complex system. There are several different motivations and goals at stake at the same time. I don't know if it is even possible to tell single direction of this system.

I studied industrial automation and I see it as a automation system a bit. To make it simple I compare it to i.e. temperature control. There are many things influencing temperature in a room. Yet we want certain temperature in this room. We try to maintain good temperature and "good" can have multiple meanings. But everything in environment changes constantly and even if nothing changes we still have inertia.

That illustration probably is not that helpful. What I try to say is that it is probably almost impossible to tell where we are heading. We can recognize some general trends for a while, maybe even few longer term. This is very complex system, we see things as we go. In case of this system if we would commonly start to believe that system is heading in certain direction for sure, because of feedback loop it would change this direction.

Maybe what I want to express is just that I think that I should read more on systems and game theory.

I didn't have time to make this post shorter, sorry.

Re: The Deep Roots of JavaScript Fatigue

#98

Post by nfriedly »

zeemonkee3 wrote: post #96
nfriedly wrote: post #88

Earlier quoted context omitted.

> It doesn't matter a bit for applying for a job. Sure it does! When I interview people, I tend to give a fair amount of weight in their side projects, because it's something they were actually interested in.

Maybe you do - and if so, kudos. But that's not standard industry practice. Nobody looks at your Github - except maybe at the final stages of the process. In the meantime you have to get through a lot of filters.

Well, maybe my viewpoint isn't the most common. But I can at least say that it does matter to some companies / interviewers.

My resume has a link to my github and I specifically call out 3 or 4 projects. If you want your side projects to count in an interview, that's probably a good place to start - if nothing else, you can at least use them for buzzword bingo to get past HR ;)

Re: The Deep Roots of JavaScript Fatigue

#99

Post by jalfresi »

marssaxman wrote: post #46

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 still cant for the life of me determine just what it is some of these developers are doing that means the DOM is too slow...

I've always approached it as "if the DOM is too slow, I must be trying to do far too much. Scale it back and re-think the problem"

Re: The Deep Roots of JavaScript Fatigue

#100

Post by UweSchmidt »

Flow wrote: post #79
UweSchmidt wrote: post #70

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. W…

We also need support from the IDE vendors. Can I drag in the component from the left hand toolbox in my GUI? Do I get at least some stubs for the corresponding server side code? And common stuff like authentification/authorization should really be rock-solid and built-in too.
Post reply on HN