The State of JavaScript – Survey results | Hacker News Reader

The State of JavaScript – Survey results

stateofjs.com

546 pointsekianjo346 comments

It's really unfortunate that so many people aren't interested in learning Ember. I just started an internal IT tool in Rails and Ember and I'm really enjoying the simplicity of it. I want something that is easy to understand, easy to setup, and won't change for a while. I became more interested in Ember when I read something online about how they are focusing on stability in the long term instead of a bunch of features. There are also a couple of tools for "just get it hooked up to rails, stupid" that helped me move quickly. As a simple, simple guy - I really prize the "hey stupid I set it up for you" command line tools that give me a starting point. Then I can figure things out as I go along by making small, simple, controlled changes.

This is in strong contrast to something like Elm. I have played around with Elm a bit but it's hard to wrap my head around some of the concepts and setting it up with the back-end frameworks that I'm familiar with has been meh. It's also changing rapidly so trying to figure out the concepts by looking at real world examples doesn't help because of a changing language specification. Going from changing the state of a counter to building out a larger application has been somewhat difficult for me and I feel overwhelmed every time I try to start a small project with it. I'm chipping away at that with an Elixir/Elm project, however. But the overall point is that progress is slow because it's such a different way of doing things and I get this gut feeling that I'm drifting away from KISS principles.

I'm not a front end developer at all. I'm a systems engineer who dabbles in web application development because it's fun and allows me to build some nice internal tooling for other teams. However, because I don't have that deep web experience I tend to gravitate towards the "old but still good" concepts and frameworks. I'm much more likely to reach for jQuery and server side rendered templates than I am for React or whatever amalgamation of libraries that require an overcomplicated build tool.

I think Ember is great, and agree more people should use it, but it is NOT simple. It is easy, but it is extremely complicated.

Ember follows in the Rails tradition of "convention over configuration". This means common activities can be done with a simple command, creating a file, or adding a flag in the right place.

This comes at a price: everything that happens in your Ember app is deeply tangled in Ember internals which are very complex.

This means adding behavior leads one of two places: It Just Works, or you have no idea what is happening or what to even ask.

When you are an Ember beginner this second state can last for days or weeks of frustration. As you learn about Ember internals, it happens less often and you move through it quicker, but expect this to take months or years.

The Ember team has taken steps to mitigate this difficulty: adding great error messages, and adding great documentation. But it a fundamental downside to the architecture they have chosen. And it's fundamentally at odds with what I would consider the Node Ethos, which is small packages that do one thing cleanly.

I would recommend Ember to professional developers who have the time to really learn about its internals and can afford to lose a week here and there to tricky debugging challenges.

I would not recommend it to developers working on small projects with tight deadlines.

>"everything that happens in your Ember app is deeply tangled in Ember internals which are very complex."

and

>"it's fundamentally at odds with what I would consider the Node Ethos, which is small packages that do one thing cleanly."

You could substitute "Ember" with "Microsoft Windows" and "Node" with "UNIX" and be just as correct.

I wonder how frequently this design/philosophy decision comes up.

I hear very distinct echos of Rich Hickey's talk, Simple Made Easy.

In that talk, "easy" is defined as being nearby, familiar, or otherwise "at hand" to the person who is involved.

This is different than "simple", which is presented as an orthogonal concept meaning roughly "one operation" not tangled or interleaved with neighboring concepts.

This is a clear and useful way to think about simplicity in software (1). I think it's fair to say that the "do one thing well" aspect of the UNIX philosophy is a pretty good match to Hickeysian (?) simplicity. I haven't worked with Ember, but I think it's safe to say that Rails makes things "easy" that actually introduce significant interleaving to your app. The two examples I can think of are both about ActiveRecord: extending AR gives your classes an enormous protocol, and AR hooks deeply braid persistence to something whatever else it is that you're doing.

1) If you wanted to talk about simplicity as it relates to, say, product design you might be way off. When we talk about a product being simple, what we usually mean is that it integrates (folds together) many complex dimensions such as ergonomics, manufacturing, aesthetics, cultural signs, etc. into a single solution.

> When we talk about a product being simple, what we usually mean is that it integrates (folds together) many complex dimensions such as ergonomics, manufacturing, aesthetics, cultural signs, etc. into a single solution.

I would argue that in order for that to happen, the design and internals of the product need to follow principles of simplicity and separation of concerns. You can't just wrap a pretty layer around a snarl of insanity and get a usable product.

For example, a common design mistake is to use several visual indicators for one piece of information: this warning text is bold, a different color, and placed inside a box. Once you've done that, you have used up three visual "slots" that can't be used as effectively for other information.

Great design like you describe requires thinking about single uses for single mechanics. It requires thinking about how things fit together while remaining functionally distinct, rather than just adding more and more complexity to solve problems that come up.

If I understand the saying correctly, this idea might be contained in the aphorism, "encapsulation breaks inheritance."

as a service!

Ah, maybe you're right. I think I'm used to convention over configuration setups so it feels a lot more comfortable to me. I think that maybe that's why its so popular with Rails developers because they're used to operating within the bounds of the prescribed architecture and then having to deal with edge cases.

I think, for me, I feel comfortable debugging as long as I understand the idea that is trying to be communicated. I think "weeks of frustration" is a bit of hyperbole but that's just my opinion. I can see days lost... but I think that's true of any technology stack that you're trying to acclimate to.

I also don't know about the last sentence about not recommending it to developers working on small projects. I don't have tight deadline but I find that it's working for my small project. As long as I'm not doing anything too far outside of CRUD operations translating into a view then I'm fine.

I don't think I would power a company with Ember. Though, granted, I don't have the experience to really make a call like that... but I would relay my personal experiences to a single developer looking for advice and suggest it for them if they're used to Rails or Django or some other massive convention over configuration back end framework.

"Ah, maybe you're right. I think I'm used to configuration over convention "

I think you meant the reverse.

You are correct! Edited. Thank you for pointing that out.

I love the promise of Ember too. But if you look at the stats, along with Angular & Backbone it has pretty terrible satisfaction ratings. And in my personal experience, it also has some of the worst word of mouth of any JS frameworks. Which I believe is the reason why so many people haven't tried it yet.

Most former Ember devs I know have moved onto React. When I mention Ember to them, I often get the response "you're STILL using ember?"

I could spend an hour explaining on all the issues with Ember's execution (it's been blogged about before, many times). I have no problems with "The Framework Approach", but when the happy path tends to always end up in the same bad destination, the community has to stop and think if they're on the right ship.

Source: I'm a full-time EmberJS dev for past 3yrs, dabbler for a couple years before that. If you'd like to discuss exactly what issues I run into daily with Ember, just contact me (my email is on my profile).

Awh, I'm pretty sad to hear that from an experienced Ember dev. I've heard some pretty bad things about Angular and I've seen some horrible Angular codebases. It's entirely possible that I'm looking at Ember through the eyes of a Rails developer who wants a better front end experience.

There is a good chance that I'll run into Ember's warts later on but just how easy it was to get started made me so happy. If I do come to the conclusion that it's something to hate, then I hope something comes along to replace it. I've heard great things about Vue.

I couldn't find anything well written and long about Ember from the ten minutes that I googled. Everything mostly seemed to be hot debates in comment sections. I think that as far as full time JavaScript developers, it's a good idea to aim for a React dominant ecosystem. But as a filthy and uncouth back end programmer, I really just want something easy to hook up. I'm not building something super complex and Ember, while it is probably terrible in sections, solves what I need it to do.

Paging data results to increase performance is what I'm working on right now. I want to feed it into a table.

Getting jQuery stuff like datatables working can be annoying and has led me to look at ember addons.

Rails dev who likes Ember, here. Well, maybe "likes" is too strong a word. Prefers, maybe?

Basically, you're right on the money. I like Ember CLI because it's the closest thing to replicating the ease of Rails development in the Javascript world that I've seen thus far. I'm keeping a keen eye on Angular CLI, but it's not ready for primetime yet.

To each their own. I tried learning Ember many times (due to my admiration/respect for Yehuda Katz), but it was always too confusing for me. Vue.js is what I use now, because it's the only front-end framework I was ever able to learn and use in real-world projects.

Yeah, this was just my personal story with it. I had a very specific goal for my first steps of development:

* Collect instance metadata from EC2 and store it in postgres.

* Collect Chef node data from a Chef API endpoint and store it in postgres.

* Return those collections to Ember to graph/put in a table/whatever.

I followed this guide for Rails 5 and Ember: https://emberigniter.com/modern-bridge-ember-and-rails-5-wit...

I had to pick and choose what it was showing since I wasn't building a book app.

It took some finagling to get everything working. One thing that confused me is that Ember resources get their own route and that wasn't explicitly stated (or maybe it was and I missed the text). So I kept trying to get `/instances` to render a table of instances but I would only get json back. I was super tired and up late at night but it didn't click that that route was bound to my resource and what was used to serve data. Whoopsy daisies.

Virtually every JS tool/lib/framework sells itself as "simplifying" something, and they usually do. It's the overhead of constantly simplifying that's murdering our productivity.

I think it depends on how you quantify "simple." If you refer to simplicity as a small framework or library with very little moving parts, e.g react or sinatra, then that's one way to arrive at a definition. However, complexity in a designed problem arises when you need to take a large variety of 'simple' components and mesh them together to solve a problem.

In this context, I'm defining simplicity as low barrier to entry and/or easy to understand ideas. I think of myself as a fairly average developer; that I'm not wholly intelligent or skilled. I want a framework that bosses me around and tells me what to do.

Accomplishing simple tasks like mapping JSON returned from Rails to Ember routes and rendering that data into a table was very easy for me to understand and do. The simplicity I'm talking about was the setup, generation, and mechanics of the process. Ember, as another commenter pointed out, is not simple internally. It is glued together using evil magicks as far as I'm concerned. But I'm happy about that because when something does break, it means that I'm doing something that is going against convention or that something is truly broken.

As far as the former, then I need to learn the convention. For the latter, then I need to post questions in forums, hit up IRC, etc. But the positive aspect about the second process is that my project is already fully set up and I'm comfortable with my framework enough that I don't feel completely out of water.

If you are building simple app then it's really easy with Ember but you need to remember that Ember is very opinionated and if you need something that is not exactly standard or creators didn't predicted that someone would use something in certain way then you have problem and you spend time fighting with framework. I've been there, lot of time wasted fighting with Ember in corner cases but if you get this out of the equation Ember is really good and you can be really productive using it.

Yeah, I do like the convention over configuration approach. Sails is somewhat similar. Not fighting against "the Ember way" is valid advice.

However, I see this advice everywhere. When I'm googling "how do I do this in Ember" I usually get a good set of practices.

What's interesting, is there is another thread on HN about a WalmartLabs platform release that bundles React and a bunch of other boilerplate libraries a la Facebook's "create react app" and it looks really cool.

We have a pretty large Ember app that consumes a variety of data from many sources (clojure services and middleware). I find I rarely have to "fight" the framework, but often have provide overrides through the various lifecycle hooks. Usually these patterns are well established and documented, but it does mean learning a pretty large API.

I worked on an Ember project once, the first JS framework I ever used. It really frustrated me that I had it had to use Babel to convert the ES6 into ES5. For some reason, on my laptop, that took about 10 seconds, so every time I wanted to check if some new code worked as expected, there was this long delay. There were a lot of other issues I had with it too.

I love working with straight Javascript (ES5), jQuery and template engines like handlebars. I can design things in a way that works for the project and can quickly just refresh the browser to check my changes.

There really is something to be said about simplicity. I love getting Flask/Sinatra/Spark/microframeworkhere and then just rendering a server side template that gets manipulated client side by jQuery. It's hard to move away from that sometimes.

As far as conversion, I don't notice transcompilation times. I'm at Ember 2.8 and whatever other versions that were setup.

