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

281–290 of 357 posts

Re: The State of JavaScript – Survey results

#281

Post by shados »

Illniyar wrote: post #131
GnarlyWhale wrote: post #45

Earlier quoted context omitted.

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.

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 , if a little uglier.

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

Re: The State of JavaScript – Survey results

#282

Post by shados »

nkassis wrote: post #140

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

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

Re: The State of JavaScript – Survey results

#283

Post by ng12 »

davidjnelson wrote: post #247
ng12 wrote: post #100

Earlier quoted context omitted.

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

Nice! Why ts over flow?

Momentum, mostly. DT/typings/@types are surprisingly comprehensive and with 2.0 typescript supports strict null checks which was the biggest flaw in my opinion. I've also unfortunately become pretty familiar with some of the obtuse concepts in typescript (e.g. extending module definitions).

I'd love to give Flow a try -- just waiting for the right opportunity.

Re: The State of JavaScript – Survey results

#284

Post by davidjnelson »

ng12 wrote: post #283
davidjnelson wrote: post #247

Earlier quoted context omitted.

Nice! Why ts over flow?

Momentum, mostly. DT/typings/@types are surprisingly comprehensive and with 2.0 typescript supports strict null checks which was the biggest flaw in my opinion. I've also unfortunately become pretty familiar with some of the obtuse concepts in typescript (e.g. extending module definitions). I'd love to give Flow a try -- just waiting for the right opportunity.

Awesome, glad to hear they are doing such great work. Thanks for sharing your valuable insight!

Re: The State of JavaScript – Survey results

#285

Post by davidjnelson »

BinaryIdiot wrote: post #264
davidjnelson wrote: post #232

Earlier quoted context omitted.

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

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.

Re: The State of JavaScript – Survey results

#286

Post by jacquesc »

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…

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

Re: The State of JavaScript – Survey results

#287

Post by darksaints »

somlor wrote: post #278
saosebastiao wrote: post #197

Earlier quoted context omitted.

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

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

Re: The State of JavaScript – Survey results

#288

Post by nine_k »

aidos wrote: post #224
spion wrote: post #210

Earlier quoted context omitted.

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…

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

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.

Re: The State of JavaScript – Survey results

#289

Post by nine_k »

increment_i wrote: post #274

For me, the beauty of JS was in its simplicity - there were wacky edge cases for sure, but here was a C-like language that you could use to build a project that almost anyone could understand. When Node first came out I was over the moon - wow, I can run processes on the machine from JavaScript?! Unreal. It seems like I'm constantly keeping up with the complexity of the ecosystem, which is taking a toll on my product…

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

Re: The State of JavaScript – Survey results

#290

Post by djmashko2 »

k__ wrote: post #243
djmashko2 wrote: post #236

Earlier quoted context omitted.

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