Hacker News new | past | comments | ask | show | jobs | submit login
The State of JavaScript – Survey results (stateofjs.com)
546 points by ekianjo on Oct 3, 2016 | hide | past | web | favorite | 346 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.


It's also written in TypeScript, nice!

A few days ago I was thinking about using GraphQL in future projects and didn't even find out about Apollo.

So it combines data retrieval via GraphQL with client side state management via Redux?


That's exactly right. We're working on refactoring it as well so that it can be used outside of Redux, here is one of the resulting projects: https://github.com/apollostack/graphql-anywhere


you just stole my heart :)


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.


I suppose you have a class of data that is not trivial enough to store in a single component's state, but also not worth sending to the server. Personally, I'm happy to be rid of having to maintain this kind of state if I can.


> I suppose you have a class of data that is not trivial enough to store in a single component's state, but also not worth sending to the server.

Exactly. For example, one application I'm working on has a complicated multi-page form/wizard. Redux is great for keeping this manageable and in fact takes care of all the management for this without me also having to write code for managing it on the backend at all.


You mean Redux, right?


Yup! Edited.


Interesting. Till now I only used redux to store server-side info. Client-side stuff always went into the component state.


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?


If a project requires server-side rendering, I render it using React on a Node server. I don't use Django templates for anything these days.


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?


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


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.


https://github.com/redux-observable/redux-observable addresses your point b) and your point c) somewhat.


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


Mutable state is fundamentally harder to reason about. You get aliasing bugs, stale cached values, etc.

With immutable data in an append-only stream this is simply impossible.


I've done plenty of work with immutable data, and I tend to code in a way that minimizes the amount of state I have to manage.

I guess that's what I was saying about mobx though - I can have a much smaller set of core data and then pure functions for the layers of derived data. And it's a) easy to reason about and b) super performant at managing the calculations.

Aliasing bugs don't really apply in JS, unless there's some variation of the term? Stale caching is also not an issue with calculated derived data.


Saying about "aliasing bug" I meant something like this:

    var my_data = {"foo": null}

    function innocuous(input) {
      var data = {"one": input, "two": something()};
      data.input.foo = data.input.foo || "foo"  // set a default value
      // do something with data
    }

    var result = innocuous(my_data)

    // Oops, now my_data.foo has changed.


I'm saying its the right way to get rid of it, not that its right to get rid of it :)

MobX does really, really well in minimising the complexity of mutable state. Its the best there is out there.

Where MobX does worse is when there is more complexity then a simple direct map function to calculate derivations: debouncing key input, doing async requests, creating animated transitions, etc. Its a great model, but it needs some more work to be truly amazing.

The user does care about the past. For example if the state of the input box changed too many times during the last second, they don't want every change to cause a slowdown in response time due to too many requests being sent to the server, and they want only results from the last request they sent, not the last one that was processed.

