The Deep Roots of JavaScript Fatigue | Hacker News Reader

The Deep Roots of JavaScript Fatigue

segment.com

239 pointsrapjs178 comments

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 browser experience on-par with native? How do all these things interact, and what about all the other factors that I'm not smart enough to see, but usually someone on HN points out for me?

But no, I never get to read that, just complaints about how the whole community is dumb. Really? That seems unlikely. I don't believe this is pointless tech churn, akin to fashion. It really feels to me, at least, that there is a direction that the tooling is heading. I'm not sure what it is, but I feel like if that's where these conversations were focused (instead of just rejecting the current state of things) we could figure it out.

Yeah, it's frustrating as shit, we needed to all be pissed about it for a bit, but let's have a productive conversation.

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 topic last week:

> If you’re feeling overwhelmed by Slack or React (judging by the HN front page this week), I politely suggest you re-evaluate your life.

https://twitter.com/iamdevloper/status/707146929075949568

> 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 we work at/for value stability. They look at IT choices on a 5+year horizon; they don't have VC money to burn to 'rewrite' when JavaScript framework X no longer works. Which am I more likely to get sacked for? 1) Not using the cool thing and us missing out, or 2) using the cool thing and having to explain in 18 months time that we need another $20,000 to rewrite it into the Next Cool Thing?

Before you write us off, please do a 360 and see what the field looks like from other perspectives.

* I didn't say 'don't have time to learn'. We learn - but what we learn is evaluated carefully, and we have a much wider field to learn (Programming/Management/PM/Negotation - just a few of the core work-focused skills)

[Edited for formatting]

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 someone.\

I'm not convinced we found the only developers who like React, but it does seem like there's a certain audience of people (which overlaps heavily with HN) who love to complain about their self-inflicted anxiety.

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

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

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.

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?

It wasn't a single developer, it was a subset culture in the team of frontend developers. Those 2 examples were 2 different devs.

I don't really get your point though. Are suggesting that JS fragments and reinvents itself outside of the will of the general populace of frontend developers? How else could the problems in frontend dev arise if not from the culture created by the people?

Given how difficult it can be to get past HR keyword filters when applying for a new job ("Oh we need a candidate with gulp experience, not grunt."), I can see how folks are fearful that they aren't using the "right" technologies. It's insanity.

> Is this a race to make the browser experience on-par with native?

Everything points into the opposite direction, unfortunately.

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.

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.

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.

There's nothing wrong with "going down the bundling path". Virtually every compiled language does this via a linker. Java's jars are another example. You have at least 3-4 different tools for doing this in Python.

In short: "bundling" is just JS catching up to how software was deployed for ages. Source maps are equivalent to leaving debugging symbols in the binary, only without performance costs.

'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.'

I think you are mistaking the language with the browser.

I think part of this is the built in functions/frameworks for Javascript are so small.

Coding in Ruby, C# or whatever is about learning the standard library as much as the syntax.

So much of the churn is caused by the constant rewriting of basic functionality (e.g. date handling), if we had a bigger and standardised standard library, we wouldn't need half of the packages

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

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.

You know, if people approached web programming like actual programming, with layers of abstraction, there wouldn't be spaghetti code in the first place, and one could move to a different framework as needed.

But the problem is nobody stays with anything long enough in the web world to learn it well. 5 years ago, Backbone, Then Knockout. Then Angular. Then Ember. Now React.

Seriously, a dev with 5 years of experience in JS has literally the same 1 year of experience over and over now.

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.

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

> [Javascript] 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).

Electron? Atom? Slack? React Native? Espruino?

Also, there are plenty of non-web Node.js applications, e.g. https://github.com/sindresorhus/awesome-nodejs#command-line-...

Wrapping a browser instead of using one directly doesn't make your application run in a non-browser runtime environment.

And to be completely honest, probably sacrificing a bit karma. All of your examples enforce my point of view on JS as a 'use it as minimal as necessary' language else avoid it.

React Native doesn't wrap a browser view, it uses native gui controls.

> use it as minimal as necessary

Interesting point of view, considering that people are building javascript desktop applications, server applications, embedded applications, web (browser) applications, and what not.

I think PHP is a better analogy than early-2000s Java/.NET. Those latter technologies were largely enterprise driver, but the PHP ecosystem used to be more like today's JavaScript ecosystem. PHP a Blub[1] language, like JavaScript, which attracts inexperienced developers because it seems easy and has widespread support from hosting platforms. Inexperienced developers tend to reinvent the wheel (badly). One major difference is that PHP has a standard library that does almost everything, whereas JavaScript needs insane numbers of libraries for a typical production system (in my case, 5 explicit dependencies create a tree of ~300 packages).

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

I agree, and Facebook (Flow), Google (Dart, TypeScript, and probably others), and Microsoft (TypeScript), agree with us.

> The best bet would be an intermediate layer

See: WebAssembly[2], the successor to asm.js (sometimes called "the bytecode for the web").

1. http://paulgraham.com/avg.html

2. https://en.wikipedia.org/wiki/WebAssembly

I think you've nailed it. Web programming in javaland was verbose but relatively straightforward until about 2004, maybe a little earlier, when frameworks exploded. I'm not sure the frameworks themselves were worse than what preceded then - Struts2 was, in my opinion, an improvement over the original Struts. But I do recall hating web programming for a few years, wanting to leave and do something else (in a way, I did, I got a job writing java code to interact with CPLEX, and other developers handled the webapp stuff, so I was able to just mainly write straightforward Java, which I still don't think is such a bad language, it was the framework bloat that I disliked). The reason was doing very simple things had become mind numbingly difficult, and you had to wade through massive amounts of configuration and framework documentation (or code, since documentation often didn't exist for your specific issue) to do relatively simple things. The Java web programming cookbook became relatively obsolete, because everything was now handle by a framework that promised to make things simpler, but (often due to churn) massively increased the overhead.

Interestingly, it was, as you've pointed out, never resolved. Instead, it all became obsolete. I personally left javaland and started writing with Rails (even the non-web stuff I generally started using Python rather than java).

I suspect that we're heading down that road again. I think the modern javascript frameworks are the product of very intelligent and talented people, but my gues is that something interesting and "unanticipated" will sweep this all aside.

To risk a prediction, I think that other languages transpiled to isomorphic javascript will provide a new approach that will allow excellent languages like ruby and python to be used to write an entire web app again.