That's strange. Both React and Ember projects compile ES6 -> ES5 in very little time on my machine.

The reason is probably that it's closely tied to Rails. I don't want to learn Rails, but I keep seeing Ember and Rails mentioned together. Probably the same community is behind them (too lazy to look up).

I don't really know where I have this preconception from, but probably it's not just me. http://discuss.emberjs.com/t/are-developers-creating-ember-a...

Ember has zero ties to Rails. We are using Ember with Java backend. I have seen Ember used with .NET and Go backend. There are even the SANE stack [0].

The only possible tie that Ember with Rails is that it used to bundle ActiveRecordAdapter with Ember data. It is now separated into another project possibly due to this exact reason.

[0]: http://sanestack.com

I think that project is still under ember-data?

https://github.com/ember-data/active-model-adapter

The two are different projects - it's just that they're a popular pairing. I could very well use Ember with Django or Dropwizard or whatever. I picked Rails because the project I'm working on is something that calculates the delta between a Chef implementation and what is in an EC2 environment. Ruby was a natural choice due to a strong library support for both the Chef API (thanks Seth Vargo and friends) and EC2.

It was on a whim that I chose Ember. I have heard of it before and how the project took stability a bit more seriously than other JavaScript frameworks so I went for it and was pretty pleased. It was super, super easy to integrate.

I think another similar pairing is Vue.js and Laravel and that actually makes me want to learn PHP.

I used to do a lot of Code for America work before I got distracted by my career and a desire to move out of my state. When I get back to it, I'll probably choose Rails and Ember just because of how happy I am.

Now, if I decided to stop doing operations/systems/devops work... I'd probably take React and other frameworks more seriously.

> I just started an internal IT tool ...

I think a lot of your ease of use comes from it being an internal IT tool. It's allowed to be clunky, you probably don't have many eyes from marketing/design/product on it-- and if they have seen it, they don't care too much.

Design & product want to be able to do some crazy stuff sometimes. And they're justified in that wish, our frameworks should work with anything that is possible in a browser. Your protests of: "oh well, that's not exactly how the Ember/Rails framework works.." will be met by glazed-over eyes. I really just agree with `erikpukinskis` here, but I think it's an important note that I think you'd have a really bad time if this app was consumer/client-facing.

> "It's allowed to be clunky"

> "that I think you'd have a really bad time if this app was consumer/client-facing"

Gee, thanks.

Now, ignoring the fact that you're immensely disrespectful, you're missing the point of what I'm trying to say. There is nothing wrong with having a small problem that is solved by a simple solution and I'm sharing how I'm solving my problem. I'm not going to choose an engineering solution that's more complex than what I need.

That being said... there are a decent amount of companies that have used Ember to build easy to use and fluid interfaces. I think the very first interface I saw built using Ember was the interface for the Riak data store - which is incredibly slick. Netflix uses it for internal services, Groupon uses it for its website, and so does LinkedIn and Heroku. Actually, technically speaking, Google uses it as well because of their acquisition of Nest - unless they rewrote the Nest store into Angular or something.

If I thought that rendering searchable tables and embedding graphs was more than Ember could handle and would result in a sluggish application then I wouldn't use it regardless of how easy it is to setup. If I thought that it wouldn't allow me to apply basic CSS and buttons and layout principles to my interface so that it's pleasant to use then I wouldn't have used Ember.

And if you think that you can deliver a better web dashboard than what's facing the users of Heroku then I suggest you knock on their door and tell them how to do so.

Ahhh, sorry, I wasn't meaning to be disrespectful, I just felt like it was an important point to shed light on.

I was listening to Joe Rogan's interview of Adam Greenfield (a bowhunter) yesterday, and Adam said something like: "look, if you're looking to get into bowhunting but you don't have the cash to get the best equipment, that's fine. You can still have success with a cheaper bow and without the extra gadgets, but it'll take more time." I'm not saying that you can't build world-class products with Ember, I'm just saying that it probably takes more time if you're getting wrenches thrown at you from design & product.

I also really haven't spent enough time with Ember to really back up my last statement, I'm really just trying to give some perspective from a company-politics / organization-process POV?

Everything you say makes sense, except for your first sentence. For people that do frontend/JavaScript full time and work on complex long term projects, an easy to learn framework that allows you to hack things together quickly is pretty low on the priority list.

"It's really unfortunate that so many people aren't interested in learning Ember."

Is that the sentence? I dunno. I looked at the stats for the first version of Angular and it had a low rate of "heard of it, not interested" and a high rate of "used it, will never use it again" with Ember being the reverse of that. I was just like "awh man, what a pity" because I have really been enjoying my short time with the framework.

"...to hack things together quickly..." That wasn't really what I was getting at. There is a lot of negative connotation around the word "hack." I want something that is easy to setup quickly as well as easy to reason about. With jQuery, I can just point to a CDN and get going. As far as the concept, I can easily understand that I'm just selecting and changing an element of the DOM.

Now, I recognize that jQuery gets super messy and has a lot of inherent limits but the spirit of the approach is something that I admire. Ember, like many front end frameworks, brings organization, conventions for testing, etc... but the concepts are a bit easier for me to grok than some of its competitors and there exists some tooling that removes a barrier to entry for me. That's just my anecdotal experience and others mileage may vary.

"For people that do frontend/JavaScript full time..." Yeah, I dunno. I'm just someone who does front end work for open source projects and when I think it has its role within my regular duties as someone who does more operations work. That being said, I think there are a lot of people out there like me. People who just want to show up at a hackathon and get moving quickly because they have that back end experience but are unsure of themselves when it comes to front end development.

Huh? Why should I use Ember instead of React or Polymer? Does it have a better story for cache management or something?

Why the dismissive "huh?" Was there anything I said that was incoherent or not easily understood?

"Does it have a better story for cache management or something?" I think this question shows a misunderstanding of what I'm trying to convey. I can't really offer a set of deep technical answers when contrasting the various JavaScript frameworks. Most of my use cases for front end development comes down to some pretty simple requirements. I just know that I ran a couple commands, changed a few configuration values, and then got going with what I wanted to do.

Ember had a low barrier to entry for me. There are a lot of community resources for how to integrate it with my back ends of choice, it has a rigorous set of conventions that are easy to cognitize, and the practices around Ember haven't changed for a long time.

Take a look at this Reddit /r/programming thread: https://www.reddit.com/r/programming/comments/55okik/how_it_...

The top two comments are about how difficult it is to determine what is an appropriate stack. A lot of programmers solve small problems that benefit from simple solutions. My anecdotal comment was that I found Ember to be a simple, stable, all-in-one solution that worked well with Ruby on Rails - which is the framework and language that best solved the problem that I was addressing.

For a React specific comment, I think Facebook recognizes this problem and it's why they rolled out their React starter CLI tool. WalmartLab's Electrode platform also looks like an admirable attempt to address the "I'm not that great at this so please configure this for me so I can just start learning and being productive" crowd.

I also really like it when a front end framework shows strong preference for and coupling with a back end framework. Vue, for example, has a strong linking to Laravel. The communities for each overlap and it's easy to get going with both. The Laravel generator, for example, sets up a Vue example so it's easier to get started even though Vue is a wholly separate project that can be used with any back end.

What did you use to learn Ember? I'm also in the "convention over config" camp and I love that the Ember team sticks to it but also introduces new tech like FastBoot whenever they can.

https://news.ycombinator.com/item?id=12631268

That's the comment that listed the article I followed. It's pretty tightly coupled to Rails and ActiveModel but it fit my use case pretty well. I found other resources as I googled around.

I used https://github.com/thoughtbot/ember-cli-rails to hook up Rails and Ember.

I found that I still had to tweak a couple of things like getting generated Rails controller to `render :json` by default but the article was fairly comprehensive.

I suspect that we didn't get enough Ember responders, because I do think they have a reasonable sized community. 9k responses is likely not enough to draw a reasonable conclusion that it isn't popular. I wish we could have paired up npm downloads or some other stat besides some of this data...

Ember has a pretty large community—the framework has a few conferences every year that are filled up. Most Ember devs don't seem to participate in a lot of JS community things and are very quiet compared to say, the React community.

Here are some npm download comparisons : http://npmcharts.com/compare/backbone,react,angular,ember-cl...

Trouble is with angular 1 is a lot of people are probably still installing via bower, angular 2 might have a lot of people installing via jspm, elm uses scoped packages which still don't have stats...

What kind of was a head scratcher for me was that Ember had such a high rate of "heard of it, not interested" from the responders. Especially when I looked a couple columns over at the Angular 1 data where a lot of people tried it but would never try it again.

I don't know how a sample of 9k maps to the developer community at large but I found it puzzling that so many people were dismissive of Ember. What makes Ember unappealing enough to not warrant being tried out in a side project? Personally, I saw it and thought "boy, a framework that wants to be stable for several years - sign me up."

Been using ember productively for years; didn't even see the survey link

I think it's because Ember forces you to do everything The Ember Way. Sure they're technically writing JavaScript, but it only works in the context of Ember. Ember makes it extremely painful to use standard JavaScript libraries so it's not surprising that Ember developers don't respond along with the rest of the JavaScript community.

Have you tried riot? Or mithril? Small and simple.

Regarding react I don't think there is anything in react itself that says that you have to use es6 and an advanced module bundler (like webpack). Just use es5 code, place everything in one file or just concatenate the files before using them in the browser and everything should work. You mainly loses out on how easy it will be to copy from tutorials that are written for es6 code with modules, and that some 3rd party things are written as modules.

> It's really unfortunate that so many people aren't interested in learning Ember. I just started an internal IT tool in Rails and Ember and I'm really enjoying the simplicity of it.

What probably killed it for me is when i tried using it a few years ago and i spent a whole weekend on it and ended up with something barely functional and generally being frustrated with a lack of documentation and helpful errors.

Hah, that'd do it. I did notice that it can be a pain to generate a data structure that feeds into ember data. If the structure doesn't match what ember expects, then you don't get an error that spits out the structure that was sent and the structure that is expected.

I was able to gain understanding by using ember inspector to inspect the store and using jq to inspect the json returned from my Rails endpoints.

We think Ember is great. If you want a framework (or any FOSS solution) for the long haul (years, not months) then back a horse that isn't ran by a company who is going to change their strategy every 6 months.

It's nice to see some love for Apollo here. It's leagues better than Relay and has definitely been the biggest boon to my development stack in a while. That being said, the article should make it clearer that Apollo is perfectly usable just as a frontend client—you don't have to adopt the backend at all.

The Meteor team really deserves commendations for learning from some of the mistakes in building Meteor. Apollo specifically emphasizes incremental adoptability: you can drop it into an existing project and see benefits almost immediately, without having to refactor/rewrite any of your existing code.

I'd also like to provide a counterpoint to the inevitable complaints about the complexity and low-productivity of a JavaScript. In my experience, once you've paid the initial cost of learning these tools you can become extremely productive. As a freelance developer who is paid a flat rate for projects, I'm directly incentivized to find an efficient stack and the modern JavaScript stack is definitely it.

Specifically, my stack these days is Django + Graphene + React + Redux + Apollo. It's insanely high productivity: I can usually have the basics of an app built within a few hours of starting.

(Disclaimer: I work on Apollo)

Yes, it was a bit surprising to see "Apollo" separate from "GraphQL" here, since our primary focus is to enable people to take advantage of GraphQL no matter their frontend and backend architecture.

It makes the most sense to make a direct comparison between "Apollo" and "Relay", but they should both be considered a subset of "GraphQL", which is really the core technology that everyone is building on.

However, excited that people like it, and we're excited to collaborate with everyone to make it the best way to use GraphQL in an application!

Do you guys know something loke Apollo but on top of RxJS?

I'm not a big fan of Redux anymore since I discovered observable streams.

Apollo returns the data in observable form. You never have to deal with Redux directly if you don't want to. Check out the Angular docs for more details.

