Live data from Hacker News

The State of JavaScript – Survey results

stateofjs.com

291–300 of 357 posts

Re: The State of JavaScript – Survey results

#291

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 featur…

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

Re: The State of JavaScript – Survey results

#292
Why are ES6 and JavaScript treated separately in this survey?

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

Could you please throw some light on this?

Re: The State of JavaScript – Survey results

#293

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 featur…

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'r…

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.

Re: The State of JavaScript – Survey results

#294
post #292

Why are ES6 and JavaScript treated separately in this survey? I thought ES6 is just a new version of JavaScript (the ECMAScript standard)? I thought both are written using the same HTML tag. Why is it necessary to consider ES6 different from JavaScript in this survey? Could you please throw some light on this?

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

Re: The State of JavaScript – Survey results

#295
post #278

Earlier quoted context omitted.

> 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 naivel…

> 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 e…

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.

Re: The State of JavaScript – Survey results

#296

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 featur…

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

Re: The State of JavaScript – Survey results

#297
post #154

Earlier quoted context omitted.

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 p…

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…

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?

Re: The State of JavaScript – Survey results

#298
post #292

Why are ES6 and JavaScript treated separately in this survey? I thought ES6 is just a new version of JavaScript (the ECMAScript standard)? I thought both are written using the same HTML tag. Why is it necessary to consider ES6 different from JavaScript in this survey? Could you please throw some light on this?

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

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

I would like to request more details on your answer.

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

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

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

Re: The State of JavaScript – Survey results

#299
post #210

Earlier quoted context omitted.

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 i…

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 eve…

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

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

Re: The State of JavaScript – Survey results

#300
post #295

Earlier quoted context omitted.

> 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 e…

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…

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.
Post reply on HN