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?<p>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.<p>Yeah, it's frustrating as shit, we needed to all be pissed about it for a bit, but let's have a productive conversation.
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.<p>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.<p>I'll welcome all you bleeding edge javascript hippies back with open arms. But you have to use the side door. <a href="https://s-media-cache-ak0.pinimg.com/736x/f0/10/a3/f010a3aad1006eab897f0acbcbb84c9a.jpg" rel="nofollow">https://s-media-cache-ak0.pinimg.com/736x/f0/10/a3/f010a3aad...</a>
We are simply going through a Cambrian explosion in the JavaScript ecosystem.<p>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.<p>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.<p>I intend to enjoy the ride and look forward to the improved productivity and capability of web apps that results from the chaos.
So much of this history is wrong.<p>1. ECMAScript is called that because Sun (now Oracle) owns the JavaScript trademark, not because anyone wanted to be diplomatic.<p>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.<p>3. The creation of the spec was driven in significant part by Microsoft, whose internal spec documents formed the initial basis for ES1.<p>4. The "harmony" name came entirely after the end of ES4.<p>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.<p>6. Neither JScript versions nor Spidermonkey's JavaScript versions ever had a significant impact on JS on the web.<p>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.<p>> Babel has worked it’s way into the standard Javascript toolchain, and now most builders include it as a first-class plugin<p>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.<p>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.<p>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.
The JS development landscape is in a state of flux, and it's overwhelming for someone not familiar with it.<p>I was just working on getting a react-redux TODO template ready and number of things I had to read up on was enormous.
<a href="https://github.com/rahulkmr/react-redux-todo" rel="nofollow">https://github.com/rahulkmr/react-redux-todo</a><p>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.<p>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.<p>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...
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?
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.<p>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.<p>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.<p>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 was taking a shower, and this question popped into my head: What is harder to master nowadays? C++/STL/Boost or the Javascript ecosystem?<p>I don't know the answer.
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.<p>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.<p>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?
I love to see someone summarize the most successful websites and the JS stack/build tools they are based on.<p>stackoverflow : jquery + anything else?
map.google.com : ?
facebook : ? React (?)
well javascript is evolving at a fast pace.<p>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.<p>Browser ecosystem is just running amok in terms of speed diversity and complexity.<p>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.<p>JS fast pace == a lot of manpower to keep application just up to date. It is a continuous growing bleed in the budget.<p>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.<p>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.<p>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.<p>Industry out of IT requires for boring stable LTS technologies. The opposite of the offer of modern IT.<p>When offer does not meet demands ... company fail.<p>If ever USA or Europa, India, China announce a recession in 2016 or 2017 there will be blood in the IT.<p>It is all about costs and prices and making benefits at the end.
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.<p>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.<p>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.
Curious questions for those who complain about Javascript fatigue:<p>What reasons are you're dropping your old libraries/frameworks in favor of the new ones?<p>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?
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.
> Coffeescript was the first major player, created by Jeremy Ashkenas in 2009. ... Google’s Inbox was built with GWT (Google Web Toolkit)<p>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".<p>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.<p>Before you know it, our simple little dynamic prototypal SCRIPTING language has Classes and typing and build systems and cascading transpilers.<p>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.'<p>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.<p>In other words while I believe fatigue exists and is probably warranted, these were bad examples of what would cause the fatigue.
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.<p>I predict eventually we'll come full circle and get something like ASP.NET forms with Javascript controls that spans both frontend and backend.
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.<p>Javascript fatigue is self inflicted.
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.