I agree that Apollo is a subset of GraphQL, but I wouldn't have been able to collect any data on it unless it was a separate answer.

It's your fault for building something innovative that doesn't neatly fit in a pre-existing box… (same thing with Meteor actually!)

Respectfully disagree--I like Relay better. And Relay 2 is including client-side state, so you don't need Redux.

It has a steep learning curve and some initial setup overhead; but from a long-range perspective--I think it will have better performance and code comprehensibility. Maybe Apollo is better suited for freelancers though.

I thought Relay already had client side state? Also what's Relay 2? Where are you finding information about it?

My opinion of Relay right now is that it has way too many needless complications. It looks like it brought a ton of baggage from being used in Facebook that just gets in the way of general use. So I'm interested in an alternative.

However, the real problem with all of this stuff is cache management. Properly managing the cache in the face of mutations is very complicated and it's impossible to be perfect anyway without some sort of pubsub.

By client-side state, I mean user interactions that affect variables used across the app that don't need to be persisted. Relay doesn't do that yet, as it only deals with persisted data. @josephsavona[1] and @wincent[2] are the guys putting information out about Relay 2. Greg Hurrell (@wincent) did a talk[3] about it in August.

And since I'm linking to related resources, I just want to add a plug for an awesome project a friend is working on (and we're putting it into production on my startup project). @calebmer/postgraphql[4] let's you get a free GraphQL API from a PostgreSQL schema.

[1]: https://github.com/josephsavona

[2]: https://github.com/wincent

[3]: https://www.youtube.com/watch?v=OEfUBN9dAI8

[4]: https://github.com/calebmer/postgraphql

@calebmer/postgraphql is an awesome project and really worth looking into! I actually built a system on top of it which automatically generated GraphQL change subscriptions through Postgres triggers.

I always thought relay was an alternative to redux

Not really. Relay is mostly designed around querying a backend data store, not updating/managing client-side state.

Relay v2 will bring with it a way to manage client side state.

Interesting. I didn't know that.

If anything, that actually somewhat affirms my preference for Apollo. Since Apollo is built on top of Redux, you can use both in tandem without any problem instead of having to learn a whole new tool and refactor your application to use it.

Relay already is a replacement for Redux. It wraps React components and it has a store. How could you even use Relay and Redux together?

> Relay already is a replacement for Redux. It wraps React components and it has a store

That's hardly the definition of a replacement for Redux.

Relay v1 has absolutely no client-side state management support. I'm sorry but it's incredibly disingenuous to say they're substitutes at this point. Apparently v2 will have some client-side support.

To be clear, I don't want to bash Relay. I really like GraphQL and have Relay to thank for helping me to get stated on it. I've just found it to have a lot of challenging complexity which is really hard to manage, especially compared to Apollo. Also, "replacing Redux" is really not a selling point. The Redux ecosystem is strong enough at this point that being able to work with it is a huge advantage.

> How could you even use Relay and Redux together?

Pretty easily. The nice thing about the React ecosystem is that things rarely conflict with each other. In my case, API data is updated/fetched via Relay while purely client-side info uses Redux.

You wouldn't happen to have a seed project with that stack by any chance? I would be very interested in trying it out.

I haven't updated this to use GraphQL yet, but this is my standard project starter template: https://github.com/gigster-eng/python-starter

What part does Graphene play (assuming you mean https://github.com/graphql-python/graphene). Are you building graphql based apis rather than rest ones?

> Are you building graphql based apis rather than rest ones?

Yes. The Django models are exposed through a GraphQL API (using Graphene), which I query using Apollo.

I'm curious: how do you think about client vs server side rendering? What happens where?

For apps which need it, everything generally happens in both places. The server-side render fetches all the appropriate data and displays a fully rendered version of the page.

That being said, I think you should carefully consider whether server-side rendering is necessary for your application before adding it. It does complicate your stack and is not worth it unless either first-load performance or SEO are important to you.

Thanks! Are you using the Django template language on the server or using React somehow?

I appreciate that for the next year when there is a framework war I will have a link to shut it down.

Typically a newbie will ask about which framework they should learn. There will be a bunch of "it depends" and "try them out" responses, and then someone will take pity and pick a clear direction based on their experience.

Well and good.

But this way the newbie can learn from the actual experience of lots of other people. Data, for short.

The same, from my slightly different perspective: I've been away from JavaScript for 3 years, and it is awesome to have a resource to help navigate the way back in, and get the most bang-for-my-buck, so to speak.

I can tell here what tech I need to focus on for my pet project, which will also improve my hirability looking forward.

>> Typically a newbie will ask about which framework they should learn..

Honestly the easiest way to learn this is to contact your local recruiters and ask them to send you some openings for FED positions.

In nearly every one, you will see which JS framework is the main one they use. In my recent experiences (the last two or three years) most corporate environments are using AngularJS, while the smaller startups are using React and some mix of various other libraries for their apps and sites.

There are still a few agencies I know using BackboneJS, since it was in that first wave of JS frameworks and there's apps and sites out there which still need supporting.

Interesting approach, but I will note that even you have recommended three (Angular, React and Backbone).

People generally put forward one of the following: Knockout (easy to learn), Ember, Backbone, Angular, React.

Someone will invariably say no, use nothing but plain Javascript at first. This will lead to a little subthread about whether it is fair to include jquery.

Every now and then someone will come up with meteor or vue as an alternative.

> there's apps and sites out there which still need supporting.

When a technology is less popular than it used to be, there's also a glut of experienced talent in that technology. That's why trends matter more than just a point snapshot in choosing what to learn, if you're looking at employability.

Seeing what developers prefer and recommend is a better way to get in front of the trends than looking at what codebases companies are (stuck) maintaining.

Unfortunately the JavaScript ecosystem is frothy enough that a lot of junior developers are inevitably going to waste time learning technologies that will be considered obsolete by the time they have mastered them.

Seeing what people are hiring for is of course a useful signal too but it's easy to become a COBOL programmer if that's the only thing you look at.

I'd love to hear more from people that expressed certain viewpoints - specifically those who used a library but wouldn't use it again... Specifically mobx :)

I've played with most popular js libs now and I've found that for my use case I wasn't totally happy for one reason or another. I've been dabbling in mobx for that last few weeks and the ease with which it has allowed me resolve issues in my codebase is really promising.

If anyone here is in the 58 people who wouldn't use it again, care to share what you ran in to?

After using Mobx for a few weeks, I've come to question why anybody would use anything else. It is the only software I've ever used that was created for a dynamic language that has me trying to re-implement in my favored strong/static typed languages. Now I just point and laugh at anybody trying to make sense of their Redux global state atom with a bajillion reducers.

So far, I've only found one common objection to it: that it embraces mutable state. Well duh...UIs are state machines. They need mutable state because their entire existence depends on it. Sure, you might be able to model the mutable state of UIs using immutable data structures, but you can't get rid of the mutable state. And because of this, my opinion of this objection is that it is of a religious nature. You can ignore this particular objection with no risk at all.

I'm unconvinced by this argument.

State machines don't let you change things whenever you feel like it. There are a set number of states and a bunch of predefined transitions between them.

That structure is exactly what redux forces you to implement - whereas in MobX it's up to you to apply the same constraints.

Redux with plain JS objects a a little messy IMO, because there aren't lots of nice & readable ways to transform objects without mutating the previous version. I use it with Immutable JS and am very happy with this approach.

I made a poc with Redux and I felt that a) the boilerplate obscured my code b) the async story was pretty confusing and c) managing my derived / calculated properties was really hard.

One thing I've discovered is that a lot of the logic is derived data in the form of pure functions. A huge amount of my codebase seems to be about managing the derived state that trigger from a core bit of state changing. Really there's actually a much smaller core set of data, and then various aggregations on top of that (with the component view tree being the final representation).

I initially played with MobX a while back and had the worry that you could end up with state changes triggering off all over the place, but I don't think it needs to be like that.

There's no reason you can't have core state, layers of calculated properties and a view. Having said that, it's early days, which is why I'm looking to hear real stories of where MobX hasn't worked.

My approach when evaluating technology is to try to find ways in which it works poorly so that if I do pick it up I'll have an idea of the limitations (and can try to work around them).

MobX does also have "strict mode" where you have to declare the transition points. I know that's not really the same as the reducer model, but it does force people to think about when state will be updated.

> That structure is exactly what redux forces you to implement - whereas in MobX it's up to you to apply the same constraints.

Redux doesn't force you to apply constraints any more than Mobx does. In fact, it's even less structured than Mobx...any component anywhere can emit any event that modifies any state. With mobx, you can only modify state that you have an actual reference to.

> Redux with plain JS objects a a little messy IMO, because there aren't lots of nice & readable ways to transform objects without mutating the previous version. I use it with Immutable JS and am very happy with this approach.

I agree that semantically immutable data structures are easier to comprehend and work with. But you still have to mutate state, or you don't have a UI. With immutable structures, you copy->modify->replace...with mutable structures, you mutate in place. You can't avoid mutating state with UI programming, so embracing a model that embraces intelligent manipulation of mutable state isn't an indictment, it's a tangible benefit.

The right way to get rid of mutable state is to replace it with a stream abstraction, which declaratively models how the state changes in response to events. That would be cyclejs: http://cycle.js.org/

Too bad that this model doesn't work well with React. React models the UI as a (mostly pure) function from props/state input to DOM output, however in reality the UI is a stream containing both DOM states and input events. The minimal modification would be to select the input events that a component would like to expose in its event stream, in a similar manner to Elm: https://guide.elm-lang.org/reuse/checkboxes.html

Why do you say that's the right way? Is there something intrinsically better about having the state modelled as a stream of changes? Is that really getting rid of mutable state? [EventA, EventB] is a mutation of [EventA], sure it's a WAL style, but the combined final state is a mutated version of the original state.

Presumably the concrete state model (like MobX) is a realisation of the event stream at a moment in time. As far as the user is concerned, the only moment in time that really matters is now.

You should check out cycle-react [1], as it combines the best of Cycle and React.

[1] https://github.com/pH200/cycle-react

> They need mutable state because their entire existence depends on it. Sure, you might be able to model the mutable state of UIs using immutable data structures, but you can't get rid of the mutable state.

Can you give an example of this?

I have worked on fairly complex Redux applications but have never ever mutated states and it has been just fine. In fact, I use ImmutableJS to keep my apps' states.

State machines without immutability in a large application sounds like a joke to me, sorry.

If you haven't mutated states, you don't have an interactive UI. With immutable data structures holding your state, you mutate it by re-assigning variables. This is exactly what Redux does.

In fact, the rendering benefits of immutable data structures comes from the fact that you can perform equality comparisons by reference safely, and ref comparisons are faster. Any time you re-assign a variable, you change that variable's reference, and it is no longer necessary to deep check the reference's value to know that it changed.

I'm really interested in what you're saying about UIs as state machines. Do you have any articles/references to back this up? Genuine curiousity here.

If you have an interactive UI, you have a state. A button is either pressed or it is not pressed, active or disabled or hidden. A text form has a text value. Your layout has state (position, color, etc.).

If your UI is interactive, you have events and actions that mutate that state. A keyboard event modifies the state of your text form field. A button press signals an action. Etc.

A state machine is `State0 + Event -> Action + State1`. Since your UI's entire functionality can be described by the state it is in combined by the Events and resulting Actions and changes in States, your UI is a state machine. This describes the superset of all UIs. Non-interactive UIs can still be described by this, although the benefits are slim because the state isn't really mutated without interactivity, so your State0 is always equal to your State1.

Note that I'm saying UIs are state machines...not like state machines. They literally are state machines. Whether you model them as such is up to you, but my claim here is that modeling your UIs as state machines has tangible benefits because they are state machines.

