The State of JavaScript in 2015

http://www.breck-mckye.com/blog/2014/12/the-state-of-javascript-in-2015/

by sahara • 12 years ago

675 217 12 years ago

yeskia• 12 years ago

How is this churn any different to other languages at the height of the popularity? Every other web programming language seems to have it's defining framework (whether it be a collection of quality packages or entirely first party code). From Rails to Django to Symfony to MVC, plus not forgetting that each language also has a popular "slim" framework also.

I see no reason why that would differ in the JavaScript world - whether it be front-end or back-end. Angular's changes may have burned a lot of developers but it could just be teething problems - learnt some critical lessons on the first round and resolving them before it's too late. I fully expect to see a solid MVC framework on the backend, whether it's Sails.js or something else that comes along.

mattxxx2• 12 years ago

idk; I've been focusing on all things javascript for the past two years, and I can relate to the "alienation" the author is describing. I mostly write vanilla (or +underscore) and AngularJS, and it feels like you have to constantly compare things, because so many of the workflows don't feel right.

AngularJS scales really well on gigantic applications, and it felt like there was going to be some stability from the corporate-world, but now it's gone.

Frontend code is so hard to maintain well (compared to backend), and now it's going to cost companies millions of dollars to migrate: retraining, migration, unit-testing, QA

sigh...

Bahamut4• 12 years ago

The stability will still be there - the first evidence of breaking changes was at ng-conf back in January, when Vojta presented about di.js. In addition, Angular 2.0 won't come out for over a year (I'd bet on 1.5 years from now given the tendency for timelines to slip - 1.3 was originally supposed to come out a year ago), and Angular 1.x will be supported for 1.5 years after that. That's at least 3 years of active development in 1.x. Meanwhile, the development ecosystem will probably have finally adopted Web Components and ES6 as the norm for development, and so it would give the perfect opportunity to evaluate options to migrate to then.

Web Components looks hugely promising as the path for independent components - essentially what Angular directives were meant to be in the absence of such browser technology.

sramsay2• 12 years ago

Check out http://dailyjs.com/ some time. Granted, it's devoted to all things JS (not just frameworks), but the number of libraries and microframeworks and plugins for frameworks is absolutely astounding.

I don't remember ever seeing anything like this level of churn, and I've been programming since the early nineties. Not with Java, not with Python, not with anything.

Someone above mentioned rolling their own stuff with vanilla JS (which provoked an immediate invocation of Greenspun's tenth rule). My sense is that a lot of people start out this way and say, "Lo, a library! Github!"

One hopes that the cream rises to the top, but I'm drowning in milk.

cozuya2• 12 years ago

Relying on reddit for all of your "temperature gauges" of the JS community probably isn't for the best.

state• 12 years ago

I would tend to agree, but what would you recommend instead?

cozuya2• 12 years ago

Good question. I guess here, and Twitter? ugh. There's nothing "centralized" for cutting edge javascript development (hopefully not an oxymoron..), so I consume a few different places daily. I don't feel like I'm missing out on things that's for sure.

davidgerard3• 12 years ago

One cause of the syndrome is relying on HN as your temperature gauge of technologies. A lot of the reason I keep up with HN is as a heads-up on what half-formed l33t technology will next become my problem.

mattxxx2• 12 years ago

Frontend JS is so hard to tame, and it feels like everyone has such varied and strong opinions on it. I'm with the author on continual shake-ups in frontend dev, but maybe with better support for DOM stuff, and framework agnostic dependency stuff, we might have gotten somewhere just as some of the rug got pulled out.

Sigh... with AngularJS 2, I'm shuddering at all the unit tests that will have to be rewritten.

err4nt• 12 years ago

Well said Breck! As a front-end dev it feels like a hurricane of new libraries and frameworks all the time.

Two years ago I decided that the best course of action would be for me to really dig into HTML and CSS, and ive been learning vanilla JavaScript as well, and that combination has worked and will continue to work. Im leery of anything I couldnt write myself, but if I can take an existing library and expand on it and make it my own that saves me time and I know I wont have to worry about compatibility changes down the road.

oakaz• 12 years ago

If you close your ears to people who try to spread the words of unix philosophy, this is where you find yourself at.

For past 4 years, there is NPM, and there is people trying to explain why you should build your software with modules instead of frameworks.

mhd• 12 years ago

That was the vision of OOP, too ("Software ICs") and we all know how well that turned out. Even Unix is not really the big success story here -- one might say that even something like 'awk' is already stretching the paradigm, never mind common fellow travelers like Perl or Emacs. Never mind most graphical interfaces.

I know, this will probably evoke a "No true Unixman" response, maybe even with pointers towards the Plan 9 highlands, but the truth is that a) connecting stuff is hard and b) a good connection is often a prime feature itself.

Especially the latter will result into a plethora of modules of its own, for nearly all possible combinations of component modules. The end result is even more "frameworks". Sure, they're going to be modular frameworks, but I don't really know whether that's going to help the developers who live in the uncanny valley of mostly knowing what's there and how it connects.

A "fat kernel" with lots of "satellite modules" might be a viable approach, too. Just like with most programming languages (i.e. not C or JavaScript), where you've got plenty of useful stuff in your standard library, and some package manager for the rest.

But hey, if the JavaScript ninjas finally figure out how to properly combine software components, that would be better for all of us. I just wouldn't bet on that.

rurabe• 12 years ago

I agree that fragmentation is a problem, but don't understand why the solution to that problem should be smaller, fragmented libraries instead of larger, complete frameworks. Isn't that the same problem described in combining all the tools with small market/mind share? In my experience, far more problems arise from the interaction of separately authored modules versus the interaction of modules designed to work together. Not to mention that there will be far more blogs and SO posts about a larger framework.

bsaul• 12 years ago

I came to say the same. If you multiply the number of dependencies, owned by different people, having different interest, you multiply the chances of having to catch up with a problematic update.

On a more general pov, the debate between "integrated design" and "modularized" design has been going on for decades. We know the advantage of both. The problem right now is that angular made a desition to break compatibility in a major way while their framework was barely becoming mainstream. Let's not make it a bigger problem.

People that invested in the .net framework, or in the unity framework, did not make a blunder. All we need is an equivalent in the front end js world.

ryanmk• 12 years ago

I'm glad I read this article. I just started experimenting with javascript for web development, and I've encountered so many Named Swords.

ben336• 12 years ago

So there seem to be 2 separate issues this post is addressing.

1. A lot of JavaScript frameworks are being released 2. JavaScript frameworks are being updated too fast.

His biggest example, the Angular 2.0 split, is of the second one, but he seems primarily concerned with the first one.

I can see the first one being a problem primarily for developers keeping their skills up to date. The fact is that once you've put a decent amount of code down into an application, you're not going to be constantly switching frameworks. Maybe do it once, but otherwise the applications that are already built will stay on a stable foundation. So for developers working on a single or stable set of applications (not client work), this shouldn't effect their actual work. There may be an issue of skill decay if employers are constantly looking for the latest and greatest, but outside the Silicon valley bubble, I still see a lot more jQuery and Backbone job postings than Ember or React.

As for the issue of frameworks lacking stability, I frankly don't see that. Yes Angular is making big breaking changes. But otherwise? Let's look at the other 6 biggest front end libraries/frameworks.

jQuery has been fairly stable for a few years now, with minimal breaking changes.

Underscore has been very stable, albeit growing with competition/help from Lo-Dash

Knockout and Backbone have evolved slowly while remaining small and very small respectively.

Ember has a very clear process for moving their framework while allowing actively developed applications to stay up to date in a reasonable way.

React is still pre 1.0 and that's something you should know going in.

Basically if you started a project with any of those technologies (or angular for that matter) at some point in the past 3 years, you've probably had a pretty easy time in adjusting as the library specific concepts have changed.

I just don't see the idea of "Frameworks are evolving too quickly" as being particularly compelling. There's a lot of information out there. Yes if you want to know it all and always be using the newest shiny thing, it will probably be too much. But none of this is preventing anyone from actually building useful things today.

joesmo3• 12 years ago

I'd say the Angular 2.0 split actually fits your first point (A lot of JavaScript frameworks are being released) rather than your second as essentially, it is a new library that shares only the name. The way I see it, Google is deprecating Angular 1.0 and creating a new library which will also be called Angular (2.0) but might as well be called something else. This bungling is rather typical of Google open source projects and I agree with the author on being aware of corporate sponsorship. I'd add to that, especially of Google, whose track record in this space (front end) is abysmal and whose track record in general as far as developer technologies is mediocre at best.

marknutter8• 12 years ago

It shares more than just the name. The Angular rewrite was unavoidable if they had any hope of integrating seamlessly with web components. They also remove a lot of the concepts that people lambasted Angular 1.0 for and end up with a much more elegant framework. It seems they were damned whether or not they wrote Angular 2.0 - people would either bitch about the current framework for being convoluted in places or bitch about the new one for having breaking changes.

ux-app• 12 years ago

"Prefer dedicated libraries to monolithic frameworks", this is the money quote for me.

I got burned a long time ago when I wrote a large personal project using ExtJS (~1.2 i think). Breaking changes, coupled with a kitchen sink mentality soured me against large frameworks.

It's vanilla JS with a few small very targeted libraries to fill in the gaps from now on for me.

