Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The State of JavaScript – Survey results

stateofjs.com

Post reply on HN
Print view View original

181–190 of 357 posts

Re: The State of JavaScript – Survey results

#181

Post by OhSoHumble »

jordanlev wrote: post #173
OhSoHumble wrote: post #152

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…

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.

Re: The State of JavaScript – Survey results

#182

Post by saosebastiao »

rifung wrote: post #154
arxpoetica wrote: post #112

Earlier quoted context omitted.

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.

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

Re: The State of JavaScript – Survey results

#183

Post by zebraflask »

FrancoDiaz wrote: post #16

ES6, CoffeeScript, and TypeScript all have near-perfect awareness, which surprised me since TypeScript isn’t quite as popular as the other two yet. I take issue with that statement. Just anecdotal, but I think these days Typescript is much more "popular" than CoffeeScript

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

Re: The State of JavaScript – Survey results

#184

Post by labrador »

Forlien wrote: post #171
labrador wrote: post #161

Earlier quoted context omitted.

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

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

If you read down, there are people against them. I didn't know this was a thing. The top comment is saying of course, switch statements are fine. There are other posts if you search for switch in r/JavaScript. This one is probably more indicative:

https://www.reddit.com/r/javascript/comments/3a4ras/how_ofte...

Re: The State of JavaScript – Survey results

#185

Post by saosebastiao »

glenjamin wrote: post #155
darksaints wrote: post #72

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…

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

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

Re: The State of JavaScript – Survey results

#186

Post by indexerror »

darksaints wrote: post #72
aidos wrote: post #52

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

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…

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

Re: The State of JavaScript – Survey results

#187

Post by aidos »

glenjamin wrote: post #155
darksaints wrote: post #72

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…

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

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.

Re: The State of JavaScript – Survey results

#188

Post by saosebastiao »

arxpoetica wrote: post #112
darksaints wrote: post #72

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…

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.

Re: The State of JavaScript – Survey results

#189

Post by inputcoffee »

at-fates-hands wrote: post #142
inputcoffee wrote: post #44

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

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

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.

Re: The State of JavaScript – Survey results

#190

Post by smac8 »

easong wrote: post #67
aidos wrote: post #52

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

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…

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