Funnily enough, there are plenty of articles out there that claim to make stateless UIs. These claims are false...any critical look at the model shows that the state exists, but either is modeled implicitly (keeping state in the DOM and outside of javascript, or within a rendered object, or within a closure attached to an observer somewhere, etc.), or explicitly moved somewhere else. There might be some merits to the latter model (as well as some drawbacks), but the former model is just delusion...a perfectly leaky abstraction where you have state, but have lost your ability to work with it.

The person you're replying to didn't specify whether UIs are represented as state machines which are finite or infinite, but I'll assume finite since infinite automata are more powerful than Turing machines so they presumably can represent something which is made by a computer.

UIs in general can not be represented by finite state machines. An example is a page with a button which when pressed adds something to the page. Since there are an infinite number of things that could potentially be added, this can't be represented by a finite number of states.

On the other hand, I think many UIs could be represented by finite state machines, although perhaps sometimes only roughly. You can start by trying to specify that each instance of a specific page a user can see is presented by a state, and any interaction with the user that leads to a different rendering of the same or a new page is a transition. However, this fails to account for things where a user can do something which doesn't change the current page but might change a later page. You can account for this by having multiple states which show the same exact UI but have different transitions to future pages. Of course, it isn't just the user who can interact with your system to produce a different UI for other people, so you'd have to model those transitions and states too..

I'm not a front end developer so I don't know how many UIs can actually be modeled this way, but I can see how it might be a useful way to think about things, even if it isn't necessarily always correct.

I second that. My experience shows it is a state machine, but I have not see any formal study of it.

I love mobx (definitely not one of the 58), but I would use redux on large apps (maybe, more than 15 pages?), especially if you don't care too much about performance. Redux has better debugging, forces more structure to the code, has a immutable data story, and there are more resources on the net if you need to bring developers up to speed. There are some configuration options for MobX that force the user to be more organized, but redux still feels more structured.

That being said, MobX is absolutely my go-to state management library now - it's probably the easiest free FPS you'll find anywhere, it's ridiculously easy to write, and it results in fewer LOC.

Out of curiosity, why do you say "don't care much about performance"? Redux can be _extremely_ performant, although it does take a bit of thinking about how your data is organized. I've got several articles discussing Redux performance [0] in my React/Redux links list [1]. In particular, check out Dan Abramov's PR to a MobX/Redux benchmark [2], and the article "High Performance Redux" [3]. Finally, the upcoming React-Redux v5 release shows noticeable improvements in a variety of scenarios [4].

Any specific issues with Redux performance that you've noticed?

[0]: https://github.com/markerikson/react-redux-links

[1]: https://github.com/markerikson/react-redux-links/blob/master...

[2]: https://github.com/mweststrate/redux-todomvc/pull/1

[3]: http://somebody32.github.io/high-performance-redux/

[4]: https://github.com/reactjs/react-redux/pull/416

Second that, MobX has been a total game changer for me. Used redux and really like the philosophy of it, but overall feel mobx is much easier to use while accomplishing just as much, and the simplicity and lack of boilerplate actually makes reasoning about state, testing, etc much easier than redux. I disagree about large apps (switched to mobx on a large app now), but I can roughly see what you are saying. Still, I think MobX is great on large apps

Yeah just to add-on to what other people are saying in replies, another happy mobx user. If I could guess at a complaint, I've worked on Ember projects (which have some similar observer / mutable capabilities) and have seen how "clever" observer / mutable-state code can turn out (overly complex). Which is to say -- it gives you some really awesome capabilities but no pre-set architecture for setting up your data modeling layer.

At any rate, I really expect this library to take-off in the next year or two, and love introducing it to people who have not heard of it (normal response: "What? Whoa"). If you already have a lot of React experience, I think their 25-line timer example is a great place to see what it can do for you: https://jsfiddle.net/mweststrate/wgbe4guu/

As someone who doesn't work incredibly often with Javascript but has dabbled with MEAN and extensions of MEAN, I found one of the last questions a bit biased in its results:

"I would like JavaScript to be my main programming language" (Rate 1 to 5)

49% (5) 35% (4-3) 16% - (2-1)

If you've taken this survey, it means that you have done at least a decent amount of work with Javascript. Chances are, you have at least enjoyed something about it so far, or are absolutely required to use it for some reason.

Of course many current Javascript users want it to be their main programming language.

I love this survey for so many reasons, and this is an incredibly small point. Personally, I think that a good Javascript tool, framework, flavor, whatever, should be able to easily integrate with other technologies. I really enjoyed Angular for that reason (yet to dive into React). I think the idea of "JAVASCRIPT EVERYWHERE" is just really unneeded. Yes, we are stuck with Javascript as a language. Yes, it should be more than a simple afterthought on top of other tech. Making Javascript better and safer doesn't mean you have to do it everywhere, because ubiquitous Javascript doesn't matter if the different dependencies are completely different anyways.

The last part is only my opinion, but I wanted to add it because I think the survey's nature is going to exclude many people with it.

It would be interesting if they'd also asked "How many other programming languages do you know besides JavaScript?"

And compared how many people want JavaScript to be their main programming language because they only know one programming language and don't want to learn another, with how many people know multiple programming languages and would rather program in JavaScript as their main language because they like JavaScript better.

Its interesting because the reason I think "JAVASCRIPT EVERYWHERE" is valid is because I think "EVERYTHING EVERYWHERE" is valid. Don't get me wrong, some languages are incredibly domain specific and don't make a tremendous amount of sense at all parts of the stack (and some parts of the stack should have domain specific languages), but JavaScript is a general purpose language, that has some interesting things to offer different domains (whether it be server development, app development, etc), but most importantly... SO DO MOST OTHER LANGUAGES! I would love a world where I could choose from most general purpose languages for most tasks. I haven't found many reasons other than "why?" for being against JavaScript being everywhere. I know that if I was a Ruby guy I'd certainly like it if I could use Ruby in as much of the stack as possible, and I think that's totally reasonable. For example, I applaud transpile-to-JS languages so that you can use a language of your choice for the browser (vs thinking "why do we need Clojure everywhere!").

>Overall, developers are not happy about JavaScript testing.

This is because of the low percentage of devs in the survey who have used Jest. I can't begin to describe the joy of finally finding a JS test utility that just works and doesn't require a giant configuration file.

If you aren't using Jest, make the switch now! It's likely a lot of your existing tests will work with Jest.

Totally agree. Just switched to it on Redux and this was all that was involved: https://github.com/reactjs/redux/pull/1951/files

Most of that is just find-and-replace kinds of changes. But we dropped 3 dependencies to one and sped everything up in the process. It's just a fantastic tool! I finally feel like I've got a good Rspec equivalent in the JS world.

I noticed that! I often refer to the Redux docs for examples and was glad to see you had also switched to Jest. You guys have some of the best documentation around, by the way. I wish you did the docs for Flow and Immutable as well! They could use some major improvement.

The survey should separate unit testing and e2e testing.

I don't know what the general feeling about e2e testing in the JS community, but in my last job we had to write, fix and maintain hundreds of e2e tests and it was a nightmare.

Our stack was Angular 1 and the de facto Angular e2e tool, Protractor. We wrote tons of helpers, like waitToBeVisible & waitToBeHidden, most of them copy/pasted from StackOverflow because every users of Angular and Protractor have the same basic troubles and use the same workarounds, and we had to use those helpers in every test. Also I can't imagine the number of hours spent to mock our Angular services + MySQL/Redshift data, to spy the functions who manipulate url/cookies/localStorage/etc and to write some "page objects" to make the tests readable.

In my opinion: The benefits of the e2e tests are too small to justify the crazy amount of time spent to make the new tests work and maintain the existing ones. Most of the time, the tests break because someone has changed something in the DOM or renamed a CSS class or modified an external API and forgot to update the tests/mocks. But they almost never break for a regression... so what's the point?

Or otherwise you need a dedicated team with 1 or 2 engineers (for a small/medium company) working full time on the e2e.

(PS: I used only Protractor with Angular 1. I haven't tested the other tools like Nightwatch.js, and I don't know what they have done for Angular 2 (Protractor 2?). Now I develop in React and just do unit testing & dog fooding).

Yeah, I've been putting off e2e testing while I pray for a decent tool to come out before I really need it.

I think the benefits come when you're really making use of reusable components. I have about 20 views that all make use of the same Redux container component, and e2e tests would definitely help me sleep better at night.

I used Jest early on, it was nice, but I quickly started to encounter problems related to how new it was. It's way better now, so maybe I will switch back to Jest from enzyme.

You can use Jest together with enzyme! We posted a big community update together with Jest 16 which should highlight a bunch of ways that you can test with Jest.

https://facebook.github.io/jest/blog/2016/10/03/jest-16.html

The only things I found really annoying ... Completely disappeared in the last major update. Very clean to work with now.

Can Jest run concurrent tests? I'm using Tape as of late and I find myself having too many long-running functional tests in series but it doesn't seem to be something I can work around.

Hey! I'm Christoph and I work on Jest. We wrote a blog post about how we are making Jest fast: facebook.github.io/jest/blog/2016/03/11/javascript-unit-testing-performance.html

If your test is fully CPU bound and limited to one core, it probably won't be faster with Jest. If you split it up across multiple files, it will parallelize tests.

Yes, yes it can. And because it can isolate tests and reset the environment, you don't really have to be (very) careful about what you do in your tests so order doesn't matter. It makes it really hard to fail there.

I love Jest, but thought the 59% satisfaction with Jest was unfortunate... probably super-early adopters?

Jest used to be very meh. Also, Jest by default would cater to more "purist" unit testing. Everything mocked, everything isolated, runs in node, no browser.

A lot of people in the frontend world equates unit testing with Selenium tests (aka: integration tests) and get really ruffled/confused by "pure" unit tests.

Now Jest changed the defaults to what most people expect, which will confuse them less, I suppose.

I wish to register my complaint with the term "ES6" which has always been unofficial and refers to the official standard "EMCAScript2015".

Same. ECMA changed to using dates a while ago and people are still saying "ES6" and "ES7". I've also seen people refer to all new syntax and features as "ES6" including things that in ECMAScript2017.

Honestly though I think ECMA has some of the blame for this. I don't think they do a very good job communicating changes and versioning.

Yeah I think there is just a lot of friction when moving from the concise "ES6" to the lengthy, and somewhat awkward "ECMAScript2015". The fact that so many people still use the terms ES6 and ES7 gives others even less incentive to use the official naming scheme. Hopefully, it will iron itself out in the future.

I think its not just the length but the concept: Every other language has a normal looking version (Rust 1.12 announced! Java 8, etc). They had that with ES3, ES5, ES6, then decided (perhaps for very good reasons) to change to a unique (?) version scheme.

What did ES5 change to then? I never heard. Honestly, ES2015 just seems odd to me.

In my experience ES6 means "modern". Anything that wasn't there before 2015.

Considering we're encouraging everyone to use transpilers and features from the future, and that browsers will forever lag just a little bit behind, I don't think that's a super bad idea. Most programmers don't care exactly which features are in ECMAScript2015 and which are in ECMAScript2016 etc. All they care about is "Can I do this thing I saw in a code example? Oh cool, it works".

Detailed versioning is an implementation detail.

> Considering we're encouraging everyone to use transpilers and features from the future

Please don't encourage this. Transpilers have a huge set of dependencies and technical complexity. I know everyone is in a hurry to use the next standard ASAP but, especially for new people, I think transpilers should be recommended against. Otherwise now you now need a build process and you need to learn how to use map files to properly debug back to your original code not to mention being unable to properly debug on older / alternative browsers.

> Detailed versioning is an implementation detail.

For the engine sure but for everyone who needs the features they need to know what is supported when, etc. It's far, far more than a simple implementation detail.

Yeah, there's also that the naming convention has changed formats so many times in the last few years too. People need to see repeated pattern for it to sink in.

