The State of JavaScript – Survey results

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.

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.

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

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

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

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

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.

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.