Until then? I wish I'd had the conviction to avoid MVC frameworks in the early 2000s. It's easy to feel like you're doing things the "old way", but I wasted a lot of time chasing java frameworks only to abandon the entire enterprise a year or two later… of course, it wasn't entirely my decision, it's hard to go against the grain, since you're rarely the only developer on a team.

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

I believe Qt's QML also uses JavaScript.

"...but let's have a productive conversation."

Okay, I'll bite.

With a web browser, a DOM, and Javascript, where do you see this all heading that's full of truth and beauty?

Where does the churn end if it's not pointless?

Cause you've got a web browser that was designed to view pages of linked information that has now been pressed into service as a ad-hoc run-time for building applications, a DOM that is so poorly implemented that most everyone tries to abstract it away at some point, and a language that is universally regarded as one of the worst ever.

Is that what you build on for the future? Cause then I do see it being pointless tech churn because your fundamental building blocks are too seriously flawed.

If the future is programs that people can download and run on their computer on demand you'll need a good run-time, language agnostic, compiles to binary, sandboxed, with a well defined UI system not based on document display. There's no web-browser, DOM, or Javascript in sight.

If you had such a thing this thread of conversations wouldn't even be happening. I sincerely hope that someone smarter than me comes up with that (yes, Java was a close but no cigar) and we gravitate away from the morass we have now.

> With a web browser, a DOM, and Javascript, where do you see this all heading that's full of truth and beauty?

Well, WebAssembly is on the way, so you won't have to use JavaScript. WebGL means you could, I guess, skip over the DOM entirely if you wanted to. None of this is fantastic, of course, but it's where we are.

Programs that people can download on demand existed, and still exist, yet the web is more popular. It's cross-platform, you don't have to install anything, updates are instant. What cross-platform UI are you going to use to address Windows, Mac, iOS and Android together?

To put it more succinctly, the "truth and beauty" for me is that it works, and it works today. I'm far happier iterating on that than noodling around imagining the perfect code execution environment that, as far as I can see, has no hope of existing any time soon.

I'm not sure putting down JavaScript, web browsers, and the DOM, and saying the ideal future is completely free of apps built on this platform, is technically being "productive" in a conversation ABOUT those things, but setting that aside:

The web app platform represents one of the largest, if not literally THE largest, explosions of programming and application development ever seen in the history of humankind. It also represents one of the most open and portable computing environments ever developed. It incubated a revolutionary and indispensable app for indexing, searching, and retrieving an unprecedented staggering corpus of human knowledge (Google.com); apps that have enabled hundreds of millions of people to effortlessly publish their writing, videos, pictures, etc globally and instantly (Twitter, YouTube, WordPress, Blogger, etc etc); apps that make it trivial to find most of the people you have ever known and to collapse time and space to communicate with them (Facebook, Gmail, etc etc); apps that enable you to select virtually any product imaginable and have it delivered, usually within 24 hours if needed (Amazon, Ebay, etc etc); not to mention probably millions of other more obscure apps to handle amazingly specific mundanities of office life, travel, entertainment, citizenship, finance, etc etc etc.

To look at all this and land on the conclusion that JavaScript and the web stack are fucked up‚— "a language that is universally regarded as one of the worst ever" — period, full stop, EOM, throw them out — seems aggressively contemptuous and beside the point.

It's sort of like looking at a raging party filled with some of the most interesting people you've known and some of the most interesting people you've ever heard of and complaining about the type of speakers being used to play the music.

I can't speak for the OP but I think that's roughly what they were getting at.

(Also, side note, Tim Berners Lee may perhaps have conceived the web as a place for documents, but he also seems to have since then embraced it as an application platform, not that his opinion or original vision should in any way confine what the web becomes. http://venturebeat.com/2013/03/09/tim-berners-lee-sxsw/ )

I wish I would upvote you 100 times. I've been a web developer over 20 years now. This attitude, that the web is unsuitable for applications, was understandable 15 years ago at the birth of web apps, but it doesn't make any sense today.

People need to realize there's never been a platform like the web in terms of portability and accessibility. Comparing the web to GUI toolkits is like saying that comparing Linux desktops to Mac OS X—Linux environments can never have the polish of OS X because Apple controls the entire stack. Similarly, a GUI toolkit can only be as cross-platform as the vendor makes (which is historically pretty terrible for all cross-platform GUI toolkits). The web is not only a standard, but a standard whose implementation is the price of entry for all new devices.

Furthermore, everyone complaining about the web's shortcomings doesn't have the whole picture—in fact the most difficult thing about a standard of this size is that no single individual or organization has the whole picture of what the standard supports. Sure the web was designed for simple documents and evolved into something for which it was never intended, why is this a bad thing? The fact is that you can never replace the web because A) there is no human power great enough to force adoption, it can only happen by serendipity (just like the web) and B) by the time you were done you would have a whole different set of warts that everyone would complain about. People would do well to remember Gall's Law before condemning web-as-app-platform.

> I'm not sure putting down JavaScript, web browsers, and the DOM, and saying the ideal future is completely free of apps built on this platform, is technically being "productive" in a conversation ABOUT those things

Would everyone is discussing the high quality of the Emperor's new clothes, is it productive to point out that he is, in fact, naked as a jaybird?

At some point we have to face up to the simple truth that JavaScript, the DOM, XML and HTML-as-she-is-written are bad. The people who assembled them over time aren't evil, or even generally incompetent: there are historical reasons for almost all of the cruft. But that doesn't mean that it's not horribly, horribly crufty, that is is objectively bad and in poor taste.

> The web app platform represents one of the largest, if not literally THE largest, explosions of programming and application development ever seen in the history of humankind.

That's the logical fallacy known as argumentum ad populum, i.e. arguing that because something is popular is is correct.

> To look at all this and land on the conclusion that JavaScript and the web stack are fucked up‚— "a language that is universally regarded as one of the worst ever" — period, full stop, EOM, throw them out — seems aggressively contemptuous and beside the point.

It is aggressively contemptuous because the current web stack deserves contempt. That is the point.

> It's sort of like looking at a raging party filled with some of the most interesting people you've known and some of the most interesting people you've ever heard of and complaining about the type of speakers being used to play the music.