doublerebel• 12 years ago

This only refers to frontend JavaScript and reflects the opinion of a dev who hasn't been using JS all that long. Angular was never that great a framework, it's popularity was by and large because it came out of Google. It's far too tightly coupled to the DOM and was therefore destined to have problems as HTML and browsers evolve.

Npm is stable, Backbone is stable, Node is stable, Gulp is great, and devs like myself who have seen trendy frameworks come and go (Batman.js and jQuery templating come to mind) are still using the same great composable tools that were better designed from the start.

Backbone (and my favorite, Spine) are built on more loosely coupled components and can be used on applications which have no DOM, such as Canvas games or native mobile apps. Browser fragmentation has been an issue since the dawn of JS -- and these days the JS ecosystem extends far beyond the browser.

Take a look at the mature tools for front or backend that major companies rely on and be glad that the open-source nature of JS produces so many options and rapid evolution.

venomsnake• 12 years ago

My brief encounter with angular - you write something, throw it into a black box, magic happens, and you receive output.

When it works - works fine. When it does not work you are completely helpless.

pluma7• 12 years ago

When it doesn't work, that usually means you have to learn implementation details like the digest cycle, which flies completely in the face of having these abstractions in the first place.

sramsay2• 12 years ago

Which summarizes the reasons for my hesitance toward anything that looks like a "framework." And here, we're talking about an old problem . . .

pluma7• 12 years ago

Factors in Angular's success:

* backed by Google * MEAN * plenty of media/blog coverage * seductive examples (that don't reflect best practices)

My personal gripe is with the last point. A lot of the appeal is in the two-way binding -- which is often the first thing to go out of the window once scaling becomes a problem.

Also, I have no idea why the author thinks Browserify and Angular go well together. They don't. At all. Browserify is great on its own, but there's not really any "blessed" way of using a module system with Angular (and like jQuery Angular 1.x is tightly coupled with the global scope).

mk32• 12 years ago

Regarding seductive examples. I recently found out, that most of the examples even example apps are lacking best practices, and in many cases even basic security measures. Good example make a e-commerce app using x and x technologies, and then disclaimer that this app is just to show how fantastic framework x is. Many frameworks js, php name it have disastrous examples, which are oversimplified for the sake of understandability, and then all hell breaks loose when someone finds out that, for example, by default csrf policy, or authorisation is not implemented correctly or not implemented at all.

Illniyar3• 12 years ago

I haven't seen two-way binding go out the window with scaling.

It's still the number one selling point and greatly reduces development time in both small and large applications.

The only thing I've seen is that in bigger projects, if there are locations where huge amounts of binding might take place (such as drawing, tables, etc...) you don't use two-way-binding in that particular place.

And in any case many of the popular frameworks (Ember, backbone etc... ) also use two-way binding, they just don't support two-way binding on simple js objects. And for that many of the bigger frameworks (

flipside• 12 years ago

If you like backbone, definitely check out http://ampersandjs.com. They've taken backbone and split it into separate modules with some nice upgrades.

tragic2• 12 years ago

website appears to be dead.

Alex3917• 12 years ago

It's far too tightly coupled to the DOM and was therefore destined to have problems as HTML and browsers evolve.

Maybe in the sense that the APIs will have to change as browsers evolve. But isn't there also some benefit from staying tightly coupled with the DOM? I know that React claims the fact that they are loosely coupled with the DOM is a benefit, but I'm not sure I really understand how this is inherently an advantage.

hrish20064• 12 years ago

I wonder if we need any JavaScript framework at all, given how far JS has come in recent years, yes, I use an MVC framework currently for the apps I'm building but I'm writing more and more of my apps these days using nothing but vanilla JavaScript(ES-6 to be exact) and the dom apis, and I'm not depending upon any framework. (well, I use traceur but only because ES-6 support is not fully baked in to all browsers). IMO the frameworks that are all out there today are simply too big and try to do too much for you. The only libraries I use from time to time are underscore, d3 and moment.js.

indubitably• 12 years ago

This. A lot of the frameworks are doing things that can sort of be done with vanilla JS now — personally I’m waiting on Object.observe to become more widespread.

hrish20064• 12 years ago

Yes. Object.observe, arrow functions, comprehensions, yield and yield* + promises, what more do you need? :)

pluma7• 12 years ago

I'm finding that in many cases the old adage holds true: "You're always using a framework. Either you're using an existing framework, or you're building your own." (paraphrased)

Sure, if legacy browser support is not a concern and you don't need to support bleeding-edge features (i.e. unstable APIs), you can go a long way with vanilla JS. But at some point any large system needs abstractions in order to stay maintainable. And if you don't use existing abstractions, you'll have to come up with your own abstractions.

Of course the other option is to simply not build large enough systems to require abstractions.

That said, I do prefer smaller libraries, too. This is why I see React not being a full replacement for all of Angular as a feature rather than a limitation.

I only ever began considering Express as a framework when it dropped the vast majority of its features (mostly middleware) in 4.x, too.

hrish20064• 12 years ago

Well, a custom framework might evolve when you write everything using just JavaScript, but I've found that when such a thing does happen, it suits your needs perfectly. Even if I screw up, I'll at least know where to look when I'm debugging :)

marknutter8• 12 years ago

This works ok if you're a single developer working alone on a project. This becomes very difficult in a larger group where you have some turnover and everyone has different backgrounds. Having a framework that makes a lot of the decisions for you greases the wheels to productivity. Give engineers an inch to bike-shed, they'll take a mile when choosing the paint color.

dpweb2• 12 years ago

I think alot of the devs today have grown up with all this frameworks on top of other frameworks. The problem is you lose power with every layer of abstraction. It's the price you pay for it. They also abstract at too low a level, especially since browsers have caught up. They don't need provide a new custom ajax for instance, XHR as implemented in the browser works quite well without imposing an arbitrary syntax on top. So I think people have moved increasingly to vanilla. We've come full circle with the opinionated frameworks and some people are frustrated and where do we go now?

Web components are the most promising development, because the preferred approach in sw development has always been isolation/separation of concerns. This is pretty much the opposite of the JQuery style. In theory you can separate using JQuery but in practice still in 2014 you cannot look at source in any moderately complex web app and understand what's going on. Ultimately, its going to have to be a DOM/JS mix (Those aren't going away for a long time) but they never got it quite right. The web component frameworks are the best thing going for the future.

IMO they should be declarative, that is - in the HTML - but programmable, and that's the way things have been heading. So in 10 years we'll still have the DOM and JS (although it would be interesting to have more languages easily usable in the browser). As Polymer evolves it (or some equivalent) will make it into the browser.

Offler5• 12 years ago

IMO they should be declarative, that is - in the HTML - but programmable, and that's the way things have been heading.

Sounds like React. WCs templates aren't programmable that's a DSL that is specific to Polymer.

dpweb2• 12 years ago

The mingling of HTML/JS in React I find unattractive (at best) but I'll have to look into React some more.

d0m• 12 years ago

Yeah, I agree. I lost faith in Angular (Even the 1.x). From now on I'll be using React for the view and a mix of amazing smaller libraries for the rest.

cageface2• 12 years ago

By using small libraries – components with a dedicated purpose and a small surface area – it becomes possible to pick and mix, to swap parts of our front end stack out if and when they are superceded.

This is the problem with front-end dev in a nutshell. Everybody is mixing and matching their own solutions which makes it impossible for an ecosystem of higher level, reusable components to emerge. Compare this to iOS, for instance, where I can go pick and choose from a huge online library of prebuilt components and be fairly confident I can just "pod install" them and go. I'm not a fan of Angular but it was a good thing for there to be something like a de-facto SPA framework standard. I can only imagine how upset business owners that invested heavily in Angular 1 apps are feeling now.

If web developers are serious about mounting a challenge to the rising tide of native apps, they need to build some consensus and agree on some durable foundations. In the end elegance and novelty count for nothing if you don't have a healthy, stable ecosystem upon which businesses can depend. It's sad to think that the freedom that makes web dev so appealing may also turn out to be its fatal weakness.

sehr• 12 years ago

Compare this to iOS, for instance, where I can go pick and choose from a huge online library of prebuilt components and be fairly confident I can just "pod install" them and go

I believe this is the one of the main motivators behind web components

cageface2• 12 years ago

I haven't built anything non-trivial with web components but I do like where they're going with them in principle. The biggest problem I see with WC is that they require native browser support to really function properly and I'm not sure it's really in Apple's or Microsoft's best interest to support them. AFAIK Apple hasn't made any indication so far that they will support the WC spec.

rictic• 12 years ago

Having worked with web components over the past few months, yes this. I can mix and match polymer, x-* elements, brick components etc with ease. I don't have to care how a given component is written or what its dependencies are. It's definitely the future.

wycats2• 12 years ago

This is actually more than just web components. iOS and Android have shared application architecture, tools, and navigation between screens. On the web, we'll never have "one true" solution to these problems, but the animosity towards attempts to provide holistic solutions on par with our native brethren sure isn't helping.

If you want to evaluate anew and put together dozens (or hundreds) of tiny modules on every new project, and maintain/evolve that collection over time, fine. But we don't need to tell people that something is deeply wrong if they want a full front-end stack that evolves as the web changes. Nothing is wrong with solutions that track best practices and evolve to incorporate more common problems.

je423• 12 years ago

What prevents you do a "npm install" ?

briantakita2• 12 years ago

People who paid attention to Rails upgrade issues over the years saw issues with heavy frameworks that abstract a bit far from the input & output.

Simple libraries often mean less maintenance headaches, more flexibility, and better productivity over the long term. YMMV of course ;-)

Exoskeleton looks like a promising microframework replacement for Backbone.js - http://exosjs.com/

---

Edit: re: downvotes. I know, sometimes it hurts to hear there are other ways that may be more optimal. Been there. Developing software is hard sometimes but it's a craft :-)

bbcbasic• 12 years ago

Why is maintaining a Rails application a mess? Yes if everything gets stuffed into controllers/models then maybe. But you don't have to do that.

briantakita2• 12 years ago

The upgrades have been historically been quite painful. Especially from v2 to v3.

Perhaps it's better now that the api has stabilized a bit. I've been using node.js & some Sinatra lately.

Upgrades tend to be smoother & due to less monolithic libraries. Also, the app startup time & TDD cycle tends to be faster with slimmer libraries.

It's also nice to be close to http vs the ambiguous controller methods & complicated route files.

Plus ActiveRecord is slow, especially with collections. The business logic can often be implemented in simple functions, resulting is less abstraction overhead.

krebby• 12 years ago

I work on Exoskeleton and Backbone. How are you liking it in your project? Anything you'd like to see different?

empthought2• 12 years ago

Can someone more invested in the SPA/rich internet application JavaScript state-of-the-art explain to me what is unappealing with the Dojo toolkit[1]? Of all the frameworks I've seen, it's appeared to have the most consistent and sustained developing, documenting, and extending efforts, over the past six years or so.

But I'd rather be programming iOS any day, so maybe my tastes in client-side application programming are very out-of-step.

[1] http://dojotoolkit.org

mimo84• 12 years ago

Where I work we decided to avoid using libraries and frameworks, because decisions taken at that level was do not give us the flexibility to deal with the problems that we face. The main issues we found were:

1. Change of behaviour between versions, (e.g. the way a frameworks integrate with a page)

2. Reliance on functionality being supported into the future

3. Customer expectations

4. Browser support

That said, it is true that a frameworks gives you the ability to put together an app in a few weeks. However, when you know that what deal with with something that needs to be maintained for years than knowing what does each piece of your code is far more important.

Bahamut4• 12 years ago

It's possible to do the same with a framework - it is also likely that frameworks and various libraries will be more performant and account for cross-browser issues. For example, I am not going to handcode JS logic with generating SVG for a graph - I'm going to use d3.

spyder81• 12 years ago

Well, sort of. It's possible if you're willing to take on maintenance of that library if/when they abandon it, and be able to dive into the guts to track down bugs or weird behaviour.

As a good example, we're on the verge of ditching JQuery.

btbuildem• 12 years ago

Seems relatively accurate to me. I understand the lean towards tiny fragments, there is less upfront investment / easier learning curve; this reduces risk. Perhaps with time we will see intermediaries emerge between light libraries and heavy frameworks - eg combinations of the former into subsets of the latter, suited for less general development.

dustingetz• 12 years ago

open source has won, we are innovating at faster and faster speeds than ever before, and the best innovations eventually bubble up to the top, bad ideas get peer reviewed out and thrown away before the whole world depends on them, this is amazing!

I for one am perfectly able to track all this innovation within my specialties (enterprise web dev) across multiple language ecosystems, and if I miss something, someone in my monkeysphere will make me aware of it, all of this fuss sounds like hot air to me.

Avalaxy• 12 years ago

Maybe because you're primarily a front-end developer? If front-end is not your fulltime job it's really hard to keep up with all the new frameworks and changes.

w4tson• 12 years ago

Agreed. I'm an enterprise dev who tries to keep a finger on the pulse but it can be quite difficult. I take my eye off the ball for 6 months and it turns out grunt is no good?! etc etc.

wycats2• 12 years ago

I completely agree with this post that there is churn fatigue. Part of that is in libraries, but an even bigger part of it is in the tooling that people use to build JavaScript applications.

It's easy to see all of these new things flying by, combined with changes to JavaScript itself, and feel completely overwhelmed. To be honest, over the past two years, even as a maintainer of Ember, I have experienced very serious hype fatigue.

This is a large part of the reason behind Ember's philosophy of finding and implementing strategies for stability without stagnation. On the one hand, people (including us) are tired of the constant barrage of new tools and techniques. On the other hand, it would be terrible to get beaten by a competitor that discovered a wonderfully productive new solution. The Ember team has spent the last few years honing a process for dealing with these conflicting desires.

That process involves:

* six-week release cycles, so every new change is incremental and adds value on its own

* canary, beta, and release channels (just like browsers), so that people will more appetite for churn can help test out features, and get them stable by the time they ship as part of a final release

* SemVer, so upgrading across final releases is relatively painless and the biggest part of our community can take advantage of the improvements as they roll out

* having each member of the core team build apps that we care about and maintain, so that we can feel the competing costs of maintenance and keeping pace with the latest and greatest first hand

The core ideas come from shipping browsers, which have had to deal with requirements of very strong stability with an increasing desire to "go fast". The pace of new browser features has been so good, in fact, that they have been used as an argument in favor of completely breaking things and starting over.

Ironically, the browser instead shows us that if we want to avoid stagnation, we are going to have to have strategies for bringing people along. Stability without stagnation is not a paradox; it's a recipe for success.

(we talked a lot more about the nitty-gritty technical details in the previously discussed Ember 2.0 RFC: https://github.com/emberjs/rfcs/pull/15)

sant0sk1• 12 years ago

FYI: Yehuda and Tom talked to us about "stability without stagnation" and other philosophies behind Ember 2.0 in episode 131 of The Changelog: http://thechangelog.com/131

notduncansmith• 12 years ago

FYI: You're replying to Yehuda.

jblow• 12 years ago

If the new tools and techniques were actually good, they would be enough for a while, and people wouldn't feel the need for even newer tools and techniques the next week.

This should be an obvious and automatic hype-temperer, but for some reason it isn't.

lhorie• 12 years ago

Interesting that the same problem (high churn) leads to two polarly opposite conclusions - i.e. the article suggests going with many specialized libraries, whereas Ember is on the camp of incorporating the latest and greatest into a single framework when it makes sense.

My opinion is that some types of features are better off bundled in a ready-to-go package. For example data binding and ajax almost always go together and just plopping a CDN link to Angular is a lot easier than installing NPM, setting up a file watcher and who knows what else to get React's JSX running (and you still need to go decide what you're going to use for AJAX).

Other less "core" types of features are better off as standalone libraries because their depth of usage can vary from not being used at all to requiring very domain-specific features (e.g. accounting.js is a good example of this). I don't agree with the author's premise that micro-libraries are easier to swap. I'd be very doubtful if anyone were to claim that it's trivial to convert a React codebase to Knockout, for example. You'd likely be hard-pressed to swap even things like moment.js because you probably chose the library based on it being better than its alternatives to begin with.

But having these types of features be standalone libraries does provide some benefits, e.g. being able to opt-out of a breaking release in a more granular fashion, trial-and-error-oriented development, etc.

noname123• 12 years ago

Good zeitgeist. I feel compelled to give my $0.02 as I was quoted in the blog as someone who "frankly feels completely overwhelmed." However, my criticism will be more from a programmer's perspective not so much a "web application developer" perspective.

Re: the chaos/churn in Javascript, forgetting for a minute the buzz-words of Backbone.js, React.js, Ember.js, Gulp, Angular etc. - they seem all to be a fight about MVC, traditional vs. single-page app vs. isomorphic.

I fail to see how improvements in these tools actually push us to create novel projects. While one can nit-pick about React.js rendering performance in its internal "DOM diff" model or Flux's "data flow architecture" in improving code readability, but they are just buzzwords to me like words-play in a post-modern novel or art that arrange concepts in their idiosyncratic way in an arbitrary aesthetic way; although sometimes the rearrangements can be beautiful, they are ultimately shrines to themselves and their creators and subculture.

Subculture because everyone wants something of their own and ignore interoperability. Although the data model are the same whether you're a single-page or isomorphic, there is no community standard to define standards to define your data models a la J2EE annotations or code-generated one's a la Google Protobuf. Same thing with single app controllers, no standard like RESTful web service spec that's universal and interoperable like between .net/Java/Python etc. that can be applied to say, Sail/Backbone/Ember/Angular.

Postmodern because they are always self-referential to the "Ember.js"/"Node.js" way of doing thing - when they all do the same thing which is rendering HTML elements on the web browser in 2014, much like Visual Basic rendering forms on Windows 95 desktop in 1997. Never mind all the touts about performance, architecture, when the users won't care about the diminishing return of shaving off some microseconds of your AMD JS module loading or the beauty of your invisible architecture.

IMHO, instead of a race to the bottom to the most "efficient" and "beautiful" stack to render HTML, I care more about the ideas that push the web as a medium, e.g.,

