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

The State of JavaScript 2018

2018.stateofjs.com

Post reply on HN
Print view View original

171–180 of 286 posts

Re: The State of JavaScript 2018

#171

Post by paulie_a »

doomslice wrote: post #153
IloveHN84 wrote: post #27

Earlier quoted context omitted.

Loved? Well, it's a point of view. I personally hate it, due to the tooling and the dependency management (npm and yarn are catastrophic, an "hello world" example with React downloads on average more than 100 packages).

Having just inherited a legacy python project where I couldn't use a library due to conflicting dependencies on ancient, incompatible versions of a dependency's dependencies... I'd kill for the npm way of dealing with it. To each his own I guess.

That's interesting, what happened? I've always loved the simplicity of a couple of inhereted requirements files in Python depending on the environment. Pin the version as necessary and call it a day. usually my requirements files for local, dev, QA and production are 30 lines total. Js land is a complete shit show of ever changing dependencies with an ungodly amount of sub dependcies that will break every thing

Re: The State of JavaScript 2018

#172

Post by tincholio »

kabacha wrote: post #36
IloveHN84 wrote: post #27

Earlier quoted context omitted.

Loved? Well, it's a point of view. I personally hate it, due to the tooling and the dependency management (npm and yarn are catastrophic, an "hello world" example with React downloads on average more than 100 packages).

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.

Re: The State of JavaScript 2018

#173

Post by minor3rd »

thrower123 wrote: post #118
devxpy wrote: post #64

Earlier quoted context omitted.

I think we should also consider that most people have gotten used to the fact that JS is the language of the web, and there’s basically nothing we can really do about it in the short term, so let’s just have a positive attitude towards it! P.S. I don’t, but most people I have met seem to have this kind of mentality.

Yep, the Stockholm Syndrome. I still swear a blue streak when I get pulled from my nice backend world over to do some trivial UI work on the front-end, and it takes me frigging forever because there's no type system, and no compiler, and the tooling is stone age, and it takes me longer to run gulp and babel to build it to see changes than building my entire backend solution and running all my tests. It's all we've go…

> to do some trivial UI work on the front-end

If that takes you forever, consider that it may also be your lack of familiarity as much as the lack of type system/compiler. Despite my preference for the back end, I have spent plenty of time on the front end and can pump out changes very quickly.

Re: The State of JavaScript 2018

#174

Post by jordache »

paraditedc wrote: post #23

A bit sad that d3.js is not even mentioned here. To me it's a solid replacement for any MVC/MVVM framework. I guess it deserves its own category, maybe data model library?

huh?

People using d3.js as a library for generic data binding UI? It's technically possible I guess, but the API, with its enter, update, delete paradigms, is very much data viz centric. Not the best option for a general front-end UI library.

Re: The State of JavaScript 2018

#177

Post by jordache »

jrumbut wrote: post #57
paraditedc wrote: post #23

A bit sad that d3.js is not even mentioned here. To me it's a solid replacement for any MVC/MVVM framework. I guess it deserves its own category, maybe data model library?

I think it's a real shame that D3 was never broadly recognized as such back when it first came out. I knew about it then, and made some small uses of it for SVG, but thought it was just an SVG generating library that could technically be used for HTML. I did a deep dive into D3 last year and it is amazing for generating HTML. I think in 2018 I prefer the model that React provides, but I didn't like approaches that re…

no built-in routing, DI, templating, components..

No it's a poor tool for what you are suggesting.

Re: The State of JavaScript 2018

#178

Post by wild_preference »

thrower123 wrote: post #118
devxpy wrote: post #64

Earlier quoted context omitted.

I think we should also consider that most people have gotten used to the fact that JS is the language of the web, and there’s basically nothing we can really do about it in the short term, so let’s just have a positive attitude towards it! P.S. I don’t, but most people I have met seem to have this kind of mentality.

Yep, the Stockholm Syndrome. I still swear a blue streak when I get pulled from my nice backend world over to do some trivial UI work on the front-end, and it takes me frigging forever because there's no type system, and no compiler, and the tooling is stone age, and it takes me longer to run gulp and babel to build it to see changes than building my entire backend solution and running all my tests. It's all we've go…

But client development is always hard. Comparing backend work to browser client development in an effort to attack Javascript never made sense to me.

At least you have pretty good wiggle room to use other solutions on the browser client, whether it's other languages (TypeScript, Elm), to completely new abstractions (React, Elm again, etc). For example, Elm or React are a fuck ton better than anything we have native on Android and iOS.

Look at other clients people development for like iOS. It's not easier. And any gains in ease of use are traded off because you're developing for a platform that not everyone uses.

Also, continuing with iOS, things like CoreData and the entire UI abstraction are super OOP and not very pleasant (especially the former). And it's nontrivial and a lot more warty to switch out abstractions (like using Rx) or use something other than Swift.

So that things are harder that you moved from backend to client development isn't a very scathing review of Javascript because client development isn't easy.

Re: The State of JavaScript 2018

#179

Post by minor3rd »

SnowingXIV wrote: post #152
kojoru wrote: post #43

One important data point there is Visual Studio Code. It used to be really popular in 2017 (double the popularity of Atom/Sublime/Webstorm), now it's just eating everyone's lunch (triple the popularity of Sublime/Vim/Webstorm/Atom, almost equal to all of them combined). Also Atom is declining sharply. Compare https://2018.stateofjs.com/other-tools/ to https://2017.stateofjs.com/2017/other-tools/

This makes total sense too. I was so hesitant to use something besides Sublime forever, then I tested out Atom and it was slow (this has probably since been improved) and didn't offer much more so the trade off wasn't worth it for looking pretty. Bounced around a few others and then thought I'll try out the VSCode thing, hooked right away and it seems to keep getting better.

Same experience as you. Thought I would always use sublime but my coworkers were so adamant about VSCode that I finally gave it a try. I don't even know that I can point to any single reason for it being better than Sublime -- feels like everything just works a little more seamlessly.

Re: The State of JavaScript 2018

#180

Post by addicted »

rafaelvasco wrote: post #162
growtofill wrote: post #143

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.

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

Post reply on HN