No, it's more like complaining that each of the interesting people is wearing a blindfold, earmuffs & a gag, with a hobble to prevent him from getting within arm's reach of anyone else and can communicate only by reaching out with a stick or probe and tapping out Morse code messages on other's arms. Sure, all those impressive people are doing a bang-up job of overcoming the absurd limitations of the insane party, but that doesn't make the party one bit less insane.

Wanna back up that beautiful rhetoric with some actual objective reasoning as to why; HTMl, Javascript, the DOM are "bad" and some ideas on the way forward?

It is "objectively" "bad" because if you bring javascript up in certain social circles involving programmers everyone huffs and puffs. I've heard people time after time who've never stepped foot out of a Java IDE complain about how hard it was for them to write something "simple" and "basic" in javascript. Not to claim that there is any real veracity in the wisdom of the crowd, but there are hundreds of thousands of programmers writing working, functional, useful apps in javascript every damn day. People can say that fact is DESPITE the language features but these people ignore that if you want to actually reach customers you have to use the most popular runtime of all time - the browser.

Being unable to have a conversation about the ecosystem because the language isn't to your liking or preferences speaks to me of a closed-off mindset, which as everyone knows is a great trait for programmers to have /s.

> Cause you've got a web browser that was designed to view pages of linked information that has now been pressed into service as a ad-hoc run-time for building applications

At this point, this is argument is 100% false. Browsers of today aren't the browsers of the 90s. Chrome came out in 2008 and has ALWAYS been designed to run applications, and an entire operating (ChromeOS) is based on the idea that the browser isn't just a system built for viewing linked documents, but a valid application platform.

> If the future is programs that people can download and run on their computer on demand you'll need a good run-time, language agnostic, compiles to binary, sandboxed, with a well defined UI system not based on document display. There's no web-browser, DOM, or Javascript in sight.

You just described Windows 10's UWP.

Yeah, I think it must drive some people at Microsoft crazy that they have a better technical solution and no one uses it

Monty Python explains the foundation of frontend web development better than anyone.

"When I first came here, this was all swamp. Everyone said I was daft to build a castle on a swamp, but I built in all the same, just to show them. It sank into the swamp. So I built a second one. That sank into the swamp. So I built a third. That burned down, fell over, then sank into the swamp. But the fourth one stayed up. And that's what you're going to get, Lad, the strongest castle in all of England."

We're still working on the second castle.

The "fundamental building blocks are too flawed" argument is so strange to me. Too flawed for what? To become, by far, the most popular platform in history for running applications? Because it's already done that.

This is a case of the evidence not fitting the theory well, so people complain about the evidence. If the browser/DOM/HTML/JS ecosystem "technically" is terrible, but in practice dominates the competition, then there is something about it that is better. This is not a fallacy, but a simple supply and demand argument.

That would actually be a very awful future. I like a linked web full of text. Flashy this and flashy that and app for this and app for that is all blah. Most things don't actually need to be apps.

I don't know how productive this is, but here is my take on this situation that you likely aren't going to hear anywhere else.

I believe there is a fundamental lack of understanding about web development - mainly HTTP and HTML. These technologies are simple which is why most developers don't bother to learn them. Being a developer both before and after putting in an effort do deeply understand the foundations of web dev, I can tell you my experience was like turning on the lights after struggling in the dark.

Basically what I found is that web app development was designed to work great in specific ways. If you don't know this and try to get it to work in a way that it was never meant to, you're gonna have a bad time. Sadly, every front end framework and many JavaScript libraries fall into this category. They focus on bending the natural web development paradigm into some other form. Which one will "win"? None - there's no right way to do something wrong. The real question is when we will stop falling for the pitch of the snake oil salesmen.

I assure you, there is no functionality that any of the frameworks bring that does not already exist and can be implemented in much simpler, maintainable and architecturally sound ways. Do not believe what the Framework charlatans claim. I can disprove every claim with real, working code examples.

Another reason we are inundated with poor frameworks is there is no other good entry point for developers new to web application development. Nobody wants to (or should have to) read the HTTP spec when they just want a simple CRUD app.

In summary: the reason these JavaScript frameworks exist is 1) Easy starting point for beginners 2) Make web development more like desktop/OOP/whatever the average developer is used to. There there cannot be a "good" web architecture until one is based on how web development actually works, not how we think it should work.

Do not believe what the Framework charlatans claim. I can disprove every claim with real, working code examples.

Please do. I am interested in seeing more detail in your post.

I would upvote this comment 10 times if possible.

Can you point to any more elaborated examples or write-ups of the kind of html/http work you're describing here? I'd love to learn more.

Honestly it's a bit disheartening to see a community with so much insight readily jump to bashing every single "hip new thing" in the browser/JS world, heck, even npm/bower.

I think part of it is because of the proliferation of JS in recent years, whereas many people still have this notion of copy/paste Javascript "skiddies". Even among new grads with significantly less experience, I often hear some voicing concerns that "web developers are not real programmers", or there's "nothing hard about front-end work", "CSS is only for designers", or "only people who can't do CS become web developers".

On the other hand, yes, new frameworks are appearing every day, and it's obvious this is a huge source of frustration; but we do we need to chase every new framework? Is it actually true that an application written in X framework HAS to be re-written every 2 years instead of a pure jQuery-based application? What is preventing you from continuing to use Angular v1, that you have no choice but to port everything to v2? (also worth noting that you can port only parts of your app to v2 and run them in tandem but I digress)

I don't want to start another flame war here (which seems to be a common trend these few days), but how many people do you know that has a deep understanding of the costs of DOM reflows and how to mitigate/minimize them? As a full stack developer who has done quite a bit of front-end work the past few years, I can tell you: not many.

Okay, so maybe you say: "For X and Y application that knowledge isn't important." That very well may be the case, but how about those that build richer and more complex interfaces that (maybe) involves thousands or even hundreds of thousands of elements on the page? What then? Has no one ever seen the absolutely abysmal jank and (lack of) performance some JS apps have?

Is it really so horrible that we have to bash and nitpick on every single thing someone makes in the web community? Is it wrong for your kid to come home one day, exclaim "look what I drew today!", and show you a horrific picture of you looking like a gorilla? Or maybe it's okay that a lot of people are very working hard to do away with the hairy pain points we have currently, make it harder for you to shoot yourself in the foot, and maybe introduce some (small) pain points of their own inadvertently? Maybe it's possible that we're not all perfect humans with perfect ideas?

I'll give a quick example of what it's been like for my experience/or the experience of people I've worked with with jQuery/Angular/React.

jQuery: I want to update this element, okay I'll add a class or id as an identifier and query the DOM. Then I'll change the text in here. Oh but now I want to add another element to this list here (but I haven't cached the selector because I haven't learned that yet), let me query that element, create a new element, then append it.

Angular: I want to update the text on this element, okay, I'll change it in $scope, or the template directly. I also need to add a list item, okay, let's just .push() the new record in our $scope variable and it'll appear since we already told Angular to iterate on this model.

As for DOM updates? Well, I may or may not know it, but Angular is going to update it for me on the next $digest cycle which happens in intervals or can be triggered manually, after doing a dirty check for $scope/$watch.

React:

Similar to my thought process with Angular, I update the list item in our model with setState, and React will do its virtual DOM diffs and update for me, or maybe it doesn't update because shouldComponentUpdate told it not to. And it only touches the elements necessary on the actual DOM.

Perhaps it doesn't seem like a big difference, but after working with all 3, speaking from personal experience: once you have to return to doing pure jQuery, you realize how forced and unnatural everything now feels.

Give it five minutes: https://signalvnoise.com/posts/3124-give-it-five-minutes

The only horse to bet on at the moment is jQuery. I know, I know. I'm old and I don't do exciting things. I work mainly on a niche product in a boring field.

But you know what? My site works with IE8+. I can deploy code without much thought as to what is going to break. My deploy script takes 15 seconds. I don't have to rewrite anything every 3-6 months. I can update something that hasn't been touched in 2 years and it works exactly as expected.

I'll welcome all you bleeding edge javascript hippies back with open arms. But you have to use the side door. https://s-media-cache-ak0.pinimg.com/736x/f0/10/a3/f010a3aad...

> I can update something that hasn't been touched in 2 years and it works exactly as expected.

This is a factor taken for granted far, far too often.

Imperative jQuery isn't that bad at all. I agree with you. Once I actually sat down and really learned Javascript 4 or 5 years ago my jQuery got a lot better. I don't think developers understand how to write maintainable jQuery. I see a lot of code where people unbind events before they bind and not using the .on methods.

It will still crumble in super complex interfaces though. Which in my experience don't pop up that often, and when they do it's only on one or two pages.

The new tabbed interface of Stack Overflow (in alpha) is all pure jQuery and it's fairly complex. I don't think it "crumbles" at all.

http://meta.stackoverflow.com/questions/308875/new-navigatio...

Disclaimer: I was one of the developers.

That's awesome. We need more developers like you writing blog posts and going on Podcasts to kind of balance out this "chasing new shiny things all the time developers". When a tech becomes big there's a million blog posts about why it's awesome(extjs, backbone, knockout, angular, react). I've seen it all. Not enough constructive views on the other side.

jquery spaghetti code can be quite readable if you're smart about layout... group things into sections, arrange everything sequentially where possible, etc etc

I've had to do a fair amount of complex UI and, frankly, I don't see why people stress so much about it. I rarely end up with more than a screen's worth of event handling code (which is a small amount of pasta, really), and things flow around fairly intuitively if you've any experience building non-web UIs

It feels like a lot of this language churn is purists reinventing the wheel. In previous comments I've ripped into specific aspects of this complaint, and an alarmingly large proportion of responses boil down to, "well, but I can't have feature XXXXXXXX or YYYYY with your stack! it's worthless!" XXXXXX is usually something like syntax highlighting, or intellisense, or some other triviality. Nobody EVER mentioned maintainability, or simplicity, or elegance, or any of these other, broader principles, without also providing a dissonant opinion.

Well you know what? I can write clean, performant, raw javascript and jQuery and I am damn proud of it. I don't need your stupid, always-changing tech. It sucks; I'm 31, but the only people I can relate to here are the old men. GOML, you kids are cray-cray

It sucks; I'm 31, but the only people I can relate to here are the old men. Nope, 31, you're an old man now.

sigh :)

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, AJAX, client side frameworks or NodeJS? Whatever the cause the dam has broken.

In a few years the winners will emerge. But it is impossible to know if the current leaders are going to win or if another champion will appear tomorrow.

I intend to enjoy the ride and look forward to the improved productivity and capability of web apps that results from the chaos.

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.

It also may be the people that are drawn to it. There are backend/frontend dev stereotypes for a reason. In my experience, the frontend dev teams have tended to be earlier in their careers and more likely to come from a 'non-traditional' background into tech. You're not seeing code boot camps popping up for Java and .NET developers like you are HTML/JS and Rails.

It's not a knock, the younger people usually bring the enthusiasm and fresh ideas to the table- but that enthusiasm and zest hasn't been sobered with a decade of real world experience and a more analytical/engineering background and schooling.

This is a really interesting point. I think another factor is that if you have a huge amount of users, you need robust server code. But front end code only has one user at a time. And it's much more tied to design, so it gets "stale" faster, so there are just very different pressures on it that make it less amenable to a traditional engineering approach. In that it might be worth trading some robustness for speed of updates.

You bring up a good point that I missed in my first comment. The design. God damned designers! I kid- I worked at an agency for years and the hardest part was always getting the build to match the design when they were still laying out the design pixel perfect in Photoshop and Illustrator as if we were doing print work or doing fixed width pages.

I've seen some designs that were, frankly, beautiful but it took no more than 5 seconds to highlight the 30 areas that were going to cause massive budget overruns trying to make look exactly right, have decent performance, and work in eleventybillion browsers.

I've certainly appreciated what interesting designers can bring to the table, but we're still a ways away from a lot of traditional designers having a good handle of what their design really means when we're building it. Kind of like the contractor who bitches about the architect for designing an angle that is impossible to hammer into. Sometimes there is a disconnect.

I would have agreed with this, but I've just been exposed to what's happening in the new .Net core and asp.net 5.

It's a clusterfuck of the sublime and the downright stupid. Any new trendy idea has been rammed in to the new ASP.Net with startlingly high churn for a MS product and bizarre choices like forcing you to program in particular (often undesirable overkill) ways.

So the JS churn model has begun to infect another language as a model to be emulated rather than reviled.

Yeah, that's a good point. In fairness to MSFT, with Roslyn and really trying to make the .NET stack able to run on non-Windows boxes you would think there would have to be a few hiccups along the way. I feel like the JS scene is facing this level of upheaval every 9-12 months right now.

