Live data from Hacker News

The State of JavaScript 2018

2018.stateofjs.com

211–220 of 286 posts

Re: The State of JavaScript 2018

#211

Earlier quoted context omitted.

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

That is why I love React Native. Things like laying out screens is simple using flex and position properties. Laying out in iOS? Not as simple with those atrocities like auto layout, constraints...

Re: The State of JavaScript 2018

#212
post #141

Earlier quoted context omitted.

One major reason is that Ng is its own thing. It's not JavaScript, nor HTML. Also, "batteries included" means buying into the whole monolithic framework. The React ecosystem requires more decisions, but also benefits from ability to pick and choose the right libraries for a given project. That said, Angular has some great parts, eg TypeScript and RxJS.

I think people will grow "hating" React because of the ease of use. Just like JS and PHP. I weep for the people that will maintain all the React mess that is being created. React is great, but the current ecosystem has too much liberty for too many junior dev using it. Angular being a framework has a lot to offer in term of maintainability and good practices.

I can assure you that nobody on earth hates Js and PHP for "ease of use"

Re: The State of JavaScript 2018

#213
post #12

> JavaScript is always changing. New libraries, new frameworks, new languages… It's part of the fun, No.. NO, it isn't.

Then stop learning the frameworks and start learning the core of the language. I got dizzy from all the options out there so I spent some time improving my knowledge of JavaScript itself instead of focusing on someone else's library. In the end, those frameworks are "nothing" but a lot of JavaScript patterns stuck together. Switching from one framework to another should't cause THAT much friction.

The main problem with frameworks isn't the frameworks but the MBA's who finished reading "Lean In", congratulated themselves for finally finishing a whole chapter book, and set out to "conquer the world" under the assumption that developing software is trivial, and the fact that it's not done yet is because the programmers are lazy and stupid and aren't using the right frameworks, googled "good web frameworks" and forwarded the first link to the engineering organization with the title "FYI".

Re: The State of JavaScript 2018

#214

Earlier quoted context omitted.

This is a fairly vacuous remark, if I'm frank. The problem isn't that you have to learn another framework (although it does become a problem when they're all slightly similar and they start to meld together after the umphteenth, not to mention that learning slows down with age). The problem is that each frameworks brings along new edge cases, new problems and forces you to reinvent tools you already had for this new…

No one forces you to learn anything new if you don't want to. People aren't stupid, if they invent new something (and pour shit ton of effort into it like with Vue or React) they probably have a good reason to (previous PITA first comes to mind). And anyone's "I don't want to learn" whining is in no way a reason to not invent that new something because that will actually slow down progress of tech field (which we can…

> if they invent new something ... they probably have a good reason to

https://en.wikipedia.org/wiki/Not_invented_here

Even if there were no reason at all, the bias toward writing things ourselves ensures that we'd continue to see these new frameworks.

Re: The State of JavaScript 2018

#215

Earlier quoted context omitted.

> Angular is dead? Most don't even want to touch it again ( Great ). I don't get the Angular hate. I work with it daily and seems like a productive environment. I did some tests with React and Vue too and couldn't find any relevant advantage. Angular has batteries included tools for a lot of tasks: i18n, routing, isomorphic builds, web components, etc.. You get a cross platform mobile development environment too usin…

One major reason is that Ng is its own thing. It's not JavaScript, nor HTML. Also, "batteries included" means buying into the whole monolithic framework. The React ecosystem requires more decisions, but also benefits from ability to pick and choose the right libraries for a given project. That said, Angular has some great parts, eg TypeScript and RxJS.

> One major reason is that Ng is its own thing

You're spot on with that in my case. I already knew JS and wanted to build on top of it. React just felt natural to pick up than Ng. Also, the fact that ng completely changed in v2 really put me off and I haven't looked at it since.

Re: The State of JavaScript 2018

#216

Earlier quoted context omitted.

One major reason is that Ng is its own thing. It's not JavaScript, nor HTML. Also, "batteries included" means buying into the whole monolithic framework. The React ecosystem requires more decisions, but also benefits from ability to pick and choose the right libraries for a given project. That said, Angular has some great parts, eg TypeScript and RxJS.

I find the "build your own framework" aspect of React to be as much a curse as it is a blessing. You can skip some of the bloat, but you also have to kludge together multiple libraries of varying quality to get the same things you'd get out of the box with a "batteries included" framework.

especially for new developers and organizations. You have a choice between a wide-open landscape and a script that you're deathly afraid to eject because you can never go back. Neither is great for someone considering adoption for a new commercial product.

Re: The State of JavaScript 2018

#217
post #193

Earlier quoted context omitted.

I'm curious: why is it bad? I very, very rarely have to delve into my node_modules folder to take a look at something.

The leftpad fiasco (which I believe NPM has now mitigated), and the recent security issue where a certain popular package was uploading any passwords it found showed the current dangers with NPM.

I'm not arguing about the security of NPM, rather the idea that multiple modules is a bad thing.

Re: The State of JavaScript 2018

#218

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

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

Re: The State of JavaScript 2018

#219
Ah, it's that time of the year again – always enjoy seeing where the JS ecosystem is moving.

I would like to see two categories added for next year's survey:

1. Auth – would be interested to see if Passport is still the tool of choice

2. ORM – curious how Sequelize, Knex/Bookshelf, Objection, etc. compare in usage.

I understand this survey will obviously skew towards frontend tools, but some of the categorization just feels off to me:

For example, I wouldn't consider Next.js a backend framework. Sure, it's a server-side-rendering framework, but you wouldn't typically be using it for traditional backend things like accessing a database. Perhaps consider adding a SSR sub-section on frontend frameworks.

The data layer section seems a bit confused – it's mix between client-side stores and server-side persistence which have very different use cases. I'd probably move out the databases into their own category - would be interesting to see which JS devs prefer (eg. Postgres, MySQL, Mongo).

And trying to draw conclusions from the testing category seems odd when both frontend- and backend-specific tools are bunched together.

Re: The State of JavaScript 2018

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

[deleted]
Post reply on HN