ES6 refers to ECMAScript version 6, which was the official name of the latest version up until around December 2014. I believe ECMAScript 2015 was coined by Dominic Denicola to put additional pressure on TC39 to publish that year.

You are right, ES6 has a lot more traction than I thought. The reason I posted that was because I had a lot of trouble understanding what ES6 was referring to when I first started researching it, and it seemed like an amorphous standard with varying features depending on who you ask. But no, it's an actual standard published as "version 6".

Incidentally I misspelled "ECMA" in my original comment, so now it's easier to see why it won't catch on anytime soon.

Can we just jump to "ES15" and get the advantages of both semantic correctness AND brevity?

Three syllables vs eight.

"EMCAScript2015" is a mouthful, and I suspect a lot of people would assume it's referring to the "old" version of JavaScript just because it's not the current year.

It might be the more "technically" correct name, but from a branding/marketing/communication point of view, ES6 is vastly superior in my opinion.

I think it's better to address complaints to not so smart decision of renaming well-known and widely adopted terms.

Super interesting. Lots of data there.

Two things that stood out from a quick once-over:

Vue is doing better than I expected.

PostCSS is less adopted than I expected.

I've been toying with Vuejs 2.0 for a few days. Thus far I'm very impressed with it. The docs are a quick read and the whole framework feels really intuitive.

I'm a big fan of Vue's single file components where you can keep a component's HTML template, CSS, and view model code together in one file. In React, I tended to use lots of inline styles. I also like that I can use templates for the majority of the simple cases while still having the full power of a React like render function (with JSX support) if needed.

I hope Vue is going to be quite popular. I haven't actually used it but have looked at the documentation and have heard so many people praise it. I have only heard of good things. It just doesn't have the support like Angular or React has from the big Companies.

I just tried Vue 2.0 for the first time last week and I really really liked it.

I had a similar experience with Vue about six months ago. I read the documentation and then gave myself an hour with it. By the end of the same day, I had re-factored a very complex dashboard and enjoyed every minute of it.

My biggest complaint is that I love React/MobX and Vue which makes choosing one over the other really painful. What a great problem to have!

At least in Angular, I can make a template in a directive for styles, which solves the "put repeated stuff in a variable" problem, without bringing in yet another tool.

(use a string for the template, not a file)

I don't remember the phrasing of the question but it could very well be that a lot of the cssnext answers use PostCSS as well...

That doesn't mean that it has huge usage anyway though.

I wish PostCSS had a good story for variables. As it stands it is just super poor. I use some PostCSS but sparingly.

For the life of me I can't understand why webpack has become the de facto build tool. It's so much more complex than anything else I've tried. I understand it's supposed to be faster, but still, I wouldn't bother with it until your build times actually start to become a nuisance.

I don't think webpack is best considered as a build tool. It's primarily a dependency wrangler - it lets you define entry points, which can declare arbitrary dependencies on assets, which can then declare their own dependencies, forever and ever, and webpack will wrangle all that into a single JS file, a single CSS file, or whatever it is you need. As it happens one can also do build-tool stuff (transpiling, prefixing, etc) on the resulting files, but that's not where the magic is.

What else have you tried? All of the alternatives have left me compromising on the way I build my front ends. The docs for Webpack aren't great, and configuring it might be a bit painful, but if there's a better option I would love to know what it is so I can start using it.

Things I want:

* es2015 transpiling * jsx support * css/less/sass support * module loading * uglification for production builds * hot module replacement * source maps * multiple bundles/entry points * hashed file names

Brunch fulfills a lot of these requirements, and I use it when I need to spin up an application really quick. But it misses on just enough items to make me reach for Webpack when I build anything serious.

parched-tasks-webapp has all but one of those things (hashed file names), and it's just built on browserify. And you don't have to do weird things to get your CSS out of your JS on the server.

Why not just use css modules with the extract text plugin to put everything in a single stylesheet to solve that problem? For Dev it supports hot reload, and other environments get an extracted stylesheet that works with sever rendering and avoids fouc's. Plus you can autoprefix the output, and because of the css modules design you get encapsulated component css for free. The annoyance is working with a css framework or its js library, i.e.: bootstrap or material as each one seems to have a different approach to css dependencies. But I think those frameworks are becoming less relevant or can have their limitations worked around usually depending on which one you choose.

Webpack got swept along in the React zeitgeist. Few people who use it really take the time to understand it.

It's a pretty slow way to build a project, but that's actually not the main sell. The main sell is in smart asset chunking, and it's pretty darn good at it. That alone earned it a place in my skillset.

Absolutely. Finding out about code splitting was incredible -- I was able to get on-demand loading of resource files working in about ten minutes. One of the most amazing "it just works" experiences I've ever had.

webpack allows some pretty sophisticated resource pipelines that go beyond what you can do with browserify, especially around binary resources.

One of my use cases is working on a HTML5 game. I pre-process all the tilemap levels to add unique IDs to the entities within the file, but only for those JSON files that look like tilemaps. Each of those files' names get mangled as a hash of their contents as well, so I get some cache-busting for free.

Similarly, I can pngcrush the image assets that pass a certain rule, etc.

Awesome. Guessing you wrote your own Webpack loader for tilemaps? I'd love to hear more about what went into that.

I had the same reaction as GP when I first saw it (meh, just another overly complex tool, who cares) but you can really do some ridiculously cool stuff with it. I also love how stable it is, compared to the ecosystem it's associated with.

Sure! Here's a short write-up I've been meaning to do that you spurred me into: https://drhayes.io/secret-game/map-entity-loader.html

The save system is next on my list of write-ups.

I switched from browserify to webpack when I started writing ES6 on the client because the browserify build times with ES6 were slow enough that they felt disruptive to my workflow (somewhere between 10-30 seconds, I don't remember the exact amount). I'm not sure if that's improved now for Browserify, but it's the kind of thing that you're not likely to switch back from once you have a working setup.

I use watchify [1] for incremental builds. The initial build is still long (10 - 30 seconds, as you said), but with each change after that the build updates in < 1 second.

[1] https://github.com/substack/watchify

It's complex but it's worth learning. You can do a lot with it; transpiling, bundling, source maps, css modules, autoprefixing, concatenation, minification, etc. Along with npm scripts and a little shell scripting you can pretty much do whatever your project needs, including auto Dev deploy, ci, one touch versioned stage/prod deploys with rollback etc. And it seems to be the common base people are building the best plugins for these days. It's far less verbose than grunt or gulp, and plugins are not needed for every little thing as a wrapper. But when you need plugins, there is a great system for them, and a ton of community plugins available.

because real webapps, that actually do stuff that can make money and keep users happy, are complicated.

Even now, Webpack is kind of feature anemic compared to what the real world needs. We just do with what we have. Or in the case of companies with $$$ to hire devs to work with it, we just build a shitload of plugins and loaders.

Webpack replaces Browserify.

Browserify, while groundsbreaking, turned out not to be so good and much harder to extend.

Since webpack is not straightforward to use with other build tools, and since it can do most build actions easily enough, people use it for whatever they can get away with, and that usually means most of what you'll use grunt or gulp for.

One thing I have noticed over the years is that the front end community is becoming more and more a "let me google how to do it" kind of community. The tooling ecosystem is so burdensome. Just to get a hello world app with React, Redux, Webpack, esLint, and ES6 takes forever. Sure there are starter boiler plates but they all don't seem to do quite what you need. Before it felt more like a solidly engineered app, now it feels a lot more like glueing various snippets from StackOverflow together.

I'm also finding the overhead from React / Redux very noisy. I have to do so much typing and define the same thing over and over across a bunch of different files just to do something simple.

I really like how Elm basically implements all of this with much cleaner syntax and works out of the box. It's too bad it doesn't have as much community behind it. I'd like to use it more but find it doesn't have enough community for me to consider using it for anything outside of home projects.

I'm not sure why you've been downvoted. I absolutely LOVE that Elm simplifies the boiler plate of a front-end app. Instead of needing a dozen different packages and tools, you basically just need the Elm core library and you're good to go.

I would only use React/Redux for a complex app that's going to be touched by a lot of people. That's where it really shines. Elm is a non-starter in these situations -- I can't seriously propose it for a project because the learning curve is astronomical.

Also, I think simple Hello Worlds are a dangerous thing. They convince you that a tool solves all your problems until three months later when you notice your foot's been blown off.

The learning curve is a weekend of reading.

Elm is much SIMPLER than js, but not as EASY for you because it is new.

If you are at all familiar with compilers, types, and functional programming it should all be review anyways.

If not then you are missing a big part of your education and I would question your capabilities as a programmer.

> One thing I have noticed over the years is that the front end community is becoming more and more a "let me google how to do it" kind of community.

Odd, I have the opposite impression. I view a lot of web developers as the self taught, figured it out for themself kind of folk. I see React as a counterpoint, pulling in ideas from more academic or enterprise-y parts of the field (functional programming, significant tooling, emphasis on correctness).

The elm community is definitely growing. I see posts here almost daily about it, and if you really want to write it full time the positions are out there.

Gives me hope for Elm, there are a lot of potential converts out there.

I apologize if the predictability of this comment, but I just want to say, I recently started a new gig at a company that has undergone a full on embrace of Javascript for tooling and server side projects and it boggles my mind how much productivity is wasted on this ecosystem. There is an interesting amount of energy put into making asynchronous code read synchronously in situations where asynchronous code provides no benefit. The dependency tree of any one project tends to be incomprehensibly sprawling. Runtime version numbering is... weird. Don't even get me started on the interplay of Gulp, Grunt, Webpack and NPM. ES6 is bizarrely noisy. ESLint fascism is a necessity given the history of legal anti-patterns the language must shoulder. Scoping can occasionally lead to absurdist solutions [1].

I know this is the future and I'm trying to embrace it, but boy does it feel icky doing it.

http://stackoverflow.com/questions/33629343/what-is-the-best...

Could it be that you are still just new to it (in the grand scheme of things)?

Because all of those things sound very similar to the complaints I hear from web developers on their first foray into desktop development.

There are so many tools it's impossible to know them all (or to even know which one is best to use in which situation), so much legacy code out there it's tough to learn what the "right" way to do things is, it often feels like you are fighting the OS or the language to get what you want how you want it, and dependencies are hard.

Application development is hard, and is still far from "solved". And while the "web stack" is far from perfect, I'm personally significantly more productive in it than I ever was in anything else. And in my experience that extra productivity makes better applications because I spend less time just trying to get it working, and more time getting it working well.

See, I'm not sure that's the case.

When I started writing apps using Cocoa, for example, I had a pretty good experience. Yeah, I fought some of the tooling that I wasn't really used to, but given that it was quite different from my backgrounds in web and embedded development, I was overall quite pleased with how easy and more importantly how obvious everything was. I found this to be the same when I wrote applications in Qt, and also when starting to work with newer languages (like Go).

This contrasts very much with the Javascript ecosystem. Despite having been a nominal web developer for approaching a decade, I am still consistently baffled by how difficult it is to get to grips with how everything is put together. There seem to be dozens of different workflows, none of which are entirely compatible with one another. There are bad configuration formats all over. Every tool seems to be broken into 200 different parts that subsequently have to be reassembled in order to implement a working pipeline. Documentation is erratic at best, and so on.

I used to feel pretty productive with Javascript, back when the web was a bit more 'Wild West'. But as it has developed as an application platform, it feels more and more like I am fighting the tools, rather than having them help me. That's not a nice feeling.

My experience is the opposite. I've been working on the web for over a decade now and only until a couple years ago have I really been happy with my stack.

My usual stack looks something like: Express / React / Redux / Webpack / Enzyme / CSS Modules

I do SSR / Universal JS whenever possible and it works great. The only problem on my stack nowadays is the CSS. Still haven't figured out a good flow. I currently use CSS Modules, but without dead code elimination, it just doesn't do exactly what I would like to (feed in the whole CSS library I use and let it pick and choose the classes that are used in my components, throwing the rest away)

Getting up to speed on all these tools hasn't been easy, but at this point, most of my projects are a breeze. No worrying about browser JS support. No worrying about CSS support. No more choosing between server side and client side rendering. Linting that works great and keeps the projects looking clean. Testing that doesn't make me wanna blow my brains out. Combining and minifying projects is a piece of cake. HMR + Autorefresh is like magic.

I'm really enjoying working on the web now.

IMO, the problem is looking at Javascript as a single unified thing. One thing I came away with from this survey is that there are two major competing "stacks" at the moment- the Typescript/Angular stack and the Webpack/Babel/React stack.

Personally, I've been focusing the majority of my "professional research time" in keeping up with the latter stack, and it's ended up paying off in the sense that it's almost trivial to spin up a new project at this point.

> Every tool seems to be broken into 200 different parts that subsequently have to be reassembled in order to implement a working pipeline.

I agree that this can be frustrating. Setting up a new Webpack/Babel/React project does tend to involve installing a bunch of different plugins, presets, and loaders. The way I learned this stuff it was by focusing on one thing at a time: set Webpack up to bundle my Javascript modules. Okay, cool, I fully understand that thing. Okay, now let's add Babel, with the ES6 preset. Alright, rad- now what about CSS?

> But as it has developed as an application platform, it feels more and more like I am fighting the tools, rather than having them help me. That's not a nice feeling.

I absolutely promise that I'm being earnest, NOT snarky, when I say that it sounds like you need to learn the tools more thoroughly. Personally, I tend to forget how much of a pain it was to learn other ecosystems, and so I sometimes get frustrated because it feels like learning a new ecosystem should be easy. And, yes, other ecosystems definitely have an easier learning curve. That said, I'm right there with you when it comes to testing frameworks. Oh god, testing frameworks. -_-;

A major part of the problem, I think, is that the current Javascript ecosystems spend a lot of time optimizing their tutorials and documentation for newbies and junior developers. I'll admit that I think it's a categorically Good Thing to have that, but many's the time I've wished for intermediate-level docs. The absolute best examples of this, in my opinion, are the Rails guides, the Rails API documentation, and the Elixir documentation (all of it).

> I was overall quite pleased with how easy and more importantly how obvious everything was. I found this to be the same when I wrote applications in Qt, and also when starting to work with newer languages (like Go).

Can you go into a little more detail on this? I'm genuinely interested in the details of what these languages got right.

I'm not going from backend to frontend or desktop apps. I'm going backend to backend.

I guess part of my point is I'm made uncomfortable by the encroachment of Javascript into areas where it's not particularly well suited, and the historical baggage it must carry into those areas. It's the when you have Javascript as a hammer, everything looks like a nail issue. I don't think my organization is unique in its embrace of Javascript-everything, either.

> Application development is hard, and is still far from "solved".

I'm surprised you feel that way; I always find it nice to do plain 'ol desktop development because it does feel solved. Everything is clean, quick, and heavily documented. Much of the languages, frameworks, and libraries have been around for decades.

I actually thing is the other way around... App Development is solved (unless you want to run the same codebase on multiple OS) but Web Development is a mess now that JS devs are trying hard to put themselves in every layer of the app from the networking layer to the data layer, throwing out the window years of good practices.

> making asynchronous code read synchronously in situations where asynchronous code provides no benefit

It's analogous to how everybody jumped to document-based databases a few years ago and gradually developed an RDBMS-like schema system enforced only by coding conventions.

> There is an interesting amount of energy put into making asynchronous code read synchronously in situations where asynchronous code provides no benefit.

I see many new / intermediate people trying to do this. They want to make everything asynchronous when it does make sense to. You want asynchronous when you're accessing an external resources or for something low running (in which case yields / multiple asynchronous calls are necessary to free up the thread for GUI rendering if we're talking web browser here).