That doesn't mean they have to re-architecture their MVC to force you to use DI all over the place whether you want to or not. Or to start running command windows when you used to have a working IDE. Hell, even the new config loading is an utter pain in the ass compared to simply just accessing a static object available from everywhere.

There are great bits, don't get me wrong, but I do wonder how much of their larger audience are actually going to enjoy this. It presently feels like a massive step back for very little gain.

It just feels, looks and smells like the old JavaFactoryHammerWidgetFactoryFactory of the days of old, i.e. over-engineering which means you can't get any actual functionality done as there's more scaffolding than functional code. You end up drowning in utterly useless code that doesn't really do anything.

I think it is a combination of what you are saying. The reason there is so much variation is because the userbase is extremely wide in the javascript world. If you want to deliver your application to the web, you are going to have javascript in there somewhere, and pretty much everybody needs to have their applications on the web these days. So you have developers from a native mindset, an embedded mindset, a backend / data oriented mindset. Nodejs is great for rapid development of http based api's, so you get a lot of backend api perspectives, and of course, as you mentioned, there is the whole html5 / javascript frontend crowd.

Then you have the situation where javascript is both functional and object oriented, so you get toolmakers who focus on one of those or the other more. Now with compile to javascript being more widely accepted, you get a lot of developers from static typed languages insisting that this missing feature is the panacea which will solve all of the problems.

The wide variety of perspectives within the javascript developer community is what sparks the wide variety of new tools and techniques. And popularity of these tools and techniques is definitely based on trends and fads.

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 Apple or Google could block, just because they were forced to preserve compatibility with the web, not because it was a terrific language.

We pretend to like it just because it's the only meal we get to eat if we don't want to starve.

Oh, language is rotten if developers use libraries and abstractions? When was last time you wrote an application in "raw" Python/C/Swift/Erlang? (Whatever "raw" is supposed to refer to, is standard lib allowed?)

No language is perfect, and javascript is actually pretty nice one, also considering that there are multiple independent runtime implementations for almost every platform, I would say javascript as an ecosystem works surprisingly well.

Javascript only has problem if you think diversity is problem. It's totally expected outcome that people (wildly) try things when the language is well designed, i.e. relatively small but flexible core.

I write applications in raw Python all the time. True, they're text-only (or text as graphics) terminal applications, but it's surprisingly versatile and very pleasant to code in, so much so that I've been trying to make more and more of my ideas console friendly.

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.

That's not even true, it's just that nobody pays attention to other things.

Look at Windows desktop apps. If you wanted to make a native Windows desktop line of business app in 2000, you would use Win32 APIs. In 2002 or so, you were supposed to use WinForms. And then it was supposed to be WPF. And then Silverlight. And then WinRT.

Don't forget about MFC somewhere between WinAPI and WinForms :)

And it's worth noting that in this case we're talking about a single entity - Microsoft - pushing these changes. In the JS-land, there are many more actors, and every one of them tries to be innovative: this has to result in a lot of changes over relatively short time.

Nothing wrong with it, too. I think that, over time, the ecosystem will converge on a couple of best solutions and that it will be of higher quality exactly because of a "chaos" we're seeing right now.

Someone need to cherry pick versions of popular libraries and make stable and maintainable LTS bundle, let call it JASMIN, which should be used in places where long term support is necessary, like CentOS.

Then application developers will refer to "jasmin-1.0/jquery" instead of random version jquery. Developer will know, than this version will be supported at 3 years least, with bug fixes only, so he will not worry about incompatible changes in libraries and it dependencies for next X years.

The churn is simple to explain: HTML/CSS/JS was never intended for building applications. We've been trying to turn a document delivery platform into an app platform. As a result, we need all this "tooling" to fit square pegs into round holes.

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

It's a huge boon for administration - auto updates, no install procedure, cross platform...

...and difficult to pirate, a major reason so much software moved to the web.

On the negative side for the consumer, the software and whatever data you committed to it will disappear if the company ever decides to stop supporting it or shuts down.

Also you are pretty much forced to be online in order to use it, so if your device isn't in a wifi friendly area and/or you're trying to limit your internet usage for whatever reason (i.e. more productive with less distractions), the software is useless.

That's actually not true with cache manifests, IndexedDB and service workers. You can make an entirely fully-offline webapp that stores data locally. This is all relatively new stuff, of course.

