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

101–110 of 189 posts

Re: The Deep Roots of JavaScript Fatigue

#101

Post by Klathmon »

askyourmother wrote: post #76
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…

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

I don't get the hatred for small JS libs. It's the unix philosophy brought to the web. Have each part do one thing and do it well, then combine them.

I've used "one function" libs before, and i'll continue to. The most recent example is a small lib that added Array.prototype.reduce to browsers that don't have it. It's 31 lines total (un-compressed, un-minified, un-anything)

Installing that small, well tested, and standards compliant function using a single npm command is significantly better than trying to do it correctly myself (which would most likely take an hour or so just to look over it's exact functional requirements, and it would most likely have subtle bugs), half-ass it and write my own "not quite reduce but close-ish" that i now need to use everywhere and need to train new hires on because "I didn't want to install a 31 line lib, so now you have this non-standard system that's buggy in it's own strange ways", or copy-and-paste the code from somewhere muddying the legal status of my codebase.

Re: The Deep Roots of JavaScript Fatigue

#102

Post by Klathmon »

porker wrote: post #93
madeofpalk wrote: post #68

Earlier quoted context omitted.

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

>expectation to use latest and greatest and be future-proof

In javascript (just like in any other programming language) you generally get one or the other.

You can have the "cutting edge" features or libraries, or you can stay a bit behind and have one that's stable and will stick around for a while.

People are using features of JS that aren't even in the spec yet then getting burnt out when they break in the future? Using a library at version 0.0.3 and getting upset when 2.4.3 breaks something?

There is nothing wrong with using mature systems, and that's why I personally feel all of this "javascript fatigue" is self inflicted. If it is going to be a project you write once then don't touch for 5 years, maybe don't use react 0.15.beta-4 as your library of choice...

Re: The Deep Roots of JavaScript Fatigue

#103

Post by Klathmon »

weego wrote: post #92
pjmlp wrote: post #73

Earlier quoted context omitted.

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…

That sounds like your developer's problem, not the technology's problem.

Would you blame the language C++ if the developer was constantly compiling their own compiler from master every single day and spending hours upon hours dealing with that?

Re: The Deep Roots of JavaScript Fatigue

#104

Post by rimantas »

PhilWright wrote: post #17

We are simply going through a Cambrian explosion in the JavaScript ecosystem. Today there is huge demand for the ability to develop desktop standard applications inside the browser. At some point in the last few years we hit a tipping point where the potential to do this was unleashed. I am not sure exactly what the technology was that tipped us over, maybe a combination of several. Was it fast JavaScript performance…

  > Today there is huge demand for the ability to develop
  > desktop standard applications inside the browser.
Is there? Or just devs wanting to do that, for reasons unknown? I as a user could not care less about "desktop standard applications inside the browser", desktop applications work just fine.

Re: The Deep Roots of JavaScript Fatigue

#106

Post by rtpg »

marklgr wrote: post #77
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…

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

Rewriting can pay off in spades very quickly.

Just as some examples.... we've moved some pages to vanilla jQuery to Angular and have gained orders of magnitude more stability (read: basically no state-inconsistency bugs in newer pages).

If you're faced with vanilla javascript in the DOM and have any amount of complexity to it, then you should be using angular/react, if not for your sanity than for the sanity of the one who will need to maintain your code (read: you in 3 months).

If you're knowledgable enough to know that your use-case doesn't work with the newer tools, then more power to you. But the productivity gains from moving away from your jQuery spaghetti code to one of the more managed frameworks is well worth the rewrite time.

I don't know much about going from Angular to React, or Backbone to Angular though.... the choice of framework is likely dependent on what kind of user interactions dominate your app and subjective comfort.

But if you're careful, you can actually transition apps slowly over to Angular and I assure you, you could get rid of so much of your custom-written (probably not well tested) DOM management code it's not even funny.

Re: The Deep Roots of JavaScript Fatigue

#107

Post by zeemonkee3 »

nfriedly wrote: post #98
zeemonkee3 wrote: post #96

Earlier quoted context omitted.

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 ;)

I do the same, but it's never made much of a difference, at least until later in the game.

Re: The Deep Roots of JavaScript Fatigue

#108

Post by aedron »

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…

> why the ecosystem looks like this

It is a symptom that the platform is woefully broken, hence the multitude of solutions to try to make it workable. Neither of which work particularly well, so there is always room for one more to 'solve' it slightly differently.

The same story played out during the early 2000s, before rich JavaScript applications were really an option, with non-JS based web frameworks. In Java alone there was Struts, WebWork, Wicket, Tapestry, JSF, Spring MVC, and countless others, each one sucking more than the other. They are all pretty much dead now because people realized the insanity of trying to build a GUI using a page request based approach.

This problem will not be fixed because JavaScript itself is the problem. It simply is too limited a language to be used for large and complex applications. The proof of this is that JavaScript is used for exactly zero non-browser runtime environments (discounting node.js whose only appeal is to use the same language on the server as in the browser).

The attempts to compile down to JS is the best we can currently do, which is why the best and most complex JavaScript applications that have ever been made have been done this way, but obviously a native solution will be the better solution.

The best bet would be an intermediate layer, a kind of JVM for the web, on which a thousand languages could run. That is bound to be a long way out though, so we have at least a few more years of pointless JavaScript framework churn.

Re: The Deep Roots of JavaScript Fatigue

#110

Post by douche »

Klathmon wrote: post #101
askyourmother wrote: post #76

Earlier quoted context omitted.

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

I don't get the hatred for small JS libs. It's the unix philosophy brought to the web. Have each part do one thing and do it well, then combine them. I've used "one function" libs before, and i'll continue to. The most recent example is a small lib that added Array.prototype.reduce to browsers that don't have it. It's 31 lines total (un-compressed, un-minified, un-anything) Installing that small, well tested, and sta…

It's dumb, because most of those little shim libraries are things that would be part of the language's core library in a less shitty language.

Then when you have all these little libraries, you've got to go down the bundling path (and navigate the bewildering array of almost but not quite the same tools), because making 47 HTTP GETs to grab < 1KB JS files is slow. Theoretically, some of those might be cached, but the churn-rate means that virtually no one will have the exact version of a library that you require pre-cached in their browser.

Post reply on HN