I maintain some of the top 10 most downloaded packages in the Javascript ecosystem - in the order of hundreds of millions of downloads a week. I've worked with hundreds of repositories, thousands of OSS developers, across a few dozen teams (professionally). I've seen just about all of it, for almost 10 years now.

With all that being said, I'll leave it at this:

I hate every facet of the Javascript ecosystem.

Especially anything to do with React.

@Ubbe I'm designing an educational application that uses a web view as the rendering engine. It would inflate my development times tenfold if I used anything other than web technologies, unfortunately.

For most other things I do, I stay well away from Javascript nowadays.

What would need to change to improve the JS ecosystem?

As an outsider, all I see is new frameworks followed by new frameworks...
Latest one being moment.js. Kinda reminds me about the left-pad incident (hilarious!)

@SuspiciousBug Nuke it and start over. Or simply, stop using Javascript as a programming language and treat it as what it really is - a scripting language.

Also, people really, REALLY need to learn about simple best practices. Today's annoyance took the form of a package that's trying to be overly magical and caused me an hour's detour creating a PR to fix its shitty behavior.

This is a package used by millions of people every day, too.

@OliverTramp Javascript (specifically, Node.js) is more performant than Python. In many cases, it will also be more performant than PHP. However, PHP is generally easier to deploy and scale.

Python shouldn't be used where performance matters, ever.

Further, Node.js by itself is fine. It's just a Javascript engine on top of POSIX APIs with some extra glue code and useful utilities (e.g. the HTTP[S] libraries that are built in).

That's where it ends for me, personally. The language itself has grown to try to be something it's not (only exasperated by Typescript, which is an atrocious mess) and has an army of terrible developers re-inventing the wheel just with flashier logos and branding and more investor-ready buzzwords ("blazing fast" comes to mind) in order to be Unique and Bleeding Edge for Github clout.

@killermenpl "just use PHP" no thanks

@junon highly doubt it's faster than well designed PHP. If performance of such an issue use Go.

I hear a lot of react love except on devrant. Never used it so I'm curious why the hate?

@hjk101 I disagree with both of those statements.

- PHP does not have asynchronous I/O, and has to re-initialize connections on each page run unless you use pooling which is notoriously hard to get right.

- Go's performance is abysmal, it's laughable to think otherwise.

@SuspiciousBug um wut? moment.js has been around forever.

@spongessuck see https://twitter.com/momentjs/...

@junon
Point 1: First of all PHP has a build in persistent SQL connections feature.
In a multiple statistics dashboard page we do the simple from cache queries sequential but all numbers that require long running queries go parallel so the database gets them simultaneously (multiple databases servers actually :multiple readers).
This is a big exception though. All the other pages are so sequential by nature. Trying to do things async is just overhead. Have to admit didn't test it but just looking at the code id say the biggest win on some pages is 20% in some cases (splitting things up more here so there are branch mispredictions) but 0 to 5 percent in most. It's fast enough...

You got to be kidding me in cases where cpu performance matters Go has a huge advantage: it engages all cores without protocol overhead. In the stats overview case PHP does the same but with a lot of context switching. It has to do some heavy post calculations so it might still be faster than node. Go will optimise it by minimising context switching.

@hjk101

> First of all PHP has a build in persistent SQL connections feature.

Yep, that's what I meant by pooling.

> Trying to do things async is just overhead.

In which way? Async decreases overhead performance-wise. In PHP you don't have a means of doing it, but in Node.js it's built into the language.

> Have to admit didn't test it

So then you have no basis to tell me yours is faster.

> You got to be kidding me in cases where cpu performance matters Go has a huge advantage: it engages all cores without protocol overhead.

This is not a novel thing. It's called multithreading. Goroutines are very, very bad at this. Pinning a Go process to a single system thread generally outperforms multiple system threads.

> In the stats overview case PHP does the same but with a lot of context switching. It has to do some heavy post calculations so it might still be faster than node. Go will optimise it by minimising context switching.

This is nonsense. I have no idea what to make of it.

@junon
> In which way? Async decreases overhead performance-wise.

If the problem is sequential. e.g. the result has to be in before calculations can start or they are needed in the next query the performance gain is 0. Even though promises and async/await are not very expensive but they have overhead so yes than performance is actually decreased.

> So you have no basis to tell me yours is faster.

Actually I didn't say mine was faster. Quite the opposite. I said that just by I balling there is not much opportunity to fetch resources in parallel I based my estimate performance gains by using JS on that. Even when getting creative (fetching resources when it's unsure if they are needed) the gains are going to be negligible; except for the two 20% pages or course.

> This is not a novel thing. This is called multithreading.

I know right. To bad node is bound to a single thread... Perhaps there is some solution I don't know about but I thought you would need to do RPC to get multiple cores engaged.

> This is nonsense. I have no idea what to make of it.

We use threading in the PHP stats solution so we can have the queries and processing in parallel. There is no co-routine in it so a lot of context switching. Go has co-routines and a scheduler that optimises execution.
https://medium.com/a-journey-with-g...

Let me guess, you maintain the is-odd package?