That's true, although it tends to hide the data in some '/users/documents/appdata/local/roaming/cache' craziness rather than true i/o. I still can't load a preferences file off my ~/crazy_named_personal_folder, update it, and then save to the same location, at least as far as I know (I've only played around with local storage briefly).

And that's a lot easier to lose and a lot less portable than all the stuff I care about in a single folder that I sync with an external hard drive, a usb drive, and dropbox, automatically.

But it's still better than nothing, and I'm glad it's an option now.

So much of this history is wrong.

1. ECMAScript is called that because Sun (now Oracle) owns the JavaScript trademark, not because anyone wanted to be diplomatic.

2. JavaScript language evolution was not primarily driven by the Firefox team. Mozilla didn't start until 1998, by which time pre-ES5 standards were mostly done. There was an effort called JS2, led by Waldemar Horwat (then of Netscape) which didn't result in a standard. Other SpiderMonkey JS extensions were mostly not adopted, or adopted in ES6 in heavily revised form.

3. The creation of the spec was driven in significant part by Microsoft, whose internal spec documents formed the initial basis for ES1.

4. The "harmony" name came entirely after the end of ES4.

5. None of the design of classes, modules, or other major ES6 features comes from ES4. Smaller features such as `let` were present in ES4, along with very different class systems, namespace systems, and other features.

6. Neither JScript versions nor Spidermonkey's JavaScript versions ever had a significant impact on JS on the web.

7. Unlike ES4, ES6 is backwards compatible. ES6->ES5 compilers are not needed to make it backwards compatible.

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.

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

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.

Amen

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 coot understand well why such inane tools exists and it's because there are too many people worrking in a hurry and can't be bothered to look back at sound engineering solution that already exists.

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

For other languages/ecosystems I would agree. However, in the JS world there is a lot of stuff that exists simply to exist. There are typically multiple libraries to do the same thing (in general) but with someone else's opinionated take on it.

Sometimes I feel like the developer of framework B was having a hard time grokking framework A and just decided to roll their own, like framework A, except for the parts they didn't like or understand. Then someone came along and realized that framework B had gaping security issues and was horrifically slow- so they created framework C which is the more secure and performant opiniated take on framework B that was an opinionated take on framework A. But then after four long months the devs behind C no longer maintain it because they've moved on to WebAssembly so a team spins off a fork of C in Coffeescript.

In a lot of other communities they would've just evolved framework A, or C would've pushed some patches back to B. Or D would've taken over for C and there would've been a handoff.

It's effing ridiculous that if I go back to a 5 month old project I will spend all damn day getting a build from source to work.

It's not just the libraries and packages. It's the toolchain, the build pipeline (heaven forbid you look like a grandpa and still use Grunt!), the transpilers. I love that people are creating cool shit all the time, but it really seems like if the code didn't come from their team, they're going to iterate the idea and put out a competing package instead of contributing back to the original. And then we wind up with two unmaintained projects 6 months later...

It really feels like there aren't many people (at least making headlines) that have had to maintain an actual live production system for more than a year or two. It'll be interesting to see what these people are doing 5 years down the road...

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.

I wasn't around for the C-explosion but it seems like something that is exacerbated by the current ease and normalization of sharing code.

Make a framework? Post it on github, go to a conference, write some blog posts, get your framework its own conference, ?, profit! (now I'm thinking of that Southpark guitar hero episode but with famo.us as Stan) There's incentive to put out new tools for the producers of those tools.

On the user side it's easier than ever to learn new tech and framework. I'm learning Clojure and in a few weeks I've asked at least five questions about libraries and frameworks on stackoverflow and slack that have been answered by the authors of those tools. It's 3am on a Tuesday/Wednesday and there are still people helping each other out all over the internet, writing how-to blogs, answering Stack questions. As an aside, for all the weird pathologies of this profession and our community I think that's pretty awesome.

My point is that even though the continuing learning burden might be volumetrically much larger, I'm not sure it's significantly more difficult.

Don't worry, it's mainly in the HN bubble, reading HN every day will after some years make you think this is how the world looks like. Most developers haven't even heard about Mongo/Angular/Backbone yet, heck, I even have to explain tree times that JavaScript is NOT Java.

> Most developers haven't even heard about Mongo/Angular/Backbone yet, heck, I even have to explain tree times that JavaScript is NOT Java.

Yes, but those developers are not doing front end web development for a living.

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, and you can do that as easily as 15 years ago if you learned it back then.

As a younger web developer sort of a guy, I'd say that the current situation is not something where you have to be learning a whole new set of tools every 6 months. You can still easily find a job if you know for example Angular 1.x, some CSS, and understand how to create a stateless JSON API using whatever language you are comfortable with. Betting on the strongest horses of the front end side has had you learn two different technologies (both in the same language) in the past four years, I'd say that's not too much asked. In the back end cloud platforms have really taken over, but it's not really that different from 15 years ago when people ran their own hardware. Linux is still the king, now you can just choose whether you want to be in 100% control of the infrastructure or actually make your life easier by purchasing a PaaS (e.g. heroku, beanstalk).

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

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

I live under the assumption that you don't have to. The thing you should figure out is: finding a stack that suits your needs (and the needs of your customers) best. If you find it, is is perfectly reasonable to beeing a bit more conservative and stick with it. On the backend for example I used rails for years, and with good reason. I am not planning to switch, but I am open enough to consider my options and experiment with other stuff. I know there are (maybe pretty good) alternatives: enterprisey Java-frameworks; good old django; nodejs; experimental stuff with erlang or haskell.

I think the frontend/js-world is not so much different. You don't have to know every framework, because it is the latest hot shit... It is not wrong knowing the strenghts and weaknesses of new frameworks, but you don't have to use and adopt to everything thats new.

I care ;) I agree it's too fashionable and not just plain old good engineering. And thanks for the clarity! Now we have to live with too many engineers whose mind have been demented by the 'move fast and break things' philosophy.

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.

> NPM has trouble weekly

Interesting. We deploy daily, always fresh from NPM at each deployment stage and have never had an issue with NPM. We had one legacy dependency downloading from github (ugh) which caused an issue the last time it went down, but we quickly sorted that out.

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, then on react-router...It was a lot of effort, but I am liking it so far. The important thing is we can build applications in ES2015 which is a better language than the browser's js implementation and still get to debug it on the browser(sourcemap and specific devtools). My impressions of react-redux so far is it makes implementing a TODO list harder, but it will be better suited for applications with lot of state.

True there are conflicting choices and advice, but I think all this will stabilize in a year or two and despite the naysayers, the future seems bright. And it's not a take-it-or-leave-it deal - if you are happy with Backbone, keep using it. You can choose to just integrate gulp,babel and browserify for es2015 goodness. You might not like react but like how redux does state management - just integrate that in your existing application.

Most of the tools are orthogonal to your framework choice. Use tern for completion and analysis, use eslint for linting, use browerify/webpack to pack your assets...

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.

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?

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

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 from it? How do you build 'a massive codebase' around a module spec? I'm guessing here the person thinks Webpack is the right horse - Webpack supports the AMD spec RequireJS uses if they felt the need to switch (which I can't see why you would), which would minimise whatever changes needed if you had the urge to 'churn'.

I think people need to stop getting so anxious about doing what all the 'cool kids' are doing.

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.

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.

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.

But you don't need to learn all of that! That's what I mean when I say self inflicted. If you feel the need to learn all this BS, no wonder you're feeling fatigued.

We just built and released a Very Big Project using React, Redux, and React-Router. Smooth sailing. Zero JS-Churn. No one had any issues being overwhelmed. We never went crazy and threw in every hot new library we heard about on Twitter.

You're missing the point. You're talking about what you used for your project. I'm talking about learning skills so I can walk into an interview for a job that says "we need React developers". They may use any number of these things I mentioned, or are thinking about using them, and will bring them up. As a "React developer" I have to be aware of the ecosystem. So it's not just "learn an API with a few functions".

And, as I said, it matters not whether I learned these things on my own: to Get the Job you need to demonstrate real-world experience.

I strongly disagree with the idea that you need to know how to use react-saga or react-redux-router to walk into an interview that name drops React.

Like, it would be a huge plus from a candidate if they even knew the name GraphQL/Relay, but I wouldn't want to work somewhere that expected me to know it completely.

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

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

I'm not anxious about it, because I don't have to deal with it, because I continue to focus on interesting problems which are almost entirely unrelated to building web sites. But I choose that in no small part because the world of web development appears to be an insanely unstable froth of fads and complication offering tons of tweaky API-fiddling and not much in the way of abstract design problems. Besides which I just don't see a lot of value in JavaScript and wish people would stop writing so much of it and trying to convince my computer to run it for me.

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"

What isn't being said, and is painfully obvious to me, is that almost everything the article talks about wouldn't be happening if a. Browsers had a decent UI capability, and b. Javascript wasn't a piece.

And to what end? What website have I gone to that just knocked my socks off because they used framework X or library Y. None. And one year from now they'll toss it out for whatever else catches their short attention spans.

So much wasted effort.

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

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

Yup, it doesn't make sense to keep chasing the perfect solution. Developers wouldn't be suffering from fatigue if they focused on "done is better than perfect".

Sure, if you're always in a position to pick your stack then just sticking with your proven tech works. If you're working for other people with existing code you might need to learn a whole new JS stack every time you switch employers. Since you're already engaged in a Sisyphean cycle of learning new ways to JS why not be on the lookout for perfect for when you do get to pick your own?

Yeah, Ember is awesome. Hassle free tooling and you can get up and going in minutes.

Ember even has a LTS version now!

Ember is fantastic, the oldest projects I have are about 4 years old and have been (more-or-less) painlessly upgraded every now and again. Everything is ember-cli and ember-cli-deploy now. Time and time again it shows that Ember is a community project that has a strong focus on scalability and maintainability over time.

I also do a lot of work in Angular and React (this year) and all the tooling, build, best practices change every couple of months.

A lot of people complain about Ember's learning curve, but the things you learn _stay relevant_. Personally I'd rather invest in that kind of knowledge than learning yet another arbitrary build system.

to me, ember is the only source of peace in js framework wars. I do not use it yet.(cause i am js noob). but if i require a full blown js framework, ember will be my choice.

You can learn it quickly from this free tutorial: http://yoember.com

Right now I know of a company that needs to overhaul their front end. They don't have a lot of available developer resources and their core strength is backend (Python/Django). I'm sorely tempted to recommend Ember. Angular is in transition and the whole React circus would be overwhelming for them. Ember fits in very well with the Django philosophy and there are plugins to make them play nicely. Ember has a learning curve but it looks like it would pay off long-term.

Ember is nice, but it is a gigantic framework with a steep learning curve, and very heavy on the wire (lots of kb). I used it at my last job.

I'm using mithril.js right now for a side project, with basic ES5 and no build tools. Mithril has a tiny API but still offers surprising amounts of power.

I'm enjoying the simplicity of everything. It's been nice spending way less cognitive energy to understand how all the pieces fit together =) I may have to add some tooling in when I deploy the finished project, but I'm going to keep it as minimal as possible.

For people who have used more batteries-included style frameworks like Ember, the churn isn't as bad. But for those who tend to lean more toward small libraries like Backbone and React, the churn can be overwhelming.

I was taking a shower, and this question popped into my head: What is harder to master nowadays? C++/STL/Boost or the Javascript ecosystem?

I don't know the answer.

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.

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.

I second this. Performant code is not so opaque as to be super hard, people simply need to know their shit.

I am also not really into web development, but from the outside it seems especially primitive. I did write some Qt applications the last ~10-15 years and even at the turn of the century it was far easier: design graphically using Qt designer, run the UI file through uic, connect some signals to slots, done. All fast, smooth, with a much more native look & feel than web apps.

I recently ported a larger Qt 4 application to Qt 5. It took one or two hours. (Qt 4 was introduced in 2005.)

It reaches much more people if that is what you care about.

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 inspiration, they all look pretty much the same. It's not like UI is a completely unsolved problem. It's not even a partially unsolved problem.

I'd be interested to know what the problem actually is, because I certainly don't want to have anything to do with the mess until someone comes up with something solid.

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 <div/> + 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).

I don't really understand the point of what you're saying.

I ignore all of the .NET and C ecosystem and I have absolutely no interest in them for many reasons, but that's not saying much about anything. Just because you don't care about Javascript doesn't inherently make it's ecosystem so bad.

Every time I think of Javascript language concept, I think about Lisp, and every time I think of "javascript fatigue" I think of Lisp Curse.

I think that the core feature of JS and Lisp is the fact that there's no concept of "compile time". Declaring classes, methods, even entire language concepts like promises happens entirely in runtime, and the language is soft to touch that every programmer with a healthy dose of curiosity and love for his craft is trying to build his own OOP system on it at some time.

This softness allows for incredible freedom for a programmer, and incredible speed of development of the language. But freedom is dangerous, both when you work with code written by others (often idiots, either only in the eyes of maintainer or completely objectively) and when you just support your own codebase that you wrote several years prior. Would anyone expect anything else from language with such capabilities?

> Lisp is the fact that there's no concept of "compile time".

The first Lisp compiler was finished in 1960.

Naturally Lisp has the idea of 'compile-time'.

> Declaring classes, methods, even entire language concepts like promises happens entirely in runtime