I do not like the new async / await syntax. Some days I think I'm alone in this but synchronous and asynchronous are two very different use cases and I think allowing both to be represented the same way can be highly confusing.

> The dependency tree of any one project tends to be incomprehensibly sprawling

This is entirely developers faults. NPM gives you A TON of rope to hang yourself with and every project I jump into people use libraries without considering to their dependencies and end up with a tree of over 3,000 dependencies. It's absolute madness!

> Runtime version numbering is... weird

Semantic versioning has been around for quite some time. I used it when I did Java and C# development; is it really that weird? Is there something about it that's weird?

> Don't even get me started on the interplay of Gulp, Grunt, Webpack and NPM.

NPM is kinda necessary for dependency resolution but beyond that gulp, grunt and webpack are all replaceable with simple scripts. It's actually one of the best and worst things about the JavaScript ecosystem: you can make your build work and behave in any way you want but you have to write the code or learn one of many build systems to do this. In other spaces, like Java, you typically just have ant and mavin and no one bothers with anything else.

> Semantic versioning has been around for quite some time. I used it when I did Java and C# development; is it really that weird? Is there something about it that's weird?

I'm talking about the various schisms that have led to this page: https://nodejs.org/en/download/releases/

It's not a big deal once you familiarize yourself with what everything means, it's just a good example of some ecosystem baggage.

The ubiquity of using babel to get future language features also obscures the relevance of any one version of the runtime.

Oh yeah io.js really, really hurt the entire ecosystem in my opinion. The versions were confusing, npm was being used as the package manager for both without a good way to target either one specifically and io.js was introducing breaking changes. It was absolute insanity.

The problem with frontend is that making code synchronous blocks the client—even if it's something that "should be" synchronous. If it's anything more complex than a loop or a map through an array, it's recommended you make it async.

Making something asynchronous doesn't do anything magical to unblock the client; a long running asynchronous call that's not accessing an external resource will block the client just as much with the only differencing being the scheduler gets freed up just before running the asynchronous code. If you have something long running you need to use a generator yield pattern (process in pieces with ES5). I addressed this in my initial comment.

Just wondering about that stackoverflow question... I don't understand what that has to do with scoping - what is the nice way this would be done in other languages?

There are those of us that have known this to be true for a while and are moving (or trying to convince our employers to move) to alternative languages that compile to JS. Clojurescript, Elm etc.

Give Dart a try.

It has a single dependency management tool (pub), support for Angular 2, and is generally a joy to use.

Material widgets for Angular 2 (the same ones Google uses internally to build Adwords) are expected to be announced at the Dart summit in October.

Gotta say its pretty awesome! I can do a whole fully functional web app in about a 80kbs JS library(including embedded HTML for fast loading of different views).

The sweet thing about Dart is you don't need libraries like Angular or JQuery. I just use the built in Dart HTML methods and they compile down to vanilla JS.

JSON support is awful, "optional types" means "no types". Thanks, but even TS is better.

Enable strong mode. It's pretty neat - https://github.com/dart-lang/dev_compiler/blob/master/doc/ST...

> "optional types" means "no types"

While it is possible to write Dart code without using types (hence "optional") - the vast majority of Dart code is written using types.

The new Dart compiler also provides a "strong mode" which enforces strong typing in order to generate cleaner Javascript code.

Correct me if I'm wrong, but I thought that the majority of the Adwords frontend is still written in GWT?

It appears that the new version of the new AdWords UI is created using Dart and Angular 2: http://news.dartlang.org/2016/03/the-new-adwords-ui-uses-dar...

I'm not a heavy AdWords user, so I can't say for certain that this represents all of the AdWords UI. But based on the linked interview, it sounds like they replaced a lot of GWT with Angular.

The new Adwords is built with Dart.

Source: http://news.dartlang.org/2016/03/the-new-adwords-ui-uses-dar...

I see a lot of beauty in the js ecosystem, but only insomuch as related technologies come together to produce platform-independent, user-facing components. Similarly, I find C# or Java and their related technologies to be more beautiful on the server. Of course, one downside to this opinion is the requirement for skill in multiple ecosystems--and perhaps your employer had sought to consolidate these skills with js across the board.

If you haven't seen it, you might find this entertaining: https://www.youtube.com/watch?v=bzkRVzciAZg

I really wish gar1t would make some new videos, I love them.

Excellent! someone in this world has their head screwed on right!