I think the reverse criticism applies for cyclejs: while it can do everything thanks to RxJS, it needs a better component composition model. The current one is too tedious and alien for my taste. (For example, why isn't the same DOM selector syntax used for component-event selection?)


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.


> If you haven't mutated states, you don't have an interactive UI.

React allows you to treat DOM mutation as an expression of current app state.

This doesn't mean that your state itself has to mutate. It's entirely possible to structure a React (and/or Redux) app with fully immutable state, copies of which represent change. (Whether copies are done efficiently, e.g. via persistent data structure algorithms, or naively, e.g. via a deep clone, is secondary).

I'm befuddled where you're getting the impression that immutable data structures themselves require mutation.


> React allows you to treat DOM mutation as an expression of current app state.

Current app state. As in not past state. Not future state. There would be no need for the distinction if the state wasn't mutated.

> This doesn't mean that your state itself has to mutate. It's entirely possible to structure a React (and/or Redux) app with fully immutable state, copies of which represent change. (Whether copies are done efficiently, e.g. via persistent data structure algorithms, or naively, e.g. via a deep clone, is secondary).

You are confusing the mutability of a data structure with the mutability of state. You can model mutable state using immutable data structures, but it's mutable state regardless. In fact, that is exactly what the Redux/ImmutableJS model is. If the state of your "immutable" react app were really immutable, you would have a webpage, not an app.


The DOM can be mutated just fine behind the scenes by React to reflect whatever brand new state has been passed into it. That brand new state can be anything. It can be a single (by definition immutable) integer. It can be a deep clone of an object. This is the ideal intended Redux architecture. Redux reducer(s) receive the state and return either the state untouched, or a non-mutated copy of the state. React reacts accordingly by expressing this brand new state as (possible) DOM mutations.


That is mutable state. Your Redux store is a mutable state container. If your redux store returns a {a:1,b:2}, and then you dispatch an action and it now returns an {a:2,b:1}, then you have mutated your state. It doesn't matter at all if the store's data structures are mutated in place or replaced with a modified immutable updated copy of a previous state, you still have mutable state.


I think I see where you're coming from, but I also think you might be moving the target a bit. I suspect you'd garner less debate if you said, I dunno, just "a dynamic UI app needs a way to model state changes". "Mutate" has a specific meaning, in my mind at least, when discussing variables and data structures. React enables avoidance of direct DOM manipulation, Redux obviates direct state mutation.


Also, "finite state machine" has a very specific meaning, and that isn't just any machine that has a finite bunch of variables that you call state.

If React lets you execute arbitrary JavaScript code (which it does), then you're no longer using just a finite state machine, you're using a Turing machine, which is something different, and more powerful. It may have many finite state machines embedded in it, but to refer to a user interface as a finite state machine is like referring to a car as a pulley, just because the engine requires several pulleys to work, and ignoring all the rest of the engine and car. You can't make a car out of just pulleys, and you can't make a user interface out of just finite state machines.


React, as it is presented to the programmer and for all practical reasoning, is programming with finite state machines. Sure, javascript is Turing complete and capable of much more (behind the scenes in React there is plenty going on that does not qualify as FSMs), and within a react application or even a component you might use Turing complete semantics to describe actions, data structures, effects, or whatever...but constrained to the API and idioms of react it is perfectly acceptable to call it FSM programming. In fact, Facebook already says this about react, that UIs are state machines and react is a way to declaratively describe them that way.

A better analogy for the equivalence of Finite State Machines and User Interfaces is the equivalence of human arms and levers. Just because it is one doesn't mean it isn't the other. One is abstract and the other is concrete, but there is still an equivalence. And not just computer user interfaces either...you could take pretty much any real world user interface: analog, mechanical, digital, whatever. Hell, tubas and vending machines are finite state machines. They fit the definition of a finite state machine because they are.


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 didn't specify finite or infinite, and you're right that FSMs alone aren't sufficient to describe all UIs. But they are sufficient to describe nearly all interactive UIs.

Your infinite button example still has a finite state, but it's not modeled explicitly, and would probably be a good idea, for very practical reasons, to do so. If it really goes on forever, you'll eventually run out of memory, whether that memory is managed by the rendering engine (appending dom elements?) or by the language runtime.

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

A Hierarchical State Machine model covers this scenario quite nicely...which is exactly what React is.


Interesting. I hadn't heard of hierarchical state machines. Thanks for the reply.

If you don't consider the infinite button example, then what other kind of UI can not be described by a FSM?


I've certainly never found a common UI pattern that isn't describable with FSMs, but you could probably think of a few toy examples of non-terminating state. Anything involving recursion, exponential, or asymptotic behavior for example could theoretically involve infinite states. Again, likely of no practical use.


Read any real-world user interface specification like Apple's classic Macintosh Human Interface Guidelines [1]. It specifies all kinds of complex behaviors, like how pull-down submenus don't pop up immediately as you move the cursor over them, and how dragging and dropping text handles the white space at the beginning and end of the selection, or how adjusting the end of the selection in mixed right-to-left and left-to-right text works, which is much too complex and nuanced and ad-hoc hacky to describe with finite state machines, and require a Turing complete machine to implement.

Even if it were technically possible to restrict yourself to a FSM, you would end up going insane and producing exponentially explosive unmaintainable finite state spaghetti machines.

There's a huge uncanny gap between what you can elegantly describe with a clean mathematical abstraction like finite state machines, and what real human beings expect and perceive to be easy to use in a real world user interface.

The polish of a good user interface is the result of millions of tiny little scratches, and in practice that requires the power and flexibility of a Turing machine (and not one stuck in the Turing tarpit like Brainfuck) to make all of those tiny little scratches and cover all the edge cases and special circumstances, because finite state machines are just too clumsy and not powerful enough to conveniently cover that much ad-hoc messy fractal detail.

[1] http://interface.free.fr/Archives/Apple_HIGuidelines.pdf


I'm not sure an "infinite state machine" [1] is actually a "thing" the same way a "finite state machine" [2] is a precisely defined mathematical concept in Automata Theory [3]: one level of the classes of automata more powerful than combinational logic and less powerful than pushdown automata and Turing machines.

In my mind, there is no question that finite state machines alone are not powerful enough to define practical real world user interfaces, which require the power of a Turing machine. The fact that most user interfaces incorporate many finite state machines at different levels doesn't mean that finite state machines alone are sufficient.

That's why we program browsers with JavaScript, not FSMML or FSMON.

[1] http://c2.com/cgi/wiki?InfiniteStateMachine

[2] https://en.wikipedia.org/wiki/Finite-state_machine

[3] https://en.wikipedia.org/wiki/Automata_theory


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


Well everything that happens in a real computer is an FSM. There's a finite amount of memory and therefore a finite number of states.


That's playing fast and loose with the literal every-day definition of the words "finite", "state" and "machine".

There is actually something in computer science with a precise mathematical definition called a "finite state machine," [1] that is not simply any machine that has a finite number of states.

When you use that term, you're not just talking about what it can do, but also what it can't do, because "finite state machine" implies that it's just a finite state machine, not a pushdown automata, and not a Turing machine.

With a Turing machine, you can implement a finite state machine or a pushdown automata, but Turing machines and pushdown automata are more than just finite state machines.

That said, user interfaces typically use lots of finite state machines at different levels (hierarchical, and unrelated), but they also require more powerful machines like pushdown automata and Turing machines (for validating email addresses, for examples).

If all you had to program user interfaces were finite state machines, but no Turing machines, you would be a very frustrated programmer, and your users would be unhappy to have such a brittle inflexible user interface.

[1] https://en.wikipedia.org/wiki/Finite-state_machine


It's not playing fast and loose at all - at least not with the precise mathematical definition (perhaps it is playing fast and loose with the "literal every-day" definition which might mean a state machine with few enough states to fit on a whiteboard). A push down automata is defined as having infinite stack and a Turing machine is defined as having infinite tape. A finite stack push down automata permits an equivalent (much larger) finite state machine. A finite tape Turing machine also permits an equivalent (much much larger) finite state machine.

Leslie Lamport makes the same observation on page 4 here: http://research.microsoft.com/en-us/um/people/lamport/pubs/s...

The comment I replied to was "My experience shows it is a state machine, but I have not see any formal study of it." - I was simply replying "of course it's a state machine".

Lots of situations in GUIs can be modelled as quite compact state machines - but it depends on the level you model it at. If you need to model the state of a text box then your state machine will grow very large since you need a new state for every possible input string. Given modelling simplifications where we abstract away some parts with large state spaces by collapsing states, there are very few pieces of software which don't benefit from being modelled with state machines.

Personally I would be a very frustrated programmer and if I had to program user interfaces with Turing machines since writing a transition table would feel awfully low level and since the Turing machine model doesn't have any facilities for user interaction I'm not sure any users would be terribly happy with the result (so I'm not quite sure what you're trying to say here).


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.


C and C++ also use years. For example, C99 was standardized in 1999. C++11 was standardized in 2011.


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.


It's a good point, they are complex. But on a team doing a complex spa, you'd need someone who's a tooling expert right?


> But on a team doing a complex spa, you'd need someone who's a tooling expert right?

I would argue no. Granted not everyone needs to be an expert on the tool chain and this ends up happening probably a majority of the time anyway but if most are ignorant how the tool chain works I don't think that's a good position to be in either. When a bug / misconfiguration issue rears its ugly head you need more than a few people being able to debug it. But even outside of that I think it's incredibly helpful for the developer to fully understand how something is going to be built and deployed.


I agree with what you're saying. You don't want to get stuck in a corner. That's smart and pragmatic. Perhaps an expert that mentors the rest of the team? I just don't see how we can do without software build tools. They are so common in almost every language/platform I've used.


> I just don't see how we can do without software build tools. They are so common in almost every language/platform I've used.

All depends on your use case. Honestly if you're working on a web app you actually don't need any build tools if you really didn't want to.

But ultimately I wasn't advocating for zero build tools. The way JavaScript works you can write your own scripts (I wrote my own, barely one page of code for minifying, packing, versioning, testing, etc) or use any of the systems if you want to. It's all not that hard. But I don't think only one (or small handful) of people should know how to use them and I think we can vastly simplify what some of them do today (looking at you, babel and webpack).


I agree with you that writing build scripts and using build tools both are not very hard. Who finds them hard? I'm sure Babel and webpack could be improved. What would you propose for how to improve them? Thanks.


Ya that's true. I'd just really hate to ever see another 10,000 line jquery monstrosity ever again shudder lol.


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.


When using browser-sync, which parched-tasks-webapps does, CSS is already hot-reloaded, and there's no worry of configuring different "loaders" for the case of a javascript file on the server trying to require a CSS file.

In both cases, the page is loading an external stylesheet, so both are as susceptible to FOUCs as the other.

This is only my opinion, but using CSS loaders backs you into a corner where your javascript file is suddenly less portable, since the environment it will be running on needs to be aware of it.


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.



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


Love me some Erlang, er, "OTP".

I'm pretty sure the video would violate the "code of conduct" at our local JS user group, though.


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.


That's typical for people who didn't use React yet. In practice JSX is awesome.


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.


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: