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

261–270 of 357 posts

Re: The State of JavaScript – Survey results

#261

Post by morgante »

rojobuffalo wrote: post #253
tiglionabbit wrote: post #219

Earlier quoted context omitted.

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

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

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

Re: The State of JavaScript – Survey results

#262

Post by cstrat »

I love Meteor and hope that it continues to grow!

I've been using it since well before v1.0 and can understand peoples frustration around it. A lot of patterns and core themes have come and gone. Allow/deny, blaze, and now it is sounding more and more like mini-mongo might go the way of Blaze in lieu of Apollo.

Like I said though, I really do hope that the core values of Meteor stick around in the framework and it continues to grow. I love it :)

Re: The State of JavaScript – Survey results

#263

Post by BinaryIdiot »

anamoulous wrote: post #144
BinaryIdiot wrote: post #78

Earlier quoted context omitted.

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

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

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.

Re: The State of JavaScript – Survey results

#264

Post by BinaryIdiot »

davidjnelson wrote: post #232
BinaryIdiot wrote: post #116

Earlier quoted context omitted.

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

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.

Re: The State of JavaScript – Survey results

#265

Post by bdr »

morgante wrote: post #238
bdr wrote: post #163

Earlier quoted context omitted.

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…

Thanks! Are you using the Django template language on the server or using React somehow?

Re: The State of JavaScript – Survey results

#266

Post by morgante »

bdr wrote: post #265
morgante wrote: post #238

Earlier quoted context omitted.

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…

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.

Re: The State of JavaScript – Survey results

#267

Post by anewhnaccount »

kuon wrote: post #129
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.

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.

Re: The State of JavaScript – Survey results

#268

Post by bcheung »

BinaryIdiot wrote: post #69
triangleman wrote: post #55

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

Re: The State of JavaScript – Survey results

#269

Post by stephenhuey »

nxtrafalgar wrote: post #213
arxpoetica wrote: post #119

Anyone feel like piping in why Aurelia? It pops out in the data, but unknown is satisfaction, etc.

I also wrote my first SPA in Aurelia this year. As an introduction to the Javascript world, it has been pretty good (though I would never use JSPM again). Bugs are fixed in a timely fashion, the developers are responsive, and overall my developer experience has been positive.

I hear you, but now they're starting to make it possible to get away from JSPM. I recently ported my "old" Aurelia app to the new Aurelia CLI version and it's great!

Re: The State of JavaScript – Survey results

#270

Post by acemarke »

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…

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

Post reply on HN