(you're getting downvoted unfairly I think, probably a bit politically incorrect in this neighbourhood).

I don't care about downvotes, I thought that video was hilarious and enjoy sharing it. He's the same guy behind "MongoDB is web scale" and "Erlang the Movie II", which I'd also highly recommend:

http://www.mongodb-is-web-scale.com/

https://www.youtube.com/watch?v=rRbY3TMUcgQ

The Web has been a very popular development platform for a long time, but that time has been characterized by intense competition between browsers. It's a bit different from most platforms which are clearly dominated and guided by a single player.

So it's a bit more of a "wild west" and it does represent wasted productivity if you look at it that way. You can also see it in a more positive light as a tradition of taking ownership of the tooling and continuously improving it. Because there's no central authority setting a course for the future, progress is through competition among solutions developed by the community.

Yes, it's awful - and you're making a huge mistake by actually doing it yourself. There are plenty of people that love this stuff, as unfathomable as that is. Why not let them do it?

This year's "Used it before, would use again" is next year's "Used it before, would not use again".

So interesting I am still looking at it.

Suggestion: Add an optional section on how the developer learned the technology

I think you could do a really interesting meta-analysis where you could see a relationship between the way things were learned and the popularity of the tool.

It would also be a great resource for people looking to learn a technology and want pointers on where to start.

Great job on the interactive presentation.

Author here, thanks!

I agree; it looks really nice!

Minor nit: would you be open to using colorblind friendly color choices in the future? The current colors are pretty hard for me to differentiate between.

Really sorry about that! I'll keep it in mind next time.

Some interesting things on the "Front End Frameworks" page:

* 53% of the respondents used React, and would do so again.

* 47% use "No framework", and would do so again.

(hmm. that doesn't leave much room, unless you can use more than one tool depending on the situation)

* 43% had "no interest" in Angular 2.

One other thing to consider, of the "had used X, would/would-not use again" responses: there is of course a lot of selection bias of whether or not to even try X in the first place.

...

My only experience with these so far is Angular 1. It's easy to get started with, but does get messy when you have a very large form (think "government work"). I don't have a "React" axe to grind, I'm just looking at the numbers.

However, by the time I have to haul in Typescript transpiling, much of the appeal of Angular 1 is lost :-(

(it feels like GWT, all over again, at least to some extent)

The way I read it is that each question is independent.

So I can say I've used Angular and would never use it again while also saying I've used React and would use it again.

This is really a pretty decisively positive stat for React. Very few of its users would never use it again, while a lot of people have tried Angular and abandoned it. (This certainly matches my experience and anecdotes I've heard in the community.)

> The way I read it is that each question is independent.

Mine as well. I have two active work projects -- one is React, and one is plain Javascript. The latter is to keep the project extremely lean (mobile form single time use type thing) and I've enjoyed using no libraries in it (yet). So I would have responded positively to both of those questions.

I know. I was joking about a coincidence, as well as pointing out some of the largest response groups. The "tried X and would do it again" add up to over 100%, so some people had more than one tool for favored for different situations (or at least tolerated employer specified selections)

That said, it looks like React is doing well, and I bet on the wrong horse :-(

For the record, you don't need to use Typescript for Angular 2, you can just use regular JS (or Dart for that matter). The documentation is definitely biased toward Typescript at the moment, but I anticipate the situation improving as the framework matures.

I used it (ng2) across 3 versions (beta 3-5 iirc), I used the flow type transformer via babel, which worked well enough. It'd be VERY difficult to do without some transpilation that allows the directive-style to be used.

For me, a lot of things in the templating seemed goofy, and had horrible, or no error messages when they didn't work right... I also still don't care for the DI system, though it's definitely a leap from ng1, I'd still prefer React over ng1 or ng2.

That's technically true, but realistically false.

Just like people used to say that you don't need to use JSX to write React.

What's the point of using a heavy duty, opinionated framework without embracing it completely? that's just bound to get you into a whole lot of hurt.

JSX and React's a little different though, because its downright easy to use without. I prefer JSX, but typing div(null, { style: 'foo' }) isn't much harder than <div style="foo" />, if a little uglier.

And then you have tons of libraries to make it nicer.

You broke my hope to start using React. JSX smells too much for me. But thanks for the info, anyway.

I'd like to dive into React sometime when I get a side project that needs web development but I am a simple guy and I need a "hey stupid follow these conventions" setup in order to learn and grow and be productive.

There are a couple projects out there that do this but they're new. The WalmartLabs Electrode project looks incredibly slick and has good documentation so maybe I'll spend an hour or two with it this upcoming weekend.

From my experience this one seems like the best bet, being somewhat endorsed by Facebook. It's zero config too which is infinitely nice when you're just getting started https://github.com/facebookincubator/create-react-app.

> (hmm. that doesn't leave much room, unless you can use more than one tool depending on the situation)

Or: There are projects that they would use React for AND projects (presumably different) that they would use no framework for.

What is meant by "Real-Time Operations"(http://stateofjs.com/2016/features/)? The description could not be more vague and Google does not know either.

I assumed they meant something like websockets or server sent events when I took the survey.

I like the stats on the home page. A 53% response rate seems really good.

Is it me, or is 89 questions a lot of questions? I wonder if the number of questions cuts down on the response rate.

edit: I assume it does, but what is the tipping point?

I would think that next year, maybe staging into 3-4 different surveys may be a better idea... a month apart even... that way there isn't the drop off on a single survey.

I really do appreciate the format though.

213 people put "never heard of it" for plain javascript

Thats a surveyor because it sounds like an actual javascript flavor. CoffeScript, Plain Javascript, TypeScript are all flavors.

According to the survey, 213 people that took it have never head of plain javascript.

To be fair, a side effect of JS Fatigue is the inability to tell whether "Plain JavaScript" is the newest kid on the block or if it really means "good old JavaScript (ES3)".

Especially when the headline is "JavaScript Flavors".

Exactly, I've seen discussions about vanilla-js.com suggesting that people thought it was a real framework.

Poe's Law, maybe?

Good observation.

One possible explanation is they are not sure about what that means.

As an example, to me that sounds like the Javascript used in the browser. Is that the same as the Javascript I get from NodeJS? Which is "plain javascript"?

I think it represents semantic confusion and not experience. But that is just a guess.

PlainJS -- the hot new javascript dialect that transpiles Javascript 1.1 to ES6 so that your coworkers don't have to know that you don't know how the fuck Array.each works.

I thought they were being sarcastic.

I love Meteor and hope that it continues to grow!

I've been using it since well before v1.0 and can understand peoples frustration around it. A lot of patterns and core themes have come and gone. Allow/deny, blaze, and now it is sounding more and more like mini-mongo might go the way of Blaze in lieu of Apollo.

Like I said though, I really do hope that the core values of Meteor stick around in the framework and it continues to grow. I love it :)

"It would also be a great resource for people looking to learn a technology and want pointers on where to start."

Second that comment.

It strikes me as a brilliant that open-source programming languages should have these sorts of statistics. I wish I could see every OSS language reported like this...hmmm. I would replace the stock market ticker in my phone with that!

Noticed that under build tools, JSPM wasn't mentioned. Is it no longer popular? I've had a ok experience using it and systemjs been pretty good so far to get es6 module support and typescript working. I guess JSPM wouldn't fit quite in the build tool category but I see no dependency management section.

JSPM never picked up. Its call to fame was that it was more "future proof" using standards that were not actually standard, and had a pretty bad take on pre-building vs building in the browser and stuff. It was slow (and the ways to make it fast were very clunky) and generally, tools focusing on node/NPM entirely ended up winning out.

It was never popular.

Anyone feel like piping in why Aurelia? It pops out in the data, but unknown is satisfaction, etc.

My first entry into the SPA world was Aurelia about 10 months ago. So my experience is colored from having to learn a whole bunch of new things - gulp, SystemJS/JSPM, npm, the "terminology" of SPAs, fighting Typescript declaration file issues, incomplete libraries like Validation, etc..

The Aurelia community on Gitter is outstanding. Just really helpful and friendly. I would have been in big trouble without them.

I had actually done research on React, Angular 2 (still in Alpha), and Aurelia before I started the SPA. React seemed to weird and foreign to me a the time, and not enough of the community seemed to want to do React in Typescript which I had settled on as my front-end language. Probably the only reason I chose Aurelia over Angular 2 at the time was because it was painful to do dynamic, data-driven, components with Angular 2 at the time.

Aurelia is probably the best of breed in the Model-ViewModel world. It's post 1.0 now. That said, I've just finished my second app in React, and my third app is going to be in React too. I just find composing UIs in React to be much more natural because you're using JavaScript instead of stringy expressions in attributes to say generate list items.

The lead developer was involved with angular 2, and basically left to develop Aurelia because he did not agree with the way angular 2 eventually went with.

Mostly it's a different take on the next step for Angular that many Angularists that are unhappy with how angular 2 turned out are putting hopes in.

I also wrote my first SPA in Aurelia this year. As an introduction to the Javascript world, it has been pretty good (though I would never use JSPM again). Bugs are fixed in a timely fashion, the developers are responsive, and overall my developer experience has been positive.

I hear you, but now they're starting to make it possible to get away from JSPM. I recently ported my "old" Aurelia app to the new Aurelia CLI version and it's great!

For me, the beauty of JS was in its simplicity - there were wacky edge cases for sure, but here was a C-like language that you could use to build a project that almost anyone could understand. When Node first came out I was over the moon - wow, I can run processes on the machine from JavaScript?! Unreal.

It seems like I'm constantly keeping up with the complexity of the ecosystem, which is taking a toll on my productivity. This is probably my problem more than any specific failing of the evolution of the language, but, I like to ship.

Just my 2 cents to the discussion.

A "C-like language" is a very dubious compliment. Fortunately, JS is built around a different core. Unfortunately, it's built as haphazardly as C has been.

What I mean is that its syntax is classical. Its constructs will be very familiar to those who have taken basic education in modern programming.

As far as your 'different core' argument I'm not too sure what you mean. If you're a Node dev, then JS is just your means of calling OS routines and giving work to threads (in C under the hood, to be sure). If you're a front end person, then JS is a very high level layer again, making calls various OS services, probably in C++ or C.

I'm pretty sure the "core" reference refers to the "FP with OOP" core based on Scheme and Self, which is one of the best things about the (JS) language.

Alas, "The Management" demanded that it be dressed up to look like Java (and thus like C++). This led to a bunch of people that were unhappy that Javascript was in fact NOT like Java when they tried to use it like Java.

It's a very nice dynamic FP language, but people keep wanting to do static OOP with it :-(

I don't get this. You are not forced to use ES6 features or ReactJS if you don't want to.

Just like you can use vanilla PHP, should you desire.

After trying out Vue.js, I am pretty sure I will never go back to React.

Never say never. Thats what I thought when I first used Backbone

This makes Firebase look wildly popular. But can you even use Firebase for an app where you don't trust every user to maintain your denormalized indexes properly?

I asked this question on Stack Overflow to not much response: http://stackoverflow.com/questions/39800531/collaborating-wi...

I really liked the "features" section. I've seen some weird things done in the wild to obtain some of these features. Like building a multi-SPA to obtain code-splitting where a site is split up into multiple pages each acting as their own SPA. But it does seem like things are settling down. Envious of all the people starting now. As someone who started web dev in 2010, anything I learned that was framework-specific then, is almost completely obsolete now lol.

I am going to mention our framework, since I think it's relevant, but it's not just a JS framework. It's a fully integrated platform:

http://qbix.com/platform

http://qbix.com/platform/features

Would like to get some feedback on it, from anyone who looks through the features.

Its a great and useful survey. But would have liked to see a question(if not a complete section) on search engine optimization(SEO). Most important thing for internet apps.

For enterprise apps it doesn't matter and for that you can safely use a framework like React. But its very crucial for Internet apps. Surprisingly, Google neglected building tools in that area, apart from guidelines via its webmaster blogs.

"the thing that stands out right away is how the React row just lights up compared to the other front-end frameworks. In other words, React users are more likely than average to have experimented with multiple other technologies."

I believe the data wrongly indicates this because React, Redux and Webpack are used together to achieve things that both Angular 2 and Ember solve similarly internally.

true, but i think even a lot of the other non-coupled technologies have higher numbers, but it's hard to say if that's higher percentages

Nice article. I started a new hobby Rails project a couple of months ago and was a little surprised to see that even Rails 5 still defaults to Coffeescript. Googled around a bit and decided to drop it, as it seems to be more or less abandoned these days, which this survey seems to confirm. I wonder if/when Rails will switch to ES6 or something?

CoffeeScript was designed by and for Rubyists, so it makes sense that they'd be the last to drop it.

I don't have time to go into details at the moment, but I'm using, loving and recommending Mithril.

Why are ES6 and JavaScript treated separately in this survey?

I thought ES6 is just a new version of JavaScript (the ECMAScript standard)? I thought both are written using the same HTML <script> tag. Why is it necessary to consider ES6 different from JavaScript in this survey?

Could you please throw some light on this?

Why shouldn't it? You still need to transpile ES6 to ES5

Thanks for the answer. I was not doubting the survey methodology or results. My question was simply out of curiosity.

I would like to request more details on your answer.

1. What kind of ES6 requires transpiling to ES5. I mean, I once tried using Promise and something like Promise.resolve("foo") works just fine. Are there any ES6 constructs that would require transpiling, to work fine on, say, Chrome or Firefox?

2. Is ES6 not completely backward compatible with ES5? If yes, I would consider ES6 as the same (although upgraded version of) language as ES5. If no (e.g. Python 2 vs. Python 3), then it would be justified to consider ES6 to be different from ES5. What's your opinion?

Disclaimer: I am not a JavaScript developer. I am a system programmer. But I do a little bit of web-designing once in a while, for example, to maintain my blog etc. That's why I would like to understand why ES6 is considered a different language than ES5.

Here's a little bit for you. Most people prefer the semantics of `let` to `var` for variable declarations in JavaScript. It's how JavaScript should have been designed from the start. It has been officially standard for a year or two and became available in some browsers even earlier.

I want to use `let` (and `const`) for everything and never use `var` again, but I couldn't even do that on my own PRIVATE website (for me alone) until today, because I didn't upgrade my iPhone to iOS 10 until last night, and iOS Safari never supported `let` (or arrow functions or so many other things) before v10 (and Apple won't allow anyone to break their browser monopoly on their platform).

I could just use Android, but I can't switch everyone else to Android, and LOTS of Android and Windows (and even Mac) users are stuck with even older browsers, because they don't know how to (or can't) upgrade.

Are there any ES6 constructs that would require transpiling, to work fine on, say, Chrome or Firefox?

Not on the latest Chrome or Firefox, but that hardly matters in a world where so many people aren't using the latest Chrome or Firefox. The question for a developer is not whether some in their market can run their software but whether some CAN'T.

Is ES6 not completely backward compatible with ES5?

It is (in practice) completely backward compatible, but I suspect you are a little confused about what that means. It doesn't mean "forward compatible". Backward compatible means that a new ES6 browser is still compatible with old ES5 code, which it is. Old ES5 code will keep working. It does NOT mean that my new ES6 code, full of `let` and arrow functions will run in an old ES5-only browser, and there are still plenty of them out there.

As long as you choose to target a market that includes ES5-only browsers (and you may or may not, but if you do), the things that are new in ES6 (Google "what's new in ES6") have to be transpiled to ES5 to run in ES5-only browsers.

Why no section on server-side frameworks? I for one picked Hapi over Express a couple years ago and have been very happy with the switch. I'd love to know what has changed since then!

I would respect the JavaScript so much more if there wasn't so much faddishness - somehow JS devs have decided switch statements are bad, indenting with 2 spaces is the only way to go, semi-colons should be banished and "boilerplate" code should be hidden in libraries the magically wipe it away so your code looks "clean," if barely understandable without reading through a bunch of libs.

Edit: forgot to add that these are my initial impressions after diving into front end development with node and browserify. I ended up avoiding a lot of pain by just using TypeScript and a make file. Who has time to wade through umpteen million build systems?

> somehow JS devs have decided switch statements are bad

Nonsense. Though sometimes using an object can look cleaner depending on your use case.

> indenting with 2 spaces is the only way to go

I love 4 spaces and I use 4 in my JavaScript projects. Just because you've seen some subset of people use 2 doesn't mean it's the majority, what you have to use, etc.

> semi-colons should be banished

Absolutely, positively NO. Semi-colons are a requirement of the language. Some people elide them, incorrectly, because the JavaScript engines are good enough to still handle it. In my experience being playing a limited part in open source JavaScript eliding the semi colon seems to be a rarely done practice.

Regardless it's incorrect no matter how you slice it.

> "boilerplate" code should be hidden in libraries the magically wipe it away so your code looks "clean,"

This sounds more like a rails-ism than a JavaScript-ism. Though you'd be hard pressed to find libraries without implicit behaviors in every language. Some people take DRY way too far.

This point just seems more anecdotal than anything else.

> a make file. Who has time to wade through umpteen million build systems?

A lot of JavaScript devs use make. Nothing wrong with that.

I think the semicolon requirement is more for broken minifiers than actually making the unpacked code clear/correct. But that's just me, I guess, as I have worked with many line oriented languages, and have no reverence for C syntax.

I'm heartened by your comment. I'm glad to be wrong on this.

> somehow JS devs have decided switch statements are bad

huh. You obviously haven't played with Redux yet, it's basically switch statements all they way.

The JS community is the biggest programming community in the world, there is no way you can lump anything on the community as a whole.

Redux is a wonderful piece of software and of course I use switch statements. I was referring to this question on reddit/r/javascript which kind of boggled my mind. I didn't know there were people advocating against switch statements.

https://www.reddit.com/r/javascript/comments/2582qv/is_switc...

Did you link the wrong page? It looks like they are advocating switch statements.

Indeed, I've never seen anyone use anything but switch statements in Redux reducer functions.

C and its descendants does have a somewhat "broken" case statement. Pascal's was much less error prone.

Putting in semicolons won't make the language NOT terminate a statement if you split a line in the wrong spot. (I suppose one solution would be just to put everything on one giant line, and separate the statements with semis, but, YUCK)

Repetitive boilerplate should indeed be pushed down a level or two in any language, so the top of your program reads in terms of the business logic / problem space, not a bunch of code management noise. This is less traumatic if your functions have actual documentation for an IDE to display when a symbol is clicked on, rather than buying into the "self documenting" fairy tale.

However, 2 spaces per level isn't visually very much. I don't need to nest things so deeply that I begrudge a few spaces per level.

- - - -

Static OOP was the shizzle back in the 80s (when we were learning about clones, often bad clones, of Simula 67). The last 10 years or so, though, I have really started to appreciate much (if not all) of what Lisp offered back in the day. Javascript is an acceptable Lisp.

Nice design.

When I finally ended on the IDE page, I realized how the vast majority of these "5-10"+ year veterans were very primitive developers. If you're using Sublime or Atom for Javascript development, I would say that you've spent too long working in and around these ever-changing tools without a useful IDE.

I'm happy coding in WordPad, GEdit, etc, and use Sublime today.

My view is that if you need an IDE to maintain your code effectively; if your volume of edits is such that macros and navigation tricks make a meaningful impact on your pace of development, then your code probably has serious architectural problems¹.

You see all impediments to action as debilitating, but I think impediments, carefully curated, can provide useful constraints on my development process. Friction helps me see where my interfaces are getting strained.

¹ I feel bad writing this because I know, if I step back from my own preferences, that your approach to development probably works great too. But your claim was so insulting, I'll leave this as is to match your tenor.

More info about the participants would be nice. How where they chosen ?

Side note: The web design reminds me of the late 1990s... funny how it comes around.

ES6, CoffeeScript, and TypeScript all have near-perfect awareness, which surprised me since TypeScript isn’t quite as popular as the other two yet.

I take issue with that statement. Just anecdotal, but I think these days Typescript is much more "popular" than CoffeeScript

Awareness just means "have heard of it". 99% have heard of Coffeescript but 14% want to use it in the future. 98% have heard of Typescript but 60% want to use it in the future.

Anecdotally, CS appears to have lost quite a bit of popularity while TS gained some.

RedMonk seems to confirm these trends. TS grows while CS stagnates:

Q1 2016: http://sogrady-media.redmonk.com/sogrady/files/2016/02/lang-...

Q3 2016: http://sogrady-media.redmonk.com/sogrady/files/2016/07/lang....

Ts seems awesome but it looked like kind of a pain with separate ts and js files, mandatory type definitions not being present for lots of dependencies, and back when I looked at it seeming pretty all or nothing. I like flow. The people that built ts are brilliant too though. Curious if anyone has a good comparison between flow and ts. I've heard ts has improved a lot lately.

> mandatory type definitions not being present for lots of dependencies

That is the biggest detriment to typescript in my book. I played around with it for a bit but finding accurate (and up to date!) type definitions for external dependencies was a huge pain.

The survey also comments "few developers have used CoffeeScript, and apparently almost nobody wants to learn it" and concludes with "Some technologies [...] proved to be on their way out (CoffeeScript)."

Hopefully DHH recognizes this and deprecates CS out of Rails.

It's got the Microsoft Seal of Approval(TM)!

Yeah, doesn't mean much to me, but it does guarantee you can get tools that are compatible with it.

Not surprising. If you've ever had to work with CoffeeScript in a large code base with multiple developers, it's . . . not ideal. I can't stand it, personally.

This seems to suggest the rate of framework churn has rather settled down. Are JS devs finally starting to be satisfied with their current tools and not needing to restart every 18 months?

I see this same, tired old meme in every thread about web technologies.

It's funny to me that certain people are so disdainful of the churn in web development on a forum dedicated to "hackers". Web application development is hard, and the reason why there's so much churn is because smart, inventive people are constantly finding better ways to do things. Things aren't just resetting from scratch every 18 months. The web apps I'm working on today are way more modular, composable, testable, and maintainable than the ones I was writing as little as two or three years ago. Just because Java systems development hasn't changed significantly in the last 5 years doesn't mean Java devs are any more or less reasonable developers than web folks.

> "... the reason why there's so much churn is because smart, inventive people are constantly finding better ways to do things."

It also follows that at some point, these smart, inventive people will come up with fairly stable frameworks that are sufficiently flexible and powerful to accommodate most of the problem space out there. It is reasonable to ask if such a point has been reached...

Depends on the space.. for example, Express has been pretty stable.. Angular 1.x has been as stable as anything else for the most part... Node's mostly been progressive additions, and features from engine updates since 0.10... npm has been pretty stable since node 0.10, though there's been significant advancements since npm 3 came out.

Browserify -> Webpack has been noisy. Babel 5 -> 6 equally noisy, but better for moving forward

Today, I think webpack, babel, react, redux and fetch cover a LOT of ground for client-side dev. There's a few other bits around that, and I think CSS tooling is starting the a similar shakeup to node's tooling options.

In the end, almost all the JS features I care about seem to be at stage-3 now, so who knows when they'll be in the major browsers.

JavaScript has been around since the 90's; a quick scan of this page reveals around 2 dozen JavaScript technologies. The only solution is to remove JavaScript from all browsers and replace it with Java.

> The web apps I'm working on today are way more modular, composable, testable, and maintainable than the ones I was writing as little as two or three years ago.

The better question is: are the apps someone with two or three fewer years of experience than you more modular, etc?

My experience is on the backend rather than the frontend, but in that domain, at least, system quality is still way more about developer maturity than ecosystem maturity. You can figure out a terrible, hard-to-maintain lazy way of solving today's immediate problems in any language.

I think the problem was the hard-to-maintain lazy way was usually the most obvious. There was so much momentum behind the quick-and-dirty imperative DOM approach that it was hard to do anything else. For example, you could totally use Backbone to construct modular, refactorable views -- but in practice everything would devolve into DOM-munging event-driven spaghetti.

I agree that a lot of the churn is each generation (a generation here seeming to be about a year) of tools learning from and building upon the former. Obviously the churn is continuing since developers realize that the tools are quite "there" yet. My hope is that some year we will finally reach "there" (not perfection, but highly good enough) and the churn will slow down to the point that perhaps the generation time period will stretch out to five years or so.

Well, most of the features I care about in JS are in stage 3 now. Webpack 2 will get the tree shaking, and babel seems ready to work with both. It think the CSS options are next in line to see some shakeup... I've been liking what I'm seeing from JSS, though I still use mostly sass at work.

What is your current recommended or dream stack?

Currently my go-to is: React, Redux, Typescript, CSS Modules (optionally with Less) built/managed via npm and Webpack. The real beauty is that everything is well-encapsulated. If I decide one component absolutely needs to use jQuery for some reason there's nothing stopping me as long as the top-level API is still React.

> Web application development is hard

Replace JavaScript with Java in all browsers and make it much easier, dependable, predictable and reliable.

Well yeah, that'd be great. But the unfortunate reality is Javascript is the lingua franca of the web and we have to make due until there's a reasonable alternative.

Furthmore, it's not even JS that's really the problem. It's the entire JS/DOM/CSS stack.

I don't think the churn has really settled down, what makes you think that? The idea that framework lifespan only lasts 6 months was always exaggerated.

Some forms of "churn" are also called "progress". Is the current crop somehow better than the previous?

It's not so much that churn has been greatly reduced, but that the worst churn has started to be centralised and hidden behind tools like `create-react-app`.

There will still be more churn as people come up with ways to be more productive, however it will be hopefully concentrated in areas other than build process tooling.

You're spinning this as a positive thing, but the fact that a UI library needs its own build tool does not speak well to the state of front-end development.

Specifically the fact that we still don't have modules or widely-deployed http2 is what makes the build tool complexity necessary.

I wouldn't say that was spin, I said that build complexity is likely going to be handled by fewer engineers. The underlying problem still exists but less people need to put their oar in: that's bittersweet.

I remember building Windows ui apps 10-15 years ago, and that definitely needed a build tool. Http2 might be great for module loading, so things don't have to be bundled, but there's lots of unsupported use cases right? Css encapsulation, autoprefixing, hot reloading for dev, compiling features not yet in browsers into js versions supporters by browsers etc.

Great report.

I'm very satisfied with Clojurescript.

Bit weird that the "Web Framework" section didn't have any Clojurescript libs at all considering it was on the list, heh. Re-frame, Om... Mobx looks pretty based on reagent, heh

Never heard of the survey maybe the data is biased to only approach people on the silicon valley where technologies are used as if they were current season premium fashion cloths.

9k responses certainly weren't from SV alone. I know alot of the Spacedojo Slack channel took the survey and I think like 2 out of 300 live in SV.

Would be fun to maybe turn ip addresses into lat/long and map out where the responses came from...

exactly this is my point, maybe the data is biased to US developers mostly

(Thin sans-serif grey body text means you hate your readers.)

-----

edit: I've tried to read it now and this site is crappy as hell. Does anyone have a link to a coherent write-up of these results?

-----

Furthermore, I know it's bad form to mention your own downvotes but I dare you I DARE YOU to make a case for that horrible font choice. You can't because it's pure vanity. Style over substance. Thhhpppppt!

Reply on news.ycombinator.com