Live data from Hacker News

The State of JavaScript 2018

2018.stateofjs.com

221–230 of 286 posts

Re: The State of JavaScript 2018

#221

Earlier quoted context omitted.

What's 'catastrophic' about Yarn?

Not exactly Yarn or NPM. The problem is that JS is suffering from extreme dependency hell, due to overly fragmentation of modules. It's appalling. It is not a good thing starting a project, doing a install and having hundreds and hundreds of modules on node_modules, some with less then 50 lines of code. Of course things must be modular, but unwraping everything in a folder like this is far from good.

NPM and Yarn are both working on approaches that would replace having a separate unpacked `node_modules` folder for every project: "Yarn Plug 'n Play" and "NPM Tink".

Re: The State of JavaScript 2018

#222

Earlier quoted context omitted.

Not exactly Yarn or NPM. The problem is that JS is suffering from extreme dependency hell, due to overly fragmentation of modules. It's appalling. It is not a good thing starting a project, doing a install and having hundreds and hundreds of modules on node_modules, some with less then 50 lines of code. Of course things must be modular, but unwraping everything in a folder like this is far from good.

Isn't the issue here basically that JS doesn't have a "standard" authorized library, like Java or C# and NPM has basically become the standard library? Having someone like Google steward a "standard" library (and it could even be distributed using NPM), would pretty much bring JS dependency management at par and beyond Java or C#.

[deleted]

Re: The State of JavaScript 2018

#223

Earlier quoted context omitted.

On the plus side, once you built it, the only dependency you have is the browser, and you can distribute it however you want since it's cross-platform compatible.

>> the only dependency you have is the browse HA! maybe this is technically true, because in the end that's where it runs, but have you looked in your modules folder at any substantial project lately? The dependencies run deep and they run wide...

Tell me about it.

https://news.ycombinator.com/item?id=12209300

Re: The State of JavaScript 2018

#224

Earlier quoted context omitted.

My bet is that Angular pushes for using TypeScript too much, which makes you wonder where to start. On the other hand ReactJS & Vue work with TypeScript, but are not designed to embrace it. I've seen lots of questions about Angular on StackOverflow which should be classified as TypeScript questions, since they have nothing to do with Angular itself. I guess that's the confusing and non-attractive part of Angular. Typ…

I've noticed this too. And I think it's a pretty big reason why people are abandoning Angular. A lot of frontend developers I work with just don't want to use Typescript (or are afraid to), I've found it incredibly hard to push for it here.

As the resident TypeScript advocate at my workplace, I sympathize.

Re: The State of JavaScript 2018

#225

Earlier quoted context omitted.

Regarding GraphQL, I think the reason is at least partially that there aren't too many applications that actually benefit from the all-dynamic approach of it. It's neat and useful in certain applications, but I wouldn't use it everywhere. The tooling isn't quite there yet also in my opinion, but the friction will probably go away with time.

I agree that the dynamic querying aspect of it isn’t useful in most apps but the way graphql simplifies your API (and maybe your state management) compared to REST is by itself, I think, worth it. Tooling seems to be ramping up quickly but I agree, isn’t there yet.

Yeah, I assume the low usage of GraphQL in this survey coordinates/correlates with the low usage/knowledge about Apollo in this survey. Apollo seems the most invested in ramping up strong tools for GraphQL, so of course developers aren't likely to be using GraphQL if they haven't yet heard about/explored Apollo's efforts.

For instance, apollo-link-rest would be a strong way to bootstrap into GraphQL for shops with heavy REST investments.

That said, Apollo aren't yet doing themselves favors with nearly every part of their tooling still showing a "Caution: Active Development" warning. That keeps them right on that cusp of "Should I use this in production?" worry for enterprise, and slows adoption probably more than they intend.

Re: The State of JavaScript 2018

#226

Earlier quoted context omitted.

I can speculate here a little bit. Majority of survey users has less than 10 years of experience. That makes them susceptible of being Visual Studio Code users. VSC - Microsoft product. Typescript is Microsoft product as well.

I am curious (as a VSCode user) what makes you conclude that junior devs are likely to use VSCode?

It is really good tool and free one. Better tools are either commercial or requires a lot of learning.

Re: The State of JavaScript 2018

#227
For connection between technologies, this wheel chart type is not very helpful, things would be much clearer on confusion matrix[1]. It is a (ha!) confusing name, so it is better to call it coincidence matrix, but "confusion" is a traditional name for this already.

The authors actually use thix matrix type viz many times in the report e.g. for correlating salary information to other categories.

[1] https://en.wikipedia.org/wiki/Confusion_matrix

Re: The State of JavaScript 2018

#228
post #42
post #18

People are generally happy with the development of JS the trends of always improving languages along with frameworks makes developing with JS makes developer increase in happiness for the third time in a row. ES6 is good, TypeScript is gaining ground, people are moving away from Flow. Angular is dead? Most don't even want to touch it again ( Great ). Ember hasn't moved a bit in three years with a declining of interes…

> Angular is dead? Most don't even want to touch it again ( Great ). Yet what I see around me is enterprise customers on our projects adopting Angular as the official internal Framework, as React is seem as too advanced.

I think the conclusion chart shows it clearly: Angular has very high usage (nearly as much as React) and very low satisfaction in using it.

(Which is often what you would expect of enterprise development: go with the solution "everybody else uses", whether or not everybody else enjoys using it. ;)

Re: The State of JavaScript 2018

#229
post #18

People are generally happy with the development of JS the trends of always improving languages along with frameworks makes developing with JS makes developer increase in happiness for the third time in a row. ES6 is good, TypeScript is gaining ground, people are moving away from Flow. Angular is dead? Most don't even want to touch it again ( Great ). Ember hasn't moved a bit in three years with a declining of interes…

GraphQL has a LOT of boilerplate to be able to use it. In many situations the effect is barely, if at all better over direct REST/RPC API end points. That has a lot to do with only 20% using it.

I really wish more would migrate to Koa over Express, but I get it.

As to the JS Love, I think there's still plenty of hate around.

Re: The State of JavaScript 2018

#230
post #36

Earlier quoted context omitted.

As much as I dislike Javascript OP is right. The latest stack overflow survey[1] puts #7 on most loved languages and it's not even in top 25 most dreaded ones. [1] - https://insights.stackoverflow.com/survey/2018#most-loved-dr...

I do wonder how much of that love is from devs who basically only know JS, and have done nothing by web stuff.

Can't speak for anyone else... but will say I'm far more productive with full-stack JS. My second most familiar language is C#, followed by Ruby, VB, Java and several other languages. Most of the productivity outside the browser is because of Node + NPM though. Also the browser gives you a much more rich rendering target than pretty much any common UI platform out there. Including some very nice abstractions.

In the end, it isn't the best choice for many things, but it's good enough for most things. As such, it's what I tend to reach for first, since getting something working takes less time, and gets in my way so much less. Windows, Mac, Linux via Node, Electron, Carlo (node + installed chrome), not to mention Cordova (iOS/Android) and React Native. Best of all, I don't have to deal with a lot of issues seen in other platform specific tools.

It's so much closer to write once, run everywhere with less friction than anything else that has been done in computing. Aside from trivial projects.

Post reply on HN