WebGL (http://www.chromeexperiments.com/webgl/),

Web Audio API (https://chromium.googlecode.com/svn/trunk/samples/audio/samp...),

Web Real Time Collaboration (https://togetherjs.com/ http://www.webrtc.org/)

carsongross4• 12 years ago

An alternative direction to head is back to the future: take the web for what it is and try to simplify AJAX interaction, rather than relearn all the hard lessons of client/server programming from the 80's, but in a hobbled browser sandbox.

This is what I'm trying to accomplish with intercooler.js: http://intercoolerjs.org/

charlysisto• 12 years ago

I appreciate this effort and will give it a try.

One of my main problem with javascript frameworks is having to drift away from the original server HTML. Not everybody wants to go the whole way down the Single Page Abbit hole. It's not only a question of speed or SEO.

I think many devs are both backend & front-end craftsmen, and as so build the backend first and then wish to 'grow' their frontend part on that foundation. Or ideally wish they could. Instead they have to fork the project into 1). the Good Ol' server HTML part 2). the API SPA part.

No matter how close angular or react (with jsx) stays to HTML, you still need to rewrite the whole view to comply with it's templating needs. There's no incremental evolution there, and worse : having to duplicate and sync maintenance on both ends, breaks the DRY principle which is fundamentally bad - since you end up with 2 sources of truth.

Pre-rendering the view with react on node (even if your on rails or whatever) may be a solution I don't know yet. Another take I guess would be to render your server html files with a template which complies with their JS counterpart. Yet another take would be to use HTML as the API instead of JSON - which is proven to work quiet well.

Anyways, just to conclude I think devs would feel more confident if they could rely a little more on the servers end while the frontend finds its ways and stabilizes a little.

mike_hearn3• 12 years ago

For an even more retro approach, perhaps some things are just better written as desktop apps. I know they're out of vogue at the moment, but I've been having good experiences with writing a JavaFX app lately. Particular points to note:

* I wrote my own online updates engine, that can be used to implement Chrome/Web style silent background updates, but which can also give control to the user over which version of the app they use. Users can downgrade at any time if a new version is buggy or just not as good as the previous version. It's very small, simple and easily integrated. It supports threshold signed updates so it's also suitable for high security apps where a hacked web server could be critical. It's called UpdateFX, check it out.

* JavaFX has a tool that creates native, bundled installers on each platform (dmg, exe/msi and deb). The user does not have to install JVMs or get any Ask Toolbar crap on their system. You remain in total control over JRE upgrades.

* UI is specified with an XML dialect called FXML, it's quite intuitive and anyone who knows HTML can pick it up quickly. But there's also (unlike with the web) a competent visual designer. You can style UI with a dialect of CSS and it's very easy to match the Twitter bootstrap look, native looks can be done too.

* Data binding is easy, the UI is OpenGL/Direct3D hardware accelerated, you can trivially apply effects like drop shadows or blurs and animate them, the API is clean, the entire framework is open source and the developers are responsive.

* Because it's not a web app, support for offline or flaky internet connections is second nature.

If your users can tolerate the initial download then it's a much more pleasant and robust development experience. If your users are the type who can't wait, you might want to stick with the web.

rattray2• 12 years ago

The improvements in these tools aren't supposed to push us to create novel projects. They're supposed to get out of our way. Some do better than others, and some paradigms can be more helpful than others. It makes sense that we have competing ideas and competing frameworks to implement those ideas.

Some projects get a bit flashy and buzzwordy, it's true. Bacon.js [0] always sticks out in my mind as a prototypical example, though I think it's tongue-in-cheek.

I try not to let that flashiness get in the way, though. The fact is, Bacon.js is useful to me, when I try to make beautiful and efficient code to render beautiful and efficient HTML. Their homepage doesn't change that. React's performance is impressive, and may be important to me; ditto with Flux and code readability. And the theories underlying those libraries (DOM diff and unidrectional data flow) are important too, so I know why I should expect them to be better.

[0] https://github.com/baconjs/bacon.js/

hammadfauz• 12 years ago

To me, it is not at all alarming. But it might be due to my inexperience in dealing with truly huge code bases.

No matter what framework, in the end it's all JavaScript. So even if I develop a flashy app using a nice fat framework, it is still going to run unless JavaScript itself is changed.

That said, I can build an app in Angular today, and when something flashier comes out, I can code new features/modules to my app using that.

AYBABTME• 12 years ago

I think the main problem is about fixes. Invariably, something is going to go wrong in the future with whatever framework you use. Either security related or else. Then your version of {{framework}} won't be supported anymore and you'll have to:

   - fix it yourself
   - give up: turn off your app
   - ignore: let people deal with the issue/be vulnerable

If your version of {{framework}} is supported, likely all you'll have to do is wait for a patch.

sosuke• 12 years ago

My stance has been to take a more static view of an applications development life cycle. So you're on an Angular 1.x app, Angular 2 is coming out in a year, your project will be launched or is already launched and you're concerned with switching.

Stop, right now, just let it go, take a step back from the bleeding edge and see that you've got all the JavaScript libraries and tools you need to put together any application you could imagine. If your imagination is big enough then you'll be hand writing your own additions in no time. So long as your applications runs on the major browsers latest-1 without issue there isn't a reason to upgrade. If you're writing a project there isn't a reason to make a framework jump, and if Angular 1 to 2 is that different, consider it a framework jump. Why feel bad about not knowing your way around when you go from one framework to another, would you feel the same going from Drupal to Wordpress? They are both CMSs, both PHP, both extended far beyond their initial goals. Angular 1 will go into maintenance if Angular 2 is that different, development will slow, and eventually you'll upgrade to Angular 3, which is incompatible with Angular 2, but after years of having a working application.

I've gone from Angular, to Kendo, to Ember, to Backbone. If you want to make an 'investment' in knowledge of front-end development learn the plain JavaScript, read through the framework you're using. Walk through the execution, that will allow you as a developer-for-hire to pickup the newest shiny on a new team with less issues.

Web development has always had this pace, whatever tool or setup you commit too, the next week someone will call you an idiot for using it. Ignore them, make something maintainable, nothing in the new framework is ever mission critical, just nice to have.

kalms• 12 years ago

I completely agree with this. Make sure you know the ins and outs of what's out there, but don't just follow trend blindly. Especially with a large team, or internal eco system.

I make a habit out of using smaller frameworks that gets the job done, and only that. Anything else or beyond, we code ourselves, or re-use from a different project. Or we just stick with older technology because we know it works. Sure, our productivity might initially be lower, but at least we save ourselves the pain of "the next big thi—oh wait, something new arrived let's switch".

tracker12• 12 years ago

Exactly... I worked on a project a couple years ago, and decided to use a beta version of bootstrap as the baseline for the project... I cloned the repo, merged the pieces into my project, and kept a copy of the docs at-that-time for reference.

The site still works great... the codebase is fine. It was before some later changes to bootstrap 3, so it isn't current with the released version, but it still works, and did better so than v2. The same goes for most things involving open-source tools. You can go through migration cycles, or accept and limit the scope of how you use it.

I always applied the same arguments for using Mono in places as a practical reasoning. So what if new development stopped/dropped or rolled.. as long as what I'm doing can keep running.

Your best bet is to keep your codebase modular so much as possible, and it makes it easier to replace certain pieces.

Today, I really like react + yahoo's flux implementation. There are some weird corner cases I've had to deal with, it's still nice. It really just depends on your needs.

grumblestumble• 12 years ago

The whole "use lots of little modules" idea is great on the surface, but when you have to build large applications with small teams, I find it fails:

- There are always multiple choices for each piece of functionality you need to address, and personality clashes over which is the "best".

- Security is a whole lot harder to nail down with more moving parts. Go with Angular, you have this: https://code.google.com/p/mustache-security/wiki/AngularJS. Similarly, Ember: https://code.google.com/p/mustache-security/wiki/EmberJS. Even though these frameworks aren't 100% secure (although Angular comes pretty close), you can be more aware of the pitfalls. The more independent modules you have to keep track of in your app, the more difficult it becomes to track security flaws.

- Some seemingly unrelated components just don't end up playing nice with each other, and this can be hard to determine ahead of time.

BuckRogers4• 12 years ago

I feel sorry for those stuck in web development. Native apps always were and still are the way to go. Appstore/Play and soon Windows 10's inevitable blastoff to mass popularity will bring a popular appstore to all 3 major platforms.

As the article states, there was a time a few years ago that js-all-the-things appeared interesting and unstoppable. To me it appears in 1 year when Win10 arrives, people will have better spent their time honing skills for native apps.

Webapps as people envision them (universal applications) will die- returning to their original intention. Document sharing and simple data collection/retrieval.

Blame Eich and Mozilla for that. They insisted on pushing no bytecode for the web. Wanting us to rely on Eich's JS + rest of the webstack monstrosity requiring ugly hacks.

mappu• 12 years ago

I don't see (comparatively) a lot of people targeting the Windows 8 app store that's been available for 2 years already. Most Windows deployment is either ad-hoc exe's or centrally administered msi's. What's changing with Windows 10?

BuckRogers4• 12 years ago

Win10 and it's (likely) XP/7 popularity level is a dark horse for native apps, and looming blow for the webapp movement. Which I believe has gotten a very long free-pass thanks to the most popular platform not having a cohesive appstore ready (on a popular OS).

Win8 IMO is almost irrelevant, the marketshare isn't there to add a MS Store option for me or many others. The corporations haven't and won't hop on. Everyone is (IMO rightly) focused on iOS/Android/web at the moment. Agreed on MSIs, but I'd add the customizable corporate frontend stores should be more powerful and slick than the current method (same appstore for MS desktop and mobile). It's possible once enterprise moves to the MS Store that MS mobile devices make major inroads. For consumers, I think they'll rejoice at Win10, upgrade to it and by default go to the MS Store for security reasons alone. Not to mention auto-updates, same apps as on MS mobile etc.

I'm not pro-MS, I'm actually anti-all-for-profits and a Mozilla fanboy. I just disagree with Eich on a bytecode for the web, he blew it as far as the web being the prime delivery mechanism for apps is concerned. The webstack sucks, it had to go. Too late now.

I understand my view isn't popular at the moment. Especially among webdevs who are most likely to be reading this HN post. Those people have invested heavily in the webapp dream with their time, skills and careers. Anything to the contrary that it was a great idea is going to get downvoted. Regardless, I think this is an accurate reading of the foreseeable future.

_pmf_• 12 years ago

I feel sorry for those stuck in web development.

Don't. They get so much for free that other developers have to work on hard (flexible data binding, easy portability and trivial deployment).

They insisted on pushing no bytecode for the web. Wanting us to rely on Eich's JS + rest of the webstack monstrosity requiring ugly hacks.

I fully agree here. The whole "JS is not that bad" mindset is firmly ingrained in people's minds, which is a shame.

grey-area• 12 years ago

I work on both apps and the web. My preference and long-term bet is definitely on the web - app stores are mostly a tool for locking customers in; they're superficially attractive to both customers as devs, but in the long run they're also too restrictive for both and too tied to the interests of the app store producers - the Apple app store for example has been used to effectively ban alternative browsers, force Google apps to be second class citizens on the store, stop Amazon from selling ebooks with a buy button in their app, etc, etc - all actions which are in the interests of Apple, but not of customers or developers. That's before you get into the problems of rewriting your stack n times because the different platforms want to force you into using their stack to develop with and constantly work to make creating a cross platform product infeasible, with n increasing each time a new device is announced.

For all the faults of web development, I also prefer it over having to work within the blessed stack chosen for me by the OS vendor, and being forced to migrate every few years as they decide their old stack isn't worth maintaining (secretly I wonder if this constant churn is not also useful to them on some level, it stops app devs every considering other platforms, they're running just to stay still). In contrast web development means you can choose your own tools, you are not limited to using javascript if you don't subscribe to this latest fad that all logic must be in the front-end written in javascript (which never appeared interesting and unstoppable to me at least), and adhere to the original interfaces of the web which was so dumb and simple it was incredibly powerful:

Simple text files (markup, styles) sent over the network to the client, which interprets them in a predictable way to show your UI and data (the predictable part has improved much over the last decade).

I do agree with you though that not having a bytecode for the web is a severe restriction on front-end development, and means that I prefer doing backend web work and using js in a limited way for ajax etc, not trying to use it to generate entire documents/UIs. Personally I find JS is fine for limited tasks, but not for writing apps in without quite a lot of pain. I expect that to be addressed at some point soon though, either by asm.js (not optimal), or something like Nacl. Till then, it's bliss working in whatever tools I want on the backend, even switching out tools if I want to, without the end user even knowing that I'm using a different stack - to them what is important is the app, not what it is written in - that is as it should be, and not something you see on other platforms. That's the attraction of web development for me, and one that native development will never equal.

I disagree that webapps will die - I think they'll just evolve and eventually will become universal applications based on HTML. Javascript will die, but not the web. However that is really a political question about how hard OS vendors will push users towards native apps (where they make money both from sales and more importantly from lock-in).

Will OS vendors continue to dominate computing? I think that's a more interesting question, and one we'll see play out over the next few decades. The web may yet reduce native platforms to a set of badly debugged device drivers.

marknutter8• 12 years ago

Good god, let's hope this dystopian future you speak of doesn't actually come to pass. Can you imagine having to launch a separate native app for Hacker News, Facebook, Github, Amazon, Ebay, etc, all of which go far beyond "document sharing and simple data collection/retrieval"? I think you are grossly overestimating the usability of having so many desktop applications and glossing over the pain in the ass it is to develop multiple versions of said applications just to be cross-platform.

ddebernardy• 12 years ago

Can you imagine having to launch a separate native app for Hacker News, Facebook, Github, Amazon, Ebay, etc

Best I'm aware, a lot of these apps exist already. The step we've yet to reach is "having to launch" instead of merely being able to launch. We probably will for some of them, though.

Speaking for myself, the dystopian present and near-future has me a lot more worried than a hypothetical future with apps: I've lost count of the number of websites which used to work fine on a 1st gen iPad and which now either refuse to work on grounds its browser is too old (e.g. Github), or outright frequently crash its browser owing to out of memory errors due to excessive use of javascript (e.g. most news site).

tomcam• 12 years ago

Oh yeah, another thing happened this year. The hivemind turned its back on the creator of JavaScript because he had a private, principled difference of opinion that was never in the slightest reflected in his public role.

thomasfoster962• 12 years ago

I still have issues with people loading jQuery just to get an element using an id. I'm glad I haven't dived into the world of Angular and other frameworks.

simonrobb• 12 years ago

If you misuse jQuery, it doesn't reflect badly on jQuery as a technology, it reflects upon the developer. jQuery is an outstanding library.

If you stay away from technologies because there are developers out there misusing it, I doubt you'll be left with much but machine code.

thomasfoster962• 12 years ago

Well, yes, that's correct. jQuery is outstanding, but 95% of the time you don't need to use it.

gfodor2• 12 years ago

My team was trying to decide what Javascript libraries to use to build our web tier for our project. After spending a few days trying to get our heads around the ecosystem, we just gave up and went running back to Rails. Couldn't be happier.

agilebyte• 12 years ago

The devil you know kind of thing?

pluma7• 12 years ago

What does Rails have to do with front-end SPA frameworks?

Or are you talking about node?

gfodor2• 12 years ago

Yeah we were looking into node for the server.

CmonDev3• 12 years ago

Good decision. Single-page-apps should be called "hashtag-hack-pages". If you want a real app you can always pick a proper mobile framework later on (e.g. Xamarin or something Ruby-based).

pluma7• 12 years ago

Or you could, y'know, build an isomorphic app that can be used without page refreshes but can also be rendered on the server so you don't need a loading screen for every single route.

pluma7• 12 years ago

The problem with node is that if you switch from something like Rails to node you'll also need to switch to an entirely different architecture.

While there are some Rails-like frameworks for node (e.g. Sails), node simply lends itself to a more service-oriented architecture, with lots of much smaller, much more specialised applications rather than one big monolithic MVC behemoth.

IOW, if you were able to replace your node app with Rails, you probably were trying to build a Rails app in the first place. Otherwise you'd probably have used something more like Sinatra.

RyanZAG• 12 years ago

Not sure why he brings up GWT so much - GWT seems to be very healthy right now. I'd probably choose to use GWT in a new project before I'd choose Angular at this point..

ChicagoDave2• 12 years ago

I've been a developer for over 30 years and there's _always_ churn. You will _always_ have to learn new things. That's just the way it is. Some things are truly better (C#) and some things are not (Flash). It often takes time to weed out the truly bad things, especially if the bad thing is the only thing that solves a noteworthy problem (how to provide high-end interactive animated content through a browser aka Flash). We've managed to move most of the basic concepts of Flash to the browser via HTML5 and that is very clearly a better solution.

The Angular 2 issue is somewhat curious. My biggest question isn't about the new teaser specification. It's what happens to the current version. It's open source, right? I suspect a number of corporate babysitters will provide the support required to make sure 1.x lasts for a decade or more. If you choose to adopt 2.0 for _new_ projects, so be it. Although why on earth the A2 architects chose to break XHTML standards baffles me. An attribute in parens? Seriously?

I personally see the new JS world as a step forward. It's absolutely a molten spew of new and unproven code, but it's also easier to build things than ever before. There are a ton of problems solved with a front-end MVC connecting to a service layer. A TON.

The hard part is that we need better tools all around for JS that we've been spoiled with in C#, C++, Java, and even Assembler.

But one more thing that's hinted at, but I'm suddenly asking myself. What if Anders Hejlsberg (C#/TypeScript) were to publish a monolithic front-end MVC/MVVM framework and its use was built into Visual Studio 2015, which is going to be free at the Pro level? That would throw even more F bombs into the JS world.

In any case, if you're a senior developer or architect and making decisions about technology, you better know what you're doing. You can pick 2% usage code, but you better own it.

rimantas• 12 years ago

The problem is that for me it looks that whaterver is happening in JavaScript world it is not going forward. More like running on the treadmill or just spinning around catching own tail. The note about gazillion MV* frameworks is spot on, and it still goes on, with no end in sight.

bshimmin2• 12 years ago

Addressing just a small point from this: a lot of people working on the web at the moment have absolutely zero interest in using Visual Studio. Like, say, all the people using Macs.

rattray2• 12 years ago

Visual Studio may be coming to OSX soon. MS recently announced .NET for Mac and made VS Community freely available; it's quite likely that they're planning to release VS for OSX/Linux soon too. There's also Omnisharp, which brings C# tooling to Sublime, Vim, Emacs et al.

http://www.hanselman.com/blog/AnnouncingNET2015NETasOpenSour...

pjmlp3• 12 years ago

Like, say, all the people using Macs.

Outside US, it is a very small number.

ZanyProgrammer• 12 years ago

I think your comment is very indicative of the divide between startups and more traditional enterprisey web development.

ChicagoDave2• 12 years ago

I was less commenting on PC vs MAC and more that Visual Studio is not used by web developers who use Sublime and WebStorm and other text editors. I believe you'll see VS move closer to those usage scenarios over time and have less of the stigma of being an MS-only tool. Or at least it _has to_ to survive. I'm a VS guy from the beginning, but I really like WebStorm.

bitwalker• 12 years ago

I'd say there is plenty of interest in a cross-platform Visual Studio. It's hands down the best IDE I've ever used, and if it was available on OSX you can bet I'd use it. That said, since VS is not in fact cross-platform, some VS-specific feature obviously doesn't apply to those developers who don't run Windows.

Personally, I do C# development in a Windows VM, everything else in OSX. With the new vNext stuff, the only thing still binding me to Windows for anything is the lack of Visual Studio (and WPF). I wouldn't be surprised to see an effort made to bring it to a larger audience now that .NET is going cross-platform.

CmonDev3• 12 years ago

"...some things are not (Flash) ... We've managed to move most of the basic concepts of Flash to the browser via HTML5 and that is very clearly a better solution..."

It was so bad, that last couple of years were spent trying to reproduce it's basic features? I would bet most of web games released today are still Flash. When you leave people with a single choice (this practice is called "open web") then of course it is going to be a "solution".

"...you better know what you're doing..."

Easy solution: move page generation to server, like Twitter did.

laurent123456• 12 years ago

Exactly, the JS demos we're amazed with today were done 10 years ago in Flash. Flash as a technology was pretty good, but it was just misused.

marknutter8• 12 years ago

Although why on earth the A2 architects chose to break XHTML standards baffles me. An attribute in parens? Seriously?

The new syntax, while odd looking, is actually completely valid HTML.

ssmoot• 12 years ago

I suspect not valid XML though. Which is what the comment was about.

Not that I think that's all that important if you're not using XSLT, but just the same, your comment is talking past it a bit.

Bahamut4• 12 years ago

More of an aside, but the Angular 2 html syntax is different - what they revealed at ng-europe is not the final syntax they settled on. In fact, shortly after, they had to switch it because it turned out the element.setAttribute function didn't like it.

Mc_Big_G• 12 years ago

Ember had a lot of growing pains, but it's starting to come out of it's cocoon and spread it's wings. When you combine it with the massive productivity boost of ember-cli, tooling that does all the tedious and hard shit that no one wants to deal with, it's a big win.

I recently made a simple app and decided to just write it in jquery and constantly found myself missing doing things "The Ember Way"™ Building an "ambitious" application in jquery alone would be complete madness and half-hearted frameworks don't really give you much benefit for all the wrestling you have to do.

I really like that the Ember team strives to find the right way and deprecates parts of the api that they find people using in bad ways. I've also seen a lot a pragmatism around preventing bloat like removing string inflections etc...

The best advice I have if you really want to try Ember is to read the guides, completely, word for word. Then try to write a simple app, using the guides/recipes/API for reference and then read the guides again, completely. Then do all that again. It won't take as long as you think and you'll be far ahead of where you would be reading some introductory blog posts.

Admittedly, I have been frustrated at points, but that's par for the course with any js framework at the moment and if I had chosen Angular 1.x for any of my previous clients, I would be VERY embarrassed right now.

tragic2• 12 years ago

I like ember well enough, but sweet jesus it's huge. We have a page weight budget; 350k of ember plus 100k of jquery plus 50k of handlebars leaves about -150k for all the ad/analytics code the rest of the business needs. It's just not going to happen.

That's a serious advantage for angular - it's pretty small for what you get out of the box, and there are no external dependencies.

I saw in the Ember 2 RFC that they hope to slim down a little, which would be good (especially now that Angular is going mad), but for those of us who don't want to send a great hulking wodge of stuff to every P.O.S. phone that so much as glances at our apps, it's going to have to get a lot smaller.

michaelmcmillan• 12 years ago

Great post! I agree with your argument regarding libraries over frameworks, but I think the real problem is how we couple our software to third-party libraries. Frameworks tie you down more than a library, like you said. But if you're not careful a library can do just the same. Which is why I believe developers have to be more clever when architecting software.

Reading your post reminded me of Robert C. Martin (Uncle Bob) opinions on how coupling your code with anything that can screw you over obviously is a bad idea.

"Apparently the notion that it’s a good idea to hide the framework, UI, or database from the application code is not universally accepted."

"What happened to us? How did we forget these rules? When did the old rules of coupling and cohesion evaporate from our awareness? Are we really so naive as to think that the best way to write a complex system is to throw a bunch of components into a bag and shake it until it works?"

http://blog.8thlight.com/uncle-bob/2011/11/22/Clean-Architec...

je423• 12 years ago

Yep !!!

cturhan• 12 years ago

Great article and I agree on most of the parts.

But, don't put tldr; on bottom of the article.

CmonDev3• 12 years ago

This is why nobody mainstream wants to work with web front-end. Would you be a JavaScript MVC expert or a Java server-side expert? Think about the rate of knowledge aging.

hardwaresofton• 12 years ago

Iteration produces churn (I don't think anyone would argue for not arriving at the best solution in an iterative manner in this day and age), and almost everything on the front end is iterating.

I say keep calm and watch it churn.

When it stops churning, whatever comes out is going to be worth it

cromwellian• 12 years ago

Not sure why he is including GWT. Google continues to fund GWT. We just hired another full time engineer on the project. We just released GWT 2.7 which has a massive number of new changes, including an all new incremental compiler that reduces development recompiles from minutes to seconds.

We have a lot more external contributor interested that in the past now, have accepted many more patches, and we just landed Java8 lambda method support, with even more cool stuff to be shown at GWTcreate.com conference in January.

In other words, Google has not removed support from the project, which has continuously existed since 2006. Not sure how much more dedication you want in funding for an open source tool/library.

smanuel• 12 years ago

Yeah, and putting GWT and Silverlight in one basket seems highly unfair. What crisis of GWT? I haven't heard anything about it.

brey• 12 years ago

so instead of being a tool which Google has already removed support for, it's in the bucket of tools which - at least to me - should be treated as liable to be cut at any time and don't rely on it.

sorry, Google lost any credibility in this area over the Reader fiasco - Google has no interest in maintaining a project for the good of a community, if it doesn't align with corporate strategy. 8 years history means nothing.

coriny• 12 years ago

"... it's in the bucket of tools which - at least to me - should be treated as liable to be cut at any time and don't rely on it."

Unless you've paid for a guaranteed period of support, bug fixes and extensions of functionality, this how you should treat all code libraries surely? All libs come as is, and statements of future actions are always expressions of intent, not facts. If your company is utterly dependent on a single free 3rd party library then you should be prepared to take over ownership of it - or accept that your company's survival is at the whim of another. Personally, I would not be swayed by any brand name here - but who would you trust (enough to bet your company on) to provide long term support for a free OSS library?

Personally, I would consider the closing down of a very niche, free, consumer product based on a seemingly dying web technology as a very poor guide towards how Google will treat GWT, which is actually used by them for website development.

louischatriot• 12 years ago

The last point about small libraries versus monolithic framworks really resonnates with me. I always have a hard time understanding why my team should commit to one specific way of doing almost everything, instead of picking the best tool for every job. In my experience, framework code is of a very varying quality, some is good, some is not, some doesn't suit what I want to do.

vjeux• 12 years ago

The way we tried to open source our front-end stack at Facebook is to release a collection of standalone libraries. This strategy worked very well to integrate with existing codebases but we're missing a very large audience: people starting new projects. It's not trivial at all to glue all those projects together. So while it's tempting to reject "framework"-type projects, that's actually what a lot of people want and our most common request.

- React: http://facebook.github.io/react/

- Flux: http://facebook.github.io/flux/

- Jest: http://facebook.github.io/jest/

- Immutable-js: http://facebook.github.io/immutable-js/

- Flow: http://flowtype.org/

- JSX: http://facebook.github.io/jsx/

illumen• 12 years ago

Framework groups are larger as a group than the many small groups that use collections of libraries. However if you add up all the smaller groups using smaller collections, maybe they are just as big or larger?

MrBuddyCasino• 12 years ago

This looks like a good opportunity to point people at Mercury: https://github.com/Raynos/mercury

It is similar to Mithril, but with a strong focus on modularity. To quote the website: "mercury is a small glue layer that composes a set of modules that solves a subset of the frontend problem."

You can basically swap out things that you don't like, use it with Backbone or JSX etc. Its weak point currently is documentation, which is of course a biggie.

vkjv2• 12 years ago

I don't think a "framework" is necessary here, though. An example boilerplate project that glues all (most?) of the libraries together is all that is needed.

wyclif• 12 years ago

The State of JavaScript in 2015, Vine edition:

https://twitter.com/jennschiffer/status/539274049273479170

sauere• 12 years ago

I got to agree with the Reddit posts quoted in the blog post.

But it's not just JavaScript, it's Frontend and WebDev in general. The whole landscape is too big and moving too fast for anyone to move along and most importantly: it is very, very frustrating. Go to angel.co and just look at three or four job openings and you will end up with 50 different Frameworks, Libs and Stacks. Half of them might be dead or deprecated in 12 months. It is insane.

davidgerard3• 12 years ago

I'm a sysadmin supporting this shit for bespoke web applications. A new piece of semi-supported crap every six months and the business expects it to be supportable for two or three years. (We're getting better about demanding they fund a damn sprint for any nontrivial work.)

Our devs are a very smart and capable bunch, but are slowly learning the Support Hangover of being the knowledgeable one on a project because you made a foolish and enthusiastic choice when the project was launched ... it's how you learn the "-ops" bit of devops.

Some year webdev will grow out of the CADT model, but it won't be this year.

jimmytidey• 12 years ago

This discussion is exactly why I'm drawn to Meteor. As someone who turns out prototypes and doesn't do full time web development, the overhead of researching all these options every time I try to do something is too much. The cost is that I might not always be using exactly the right thing, and that I'm stuck with Meteor's quirks. The pay off is that it always just waiting to go.

As an aside, I think it's notable what a barrier to entry all this is. If you want to try your hand at web app development the thicket of libraries is not a welcoming prospect...

evo_9• 12 years ago

I have to agree, I've played with all the 'big' JS frameworks during the past 2 years and only Meteor has 'stuck' for me. Part of it is that it's just so fast and easy to crank out something usable with minimal effort; I think this is largely because Meteor is unencumbered by any MVC requirements. It would take a lot for me to consider changing to something else at this point, Meteor is just so fast, easy and most importantly fun to develop apps in.

prottmann• 12 years ago

To be fair: many things were developed in the last 4 years since google pushed V8.

Thats why so many things changed too.

And the other thing is: why are all those things so successfully? People had enough from old fat frameworks, that where developed 10 years ago with a language from 15 or 20 years ago.

This old languages and frameworks did not fit to Web-Development, Apps, whatever... all the things that boomed since 2007.

bwindels• 12 years ago

Funny how a lot of the comments here, on an article about framework fatigue, talk about frameworks that don't have problem x :)

My preferred way of working in a lot of projects is to work with the DOM directly but keep the code that is DOM-aware as minimal as possible, and call my domain layer right from the event handler after extracting the needed info (id, ...) from the event and target. IMHO, data-binding is not that useful in most projects.

tk42• 12 years ago

The state of JavaScript in 2015: it still sucks. I just wish the webbrowser creators would implement a way of other languages to be executed as a replacement of JavaScript. Not gonna happen, I know...

pestaa2• 12 years ago

In my mind it's in the same spot as PHP: the language can hardly be worse, but so much quality code is written in both, you're beginning to accept them.

Lucky if you can work with a disciplined team...

juliangregorian2• 12 years ago

JavaScript, while it was rushed and had questionable design goals, at least was somewhat designed. You can't say that about PHP.

Also not sure I can get on board with "lots of quality code in PHP", some sure, but seems that anyone who knows PHP and another language prefers to write in another language.

montecruiseto• 12 years ago

if we're worried about this miniature explosion...just consider the supernova that's coming when the internet of things hits the scene. Then, we will all look back on how peaceful things were in 2014.

Illniyar3• 12 years ago

I'm not sure if this churn is unique to the javascript and front-end world.

When I used to work in Java a few years back, there was a new "favorite" framework every few months:

* build: ant, then maven and just when maven started getting massive traction, gradle.

* web frameworks: JSP, JSF, Spring MVC, Wicket, Tapestry, GWT, struts, dropwizard (and compiled java - Grails, Play etc...).

Even "standards" made by the "governing body" conflicted with each other - JDO, JPO and ESB (the persistence part, though I'm not sure if there was a JSR for that) for example.

A new web shop even had a hard time choosing the Language of the month: Groovy, Scala, Clojure.

If you go broader then the Java world, then the flavour of the week platform was even harder to pinpoint- ASP.net ,PHP,wordpress,drupal,rails, node etc...

Not to mention databases - from everything must be relational in one Monolith DBS (oracle mostly) to sharded mysql with memcache layer, to only noSQL (usually mongodb),then to polyglot persistence (I.E. use what fits) and now into the brave world of natively distributed sql (I.E. newSql).

I don't think it's the front-end that is high churn, I think web development as a whole has changed so much in the last few years that the technologies involved has changed drastically.

At least in front-end development you one language, and the knowledge of some universal standards (you aren't going to need to relearn HTML and css).

Also there is still jQuery- which regardless of how many things are built against it, it exists in practically every site.

narag• 12 years ago

I wouldn't say it's the general case (and of course not about JS, that I know very little of) but sometimes the proliferation of tools in a field is just a simpton that either none of the tools have been really good (first rush, then technical debt) or that there's some intrinsic deficiency in how the field works.

gred2• 12 years ago

build: ant, then maven and just when maven started getting massive traction, gradle

I'm not sure that I would call 3 big build systems over the course of 20 years "churn" :-)

web frameworks: JSP, JSF, Spring MVC, Wicket, Tapestry, GWT, struts, dropwizard (and compiled java - Grails, Play etc...)

The height of the churn corresponded to people trying to handle MVC on the server side, and seems to have subsided somewhat as people have simplified the server side (RESTful APIs) and moved the MVC to the client side.

I wonder if this churn is somehow intrinsic to the type of problem being solved (user interaction), rather than to the technology / language / community.

Illniyar3• 12 years ago

in regards to build, I was talking more about when these systems became popular/hyped/adopted rather then when they were released.

Maven didn't became really adopted until 2.0 came out, and, to me at least, Gradle gained traction extremely fast after Maven was adopted (along with sbt for scala and others). I think Maven laid out the foundation for the adoption of gradle.

But yes, it's a lot farther apart then Grunt vs Gulp. I was more trying to show that build systems change even for very stable languages/ecoSystems (relatively speaking).

In regards to problem solved - it's an interesting thought, I haven't done a lot of ui outside of web, I wonder if other people can shed some light on churn regarding ui frameworks on desktop (or even flash/silverlight/unity etc...)

vorg2• 12 years ago

A new web shop even had a hard time choosing the Language of the month: Groovy, Scala, Clojure

Each language had a different purpose:

* Groovy provided a Ruby-like MOP for use with Grails

* Scala provided lazy-eval functional programming and a higher-order type system

* Clojure provided concurrency constructs and Lisp macros

scribu• 12 years ago

Each language had a different purpose

No, all languages had the same purpose: being the best general-purpose programming language. What differed was their approach.

jfmercer• 12 years ago

An altogether excellent article. You have impressed clearly and eloquently the exact same sentiments as I have about instability of the Javascript landscape.

ddw• 12 years ago

Does it really take that long to learn Angular? Will it really take long to upgrade to 2.0 and will you have to do it immediately?

The web has always changed quickly because that is the only way it can survive. If you think you can write an app and let it sit there for years you're silly.

Technology: there is no end game.

al2o3cr• 12 years ago

"Developers will move, I believe, from monolithic frameworks like Angular.js and Ember to a ‘pick n mix’ of small, dedicated libraries to mitigate the risk of churn"

Well, that would reduce the framework churn rate for an individual developer to exactly the rate that said developer gets new projects. Too bad about the NEXT dev on the project, tho...

vkjv2• 12 years ago

I completely agree with the modular, single purpose library approach, but, for large teams, it adds a lot of hidden overhead: library curation.

It's so easy to just, `npm install` or `bower install` a new library, sometimes you don't even think about it. But, this causes a huge bloat and duplicated functionality that both produce huge build artifacts and increase the learning curve.

You need to make sure you have at least one person dedicated to saying, "I know B does X better, but, we are already using A and it does X good enough."

je423• 12 years ago

In my experience you will get into this problem also in any other language. I had this particular problem with C#/Unity, C++/Windows and Python/Linux.

tempVariable• 12 years ago

This and the related reddit post put some more libraries on my radar and the cycle continues. That is probably the most useful thing for me out of this debate.

I have not dipped my toes into a production app with ember or angular because of the same list of concerns put forward by folks here and on the other-webs.

kartikkumar3• 12 years ago

As a relative beginner in front-end dev, I have to say, the whole JS world has me completely flummoxed. I really don't know which way is up and given that my time is at a premium at the moment, I want to learn something that is going to give me a firm foundation in the long-term. It seems with all these frameworks that it's like betting on a horse blindly, at least to someone who only has a cursory view of the JS landscape. I've played around a bit with Express.js and with jQuery, but not enough to know which way is up.

I've been wondering if all this change means that the real way for me to start is diving straight into vanilla JS. I have a firm grasp of Fortran, C++ and experience with MATLAB, SciPy, and Julia (recent) for scientific computing. Coming from the engineering world though, I have no sense how the front-end dev community is shaping up, and that makes me nervous about deciding where to spend my time learning. There are some fun projects I have in mind to bring some of the engineering stuff I've done to the web (e.g. an asteroid redirect mission calculator), but I'm worried about spending time learning a framework that'll just disappear by the time I even really get going.

Does all of this change mean that, in the long-run, I'm best working my way through vanilla JS and at a later stage making using of frameworks or libraries to make the more mundane programming tasks a synch? Or should I actually be starting off by learning a framework? Input highly appreciated!

dccoolgai2• 12 years ago

"I've been wondering if all this change means that the real way for me to start is diving straight into vanilla JS."

Yes. If you learn JS really well, you can adapt to the framework-du-jour quickly. Learn the DOM , Learn the Web Standards: Two years from now, these frameworks may or may not matter but the things that are happening in Web Standards like ServiceWorker, Components, RTC, etc. definitely will. If you are searching for the branch to cling to in the storm, it is this: Web Standards (which includes "Vanilla" JS). Start here and work your way outwards: http://youmightnotneedjquery.com/

kartikkumar3• 12 years ago

Thanks, I guess that's along my line of thought at the moment.

My interpretation from my limited exposure is that RoR is a big step up from "vanilla Ruby" and that the community in that case is consolidated enough that it's pretty much a no-brainer to just start with RoR as a beginner. In the case of JS it seems like a movement towards consolidation in that sense is still a long way off, meaning that "vanilla JS" knowledge carries more value than it might do 5 years from now. I've also wondered if all the energy that's being pumped into frameworks and libraries wouldn't yield more if it was targeted towards completely replacing JS with something that's more akin to modern (front-end) dev from the ground up. Maybe that's a silly thought, given legacy and the close relationship with browser development, but as an outsider it seems like a lot of energy is spent on "warring" that could perhaps be focussed more productively in a different direction altogether.

Any other JS resources you would recommend to start from the bottom outwards/upwards?

GlennS• 12 years ago

I'd say this is a pretty sensible approach. Ultimately if you want to understand JavaScript properly you're going to have to do it barebones for a bit first, so why not start there?

The only caveat is that JavaScript is still really lacking in a few areas, and you'll probably find yourself wanting some 3rd party parts to help you with them:

1. No modules or dependency management. I believe these are coming in ECMAScript 6, but the browser support isn't there yet. You can invent your own module system by hand and then write out all the script tags but it gets really annoying once you get to say 10 files. I'm using npm (the NodeJS package manager) with Browserify and that seems ok, although there are a few other solutions out there too.

2. I use Lodash to give me some extra operations on functions and collections that aren't in by standard, but I find useful. I'd actually prefer to have a library which provided some good standard data structures instead, but I haven't found the right one yet.

3. DOM manipulation. The standard DOM interface is a bit scabby. I'd recommend D3.js as a pretty nice DOM manipulation library that you can dip into or out of as you like. It's a fairly large learning effort, but I'd say worth it.

akrymski3• 12 years ago

I'd definitely recommend learning vanilla js over a framework. From there you should pick up and read the source of some useful libs like Backbone, or (shameless plug) my own MVC framework: https://github.com/techlayer/espresso.js

Only once you know how these frameworks operate will you be able to make an informed decision as to whether you need something as complex as Angular or React under the hood.

I'd also suggest learning Node.js - as NPM packages and the whole dependency management system of node is really great. Browserify lets you package such apps for the browser, and this is definitely the future of javascript imo.

kangax• 12 years ago

This is nothing new.

Back when I was starting, it was all about "JS libraries"; when Prototype.js gained the most traction at one point, beating in popularity older Dojo. Still, there were new libs popping up again and again — Mootools, MochiKit, YUI, jQuery. jQuery "won" by introducing a simple and powerful concept of operating on collections via an intuitive API.

Then there were modules — AMD, Require.js, Common.js, etc. New "standards" and libraries competed and everyone claimed to be the best.

Then Backbone and others brought a new perspective on widgets via sort-of-MVC, and a whole slew of libs emerged — JavascriptMVC, Knockout.js, SproutCore -> Ember, Angular, etc. All similar concepts rearranged in a different flavor, shifting abstraction into one layer or another, with different levels of convention.

In the end, every wave brings something good. Right now we have React & Ractive bringing concept of virtual DOM. It seems long overdue and sorely needed.

Staying at the edge must be exhausting. Staying in the middle of a bell curve is best bang for your buck.

ebiester• 12 years ago

I posted it elsewhere, but I remember it said from my days watching the proliferation of java frameworks: If you aren't using a framework, you're building a framework.

When I spent some time in the node.js world, I felt the same thing: there were a few attempts at frameworks, but most everybody was writing their own glue framework between microlibraries. I am convinced that it is only fun the first few times you have to do it. :) It reminds me a little of the days before server side frameworks, where people were reinventing the wheel (poorly) every project.

Further, I don't think it's necessary to run and learn every single framework that comes out. If something is an order of magnitude better, it will take over the market. (Ember, Angular, and React are all an order of magnitude better than backbone.) There will come something that is an order of magnitude better than these eventually. Until then, just get stuff done.

And frankly, there's no shame in continuing to render on the server until that next generation leap comes.

bahmutov• 12 years ago

Are we really now complaining that the fast pace of new tools is a problem? Not to put everything in black and white, but would the author prefer new releases every 5 years? Just apply same principles to picking new tools like you would when buying a car: do you really need it? Can you afford it? Does the new model have something the old one does not?

strickjb9• 12 years ago

I disagree with this post. Churn is the byproduct of evolution. Libraries will slowly die and fade away but we learn with each misstep. Sure, there is a lot of redundancy in the work but each different library/framework/plugin/shim is a mutation. The good ones pass down traits to future libraries.

Survival of the fittest. Churn is just necessary. The front end world is a huge ecosystem which is constantly evolving.

funkiee• 12 years ago

I think the Front-End community just happens to collaborate a lot more than other communities and so the ideas get shared at a faster pace. Yes, it leads to framework churn, but it's mostly because we're learning from each other's ideas. If the other side of the coin is stagnation where people learn the dogma of a framework and not the reason behind it, I'm all for framework churn.

Find something that works for your team and stick with it. No one is making you use the latest framework or library out there.

calebm• 12 years ago

I've often found Libraries > Frameworks.

cayblood• 12 years ago

I'm surprised there was no mention of Google Polymer in this article (and very little in the comments). As I understand it, one of the big reasons why Angular wasn't backwards compatible is that they wanted to remove directives and opt for a more web-components-compatible approach. Having worked with Polymer during the past few months, I'm very impressed with its modularity and the simplicity one can achieve because of how each component's features are well-encapsulated.

WhyYes• 12 years ago

Stop doing your coding in a framework. I know coding something big in JS is not ideal and thats why Google made Dart.

Lamba• 12 years ago

I stick to using well established libraries/frameworks, eg jQuery. Unless you have a large and complicated model, an MV* framework can be overkill and add unecessary complexity in addition to possibly tying you down to something that becomes a laughing stock in six months. The new and well received SPA book by Mike Mikowski and Josh Powell takes a similar stance.

akrymski3• 12 years ago

Small libraries win out every time, as soon as there is a decent package management system. Just look at what happened with Node and NPM - npm really rocks, and the whole node ecosystem is choke full of great and small libraries that fit together nicely.

I write node on backend and frontend, and package the frontend using browserify into a single index.html file that contains everything the app needs, so it's one HTTP request to fetch the app. That's the new binary format of the web, and all the dependency management is done for you. It's bliss. For the frontend I used vanilla JS to write a small Backbone-style library to meet my needs: https://github.com/techlayer/espresso.js because even Backbone seemed too monolithic to me (requires jQuery/Zepto).

I've tried React and Angular, but I simply don't understand what they offer over Vanilla JS. What developers really need is to agree on a package standard (NPM!) so that small libs can flourish. There are tonnes of great libs on github but unless they are in npm, it's just a hassle, let's face it. Frontend devs need to adopt the same approach of publishing everything to npm as Node devs have been doing for years. You don't see monolithic frameworks in Node world because the package management system just works. I don't care about standards, but if everyone embraced something the world would be a much happier place.

jnem• 12 years ago

I've tried React and Angular, but I simply don't understand what they offer over Vanilla JS.

Agreed, especially considering many devs choose Angular, Ember, etc. to perform easy two-way data binding. However, two-way data binding can be achieved fairly easily in vanilla JS. I recall Javascript Weekly sharing a great article about how simple it is to do: http://www.sellarafaeli.com/blog/native_javascript_data_bind...

at-fates-hands• 12 years ago

As someone who was drinking the AngularJS kool-aid, the merry-go-round joyride ended abruptly for me and my startup after the Angular team announced a lot of the updates they were planning, including the obsolescence of previous Angular versions at the ng conference in October.

My partner and I had about 8 months of dev time into a directory app we were building on the MEAN stack. It just so happens AngularJS was a big part of that architecture.

After some long conversations over beers and some teeth gnashing, one thing became clear. If the Angular team just decided to make these huge changes now, what keeps them from doing it again in the near future? If they have no plans now of making newer versions backwards compatible, does this means every new version will be this way? All it did was create huge questions of trust and reliability with using a framework which could dead end your project somewhere in the distant future. This meant continually looking over your shoulder, which is not good for any business.

Our final decision was to scrap what we were doing with Angular and now are looking at several options which include:

1 - going with a traditional .Net stack / MVC

2 - going with Django or other Python framework

3 - moving to another JS framework like Ember

Either way, We're moving away from Angular. Call me gun shy, call me spooked by the latest change in direction, but I have a bad feeling about how this is going to turn out in the next 18-24 months.

The State of JavaScript in 2015

Related Stories