Let's see. I have a file with these contents:

    (defclass foo () (a b c))

    (defmethod bar ((a foo) (b foo))
      (+ (slot-value a 'a)
         (slot-value b 'b)))

Now let's use a Lisp compiler (!), here SBCL:

    $ sbcl
    This is SBCL , an implementation of ANSI Common Lisp.
    More information about SBCL is available at <http://www.sbcl.org/>.

    SBCL is free software, provided as is, with absolutely no warranty.
    It is mostly in the public domain; some portions are provided under
    BSD-style licenses.  See the CREDITS and COPYING files in the
    distribution for more information.

compiling the file:

    * (compile-file "compile-test.lisp")

    ; compiling file "compile-test.lisp" (written 16 MAR 2016 07:34:51 PM):
    ; compiling (DEFCLASS FOO ...)
    ; compiling (DEFMETHOD BAR ...)

    ; compile-test.fasl written
    ; compilation finished in 0:00:00.020
    #P"compile-test.fasl"
    NIL
    NIL

Wow, the sbcl Lisp compiler just compiled the file and generated the code for a class and a method using that class.

Let's see if sbcl knows about the class:

    * (find-class 'foo)

    debugger invoked on a SIMPLE-ERROR:
      There is no class named COMMON-LISP-USER::FOO.

    Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

    restarts (invokable by number or by possibly-abbreviated name):
      0: [ABORT] Exit debugger, returning to top level.

    (SB-PCL::FIND-CLASS-FROM-CELL FOO NIL T)
    0] 0

Oh, it doesn't know about the class. We are no longer in 'compile time'. The class was only known during 'compile time', a concept you said Lisp does not have. sbcl seems to have it. Funky.

But we can load the generated machine code:

    * (load "compile-test")
    STYLE-WARNING: Implicitly creating new generic function COMMON-LISP-USER::BAR.

    T
    * (find-class 'foo)

    #<STANDARD-CLASS FOO>
    *

Now it knows about the class.

> Would anyone expect anything else from language with such capabilities?

Lisp has a lot of code bases which are large and maintained for 2 or more decades. Common Lisp has especially been designed to support compilation in various forms and to support the development of complex/large systems. One gets a lot of support from compilers like sbcl for doing so.

I love to see someone summarize the most successful websites and the JS stack/build tools they are based on.

stackoverflow : jquery + anything else? map.google.com : ? facebook : ? React (?)

see: http://stackshare.io.

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.

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

Well, read the source of jquery. You will see fixes for "old new features" of FF that broke applications in the past.

Given the way mozilla teams are still working I guess it can still happen.

EDIT and add the memory leaks and the change of performance that happens from time to time in new releases.

The problem now a days is phones. Their browsers work very different from desktop browsers.

And set top box that may have another version of JS.

Or the "javascript" used in Qt ... or any new appliance/software that wants to provide a common accessible language for their "events" and choose a JS that is patched to support stuff like hardware functions.

I have been using these kinds of FrankeinJS in the past.

When explorer 10 started reporting in js the availability of the firefox xml parser object but then it was not compatible and all code parsing xml suddenly broke for no reason, which is not javascript per se but it isn't like the language exists in a vacuum

Or if you want language proper at some point node allowed keywords to be used as properies.

Companies will never stop wanting better tools to build apps. The software industry is highly competitive - If tools didn't keep improving, established players (big companies) would have the upper hand. New tools allow increasingly small startups to compete against big companies - Being able to start fresh with the most cutting edge tools is a huge competitive advantage for startups.

I don't think progress will stop at React. Soon enough, we will have drag-and-drop web app builders - They will allow us to build web apps where all data will be live-bound in realtime. Adding new pages/functionality will be trivial.

Software developers won't stop until the tools become so convenient that they take over our jobs completely - We will be replaced with app designers and entrepreneurs.

Still waiting for that reality on the desktop side of things....

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?

A big problem I have run into on projects that have gathered dust for a few months has been when version wasn't pinned, or the package wasn't using semver, or some other drift in the package.json that causes a slightly or completely newer version to come down, which causes, a whole host of dependencies to update and then boom- hopefully you have unit tests to catch the breaking changes.

Also, when you check the project out and it was relying on global npm packages to build and the system you're working on has been updated in the last few months and now all of a sudden your grunt file doesn't run or your CSS minimizer complains about your Ruby version. God forbid you build multiple JS projects in one CI server!

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.

Or jQuery. That also has proved itself to be reliable.

Let the jQuery revival begin.

I've been enjoying the post jQuery 2.0 revival for a while now.

> Coffeescript was the first major player, created by Jeremy Ashkenas in 2009. ... Google’s Inbox was built with GWT (Google Web Toolkit)

GWT came way before CoffeeScript, in 2006.

I hate to sound curmudgeonly, but the reason the state of JS is always in flux is because app developers suddenly decide they want to do front end development, and they come in and say, "WTF, everything here is weird and broken. I'm going to fix it. Make it more like python/ruby/.NET/C++/LISP/Haskell/Objective-C".

So then some high brand developer heads up a project, it gets a lot of attention because a big name company adopts it, and then we're off to the races.

Before you know it, our simple little dynamic prototypal SCRIPTING language has Classes and typing and build systems and cascading transpilers.

I'm not saying we should go back to the bad ol' days of writing kitchen sink code for MVCs a billion times, but why do we need Typescript, Flow, Babel, Dart, Coffeescript, and Clojurescript? Why?

This is why I use ember. It may not be the fastest or the greatest, but its more than good enough (what I can build, stability, longevity etc.) and it's opinionated to the point where I really don't have to think about all of these pain points.

What I get most tired of is that all the tools nowadays seem to think they are at the center of their ecosystem, instead of doing things in the old "UNIX" style, where tools had clear I/O specs, and just worked well together.

'Most of the tools we use today didn’t even really exist a year ago: React, JSX, Flux, Redux, ES6, Babel, etc.'

ES6 is a new version of the language under discussion, Babel is a tool to allow you to compile code written in the new version into the old version. The other 4 examples are all closely related to each other, if you use JSX and FLUX you use React, if you use Redux you probably use React.

In other words while I believe fatigue exists and is probably warranted, these were bad examples of what would cause the fatigue.

that said if anyone can explain to me the benefits of webpack in comparison to my gulp.js build pipeline with real examples then it would be nice.

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?

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.

You don't need to try and keep up with every new library/framework/tool. Use what you want and pick new things up when you feel you want or need to.

Javascript fatigue is self inflicted.

We need stable platform for JS, like Fedora/Debian/etc. does for C. I.e. make snapshot of bunch of popular libraries with their dependencies, name that snapshot, e.g. «Jasmin-1», then accept security and bug fixes only in forms of patches to original source, like every distribution does. Call it "stable" and stick to it for at least 6 months. Then spin another release, "Jasmin-2".

"No other language does anything remotely resembling that kind of thing". Have you ever worked on a Java EE project?

I did JSF for 4 years, along with the rest of the Java EE stack. Glassfish web server. There was never churn like this . I was pretty enthusiastic about front end dev for years. I'm pretty burnt on it now though.

I didn't mean the churn (Java EE could do with more churn) I meant in terms of setting up a project and the number of dependencies.

The language itself is what is simultaneously causing this craziness and holding back real change. Half of the stuff out there is working around JavaScript's limitations. If a bytecode had been approved 15 years ago instead of blocked by JavaScript's own creator, we would be much better off today. WebAssembly is finally, finally a step in the right direction, but it's not a bytecode, either.

Site seems to be down for me.

Perhaps the server experienced javascript fatigue and quit.

They are swapping JS frameworks.

really interesting article!

Reply on news.ycombinator.com