14 ms·

The Deep Roots of JavaScript Fatigue

239 points by rapjs 11y ago

officialchicken 11y ago
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.
- zdragnar 11y ago
  > 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.
- cptskippy 11y ago
  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.
  - orvr 11y ago
    Amen
- cubano 11y ago
  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.
  - wonnage 11y ago
    You can either shut yourself off from it and cement yourself into "oldman" oblivion, or actually try to understand why these tools exist.
    - LoSboccacc 11y ago
      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.
    - manyxcxi 11y ago
      > 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...
- extrapickles 11y ago
  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.
  - madeofpalk 11y ago
    > 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.
tkinom 11y ago
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 (?)
- maze-le 11y ago
  see: http://stackshare.io http://stackshare.io.
mixedCase 11y ago
Site seems to be down for me.
- foobarbecue 11y ago
  Perhaps the server experienced javascript fatigue and quit.
  - i_feel_great 11y ago
    They are swapping JS frameworks.
sosuke 11y ago
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.
- reitanqild 11y ago
  Or jQuery. That also has proved itself to be reliable.
  - davydka 11y ago
    Let the jQuery revival begin.
    - techdragon 11y ago
      I've been enjoying the post jQuery 2.0 revival for a while now.
deleted 11y ago
[deleted]
julie1 11y ago
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.
- woah 11y ago
  When was the last time an existing application stopped working because of new JS features?
  - julie1 11y ago
    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.
cognivore 11y ago
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.
PhilWright 11y ago
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.
- prewett 11y ago
  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.
  - manyxcxi 11y ago
    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.
    - samcodes 11y ago
      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.
copperx 11y ago
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.
- nly 11y ago
  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.
  - cgh 11y 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.
    - deleted 11y ago
      [deleted]
    - pcwalton 11y ago
      > 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.
      - gcb0 11y ago
        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.
vmware505 11y ago
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. ;)
- seanwilson 11y ago
  > 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".
  - BWStearns 11y ago
    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?
- fokinsean 11y ago
  Yeah, Ember is awesome. Hassle free tooling and you can get up and going in minutes.
- anonyfox 11y ago
  Ember even has a LTS version now!
- mpk 11y ago
  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.
vmware505 11y ago
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. ;)
sdnguyen90 11y ago
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?
- manyxcxi 11y ago
  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!
samcodes 11y ago
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.
- madeofpalk 11y ago
  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 https://twitter.com/iamdevloper/status/707146929075949568
  - porker 11y ago
    > 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]
marssaxman 11y ago
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?
- phpnode 11y ago
  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.
  - marklgr 11y ago
    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.
    - noir_lord 11y ago
      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 http://knockoutjs.com/spec/runner.html
- madeofpalk 11y ago
  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.
LukeB_UK 11y ago
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.
- lisivka 11y ago
  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".
UweSchmidt 11y ago
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.
- Flow 11y ago
  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?
  - UweSchmidt 11y ago
    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.
irahul 11y ago
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 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...
- madeofpalk 11y ago
  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.
  - irahul 11y ago
    > 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.
jondubois 11y ago
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.
- tomc1985 11y ago
  Still waiting for that reality on the desktop side of things....
Shicholas 11y ago
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.
amelius 11y ago
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.
aedron 11y ago
> 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.
br3w5 11y ago
"No other language does anything remotely resembling that kind of thing". Have you ever worked on a Java EE project?
- dham 11y ago
  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.
  - br3w5 11y ago
    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.
edtechdev 11y ago
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.
samth 11y ago
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.
NDizzle 11y ago
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/f010a3aad1006eab897f0acbcbb84c9a.jpg https://s-media-cache-ak0.pinimg.com/736x/f0/10/a3/f010a3aad...
- brightball 11y ago
  > 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.
- dham 11y ago
  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.
  - sklivvz1971 11y ago
    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-navigation-release-candidate http://meta.stackoverflow.com/questions/308875/new-navigatio... Disclaimer: I was one of the developers.
    - dham 11y ago
      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.
golergka 11y ago
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?
- lispm 11y ago
  > 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.
deleted 11y ago
[deleted]
dclowd9901 11y ago
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?
bryanrasmussen 11y ago
'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.
- bryanrasmussen 11y ago
  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.
afrancisboeuf 11y ago
really interesting article!

239 points by rapjs 11y ago

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.

zdragnar 11y ago
> 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.
cptskippy 11y ago
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.
- orvr 11y ago
  Amen
cubano 11y ago
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.
- wonnage 11y ago
  You can either shut yourself off from it and cement yourself into "oldman" oblivion, or actually try to understand why these tools exist.
  - LoSboccacc 11y ago
    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.
  - manyxcxi 11y ago
    > 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...
extrapickles 11y ago
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.
- madeofpalk 11y ago
  > 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.

tkinom 11y ago

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 (?)

maze-le 11y ago
see: http://stackshare.io http://stackshare.io.

mixedCase 11y ago

Site seems to be down for me.

foobarbecue 11y ago
Perhaps the server experienced javascript fatigue and quit.
- i_feel_great 11y ago
  They are swapping JS frameworks.

sosuke 11y ago

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.

reitanqild 11y ago
Or jQuery. That also has proved itself to be reliable.
- davydka 11y ago
  Let the jQuery revival begin.
  - techdragon 11y ago
    I've been enjoying the post jQuery 2.0 revival for a while now.

deleted 11y ago

[deleted]

julie1 11y ago

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.

woah 11y ago
When was the last time an existing application stopped working because of new JS features?
- julie1 11y ago
  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.

cognivore 11y ago

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.

PhilWright 11y ago

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.

prewett 11y ago
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.
- manyxcxi 11y ago
  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.
  - samcodes 11y ago
    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.

copperx 11y ago

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.

nly 11y ago
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.
- cgh 11y 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.
  - deleted 11y ago
    [deleted]
  - pcwalton 11y ago
    > 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.
    - gcb0 11y ago
      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.

vmware505 11y ago

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

seanwilson 11y ago
> 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".
- BWStearns 11y ago
  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?
fokinsean 11y ago
Yeah, Ember is awesome. Hassle free tooling and you can get up and going in minutes.
anonyfox 11y ago
Ember even has a LTS version now!
mpk 11y ago
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.

vmware505 11y ago

sdnguyen90 11y ago

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?

manyxcxi 11y ago
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!

samcodes 11y ago

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.

madeofpalk 11y ago
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 https://twitter.com/iamdevloper/status/707146929075949568
- porker 11y ago
  > 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]

marssaxman 11y ago

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?

phpnode 11y ago
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.
- marklgr 11y ago
  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.
  - noir_lord 11y ago
    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 http://knockoutjs.com/spec/runner.html
madeofpalk 11y ago
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.

LukeB_UK 11y ago

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.

lisivka 11y ago
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".

UweSchmidt 11y ago

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.

Flow 11y ago
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?
- UweSchmidt 11y ago
  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.

irahul 11y ago

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

madeofpalk 11y ago
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.
- irahul 11y ago
  > 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.

jondubois 11y ago

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.

tomc1985 11y ago
Still waiting for that reality on the desktop side of things....

Shicholas 11y ago

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.

amelius 11y ago

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.

aedron 11y ago

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

br3w5 11y ago

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

dham 11y ago
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.
- br3w5 11y ago
  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.

edtechdev 11y ago

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.

samth 11y ago

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.

NDizzle 11y ago

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/f010a3aad1006eab897f0acbcbb84c9a.jpg https://s-media-cache-ak0.pinimg.com/736x/f0/10/a3/f010a3aad...

brightball 11y ago
> 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.
dham 11y ago
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.
- sklivvz1971 11y ago
  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-navigation-release-candidate http://meta.stackoverflow.com/questions/308875/new-navigatio... Disclaimer: I was one of the developers.
  - dham 11y ago
    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.

golergka 11y ago

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?

lispm 11y ago
> 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.

deleted 11y ago

[deleted]

dclowd9901 11y ago

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?

bryanrasmussen 11y ago

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

bryanrasmussen 11y ago
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.

afrancisboeuf 11y ago

really interesting article!