Alternatives to the npm, Inc. registry surfacing

General Prog (Archived)
, , ,
1

Seems alternatives to npm Inc.'s registry are becoming more common.

https://open-registry.dev/

[Entropic] The economics of open source by C J Silverio | JSConf EU 2019

The opinion expressed in the the talk is that the demise of npm, Inc. is inevitable - though that shouldn’t be too surprising given the source.

Not limited to JavaScript:

1 Like
2

I wonder how the decentralised version will even deal with security and taking down compromised or abusive packages.

3

I am more interesting in alternatives to the whole JS ecosystem. I would love to get rid of Webpack for example. It would already help a lot if someone could port SASS to Elixir.

1 Like
4

Why port sass to elixir if there’s GitHub - sass/libsass: A C/C++ implementation of a Sass compiler and GitHub - sass/sassc: libsass command line driver. You should be able to control both from the beam.

1 Like
5

Then I could also use rubysass directly.

6

Which you need ruby for and is considerably slower. C on the other hand should not be much overhead and if you have other NIFs to compile you might already have the needed (build) dependencies. But tbh I don’t really get what you’d expect from an alternative implementation in elixir in the first place?

7

Well, I just want to get rid of the JS junk. My dream would be an all-elixir implementation of the frontend building stack so I don’t have to pull in 3 f*ckzillion packages just to compile some CSS and JS.

8

libsass is a standalone C project - no js at all. Wrap it in an elixir api (using ports or NIFs) and you could be good to go. There are many similar language implementations for libsass in other languages already available. node-sass is just one of them, which bundles libsass for usage in javascript.

1 Like
9

@Phillipp Even another S(C|A)SS compiler in just another language would make the eco system even more fragile…

Some bits and pieces implemented differently here and there, some UB over there, and still having the standard implement by 98%, the last 2% will shoot your toe if not break your neck.

I can totally understand that you want to get rid of JS, but to be honest, if there are tools only available in JS, then use them. Use them as any other tool which is only available in a language that is not BEAM.

But try to use it in a way, that you only depend on it during compile time, then you can “lock it” into your docker container, only used for build while keeping the actual released piece of software free of evil stuff.

3 Likes
10

I agree that NPM is hardly the problem. The JS ecosystem and the poor stdlib are the real issues.

11
  • The original post was primarily intended as a “heads up” that there may be changes coming that could generate more than the usual fallout from the Node.js ecosystem towards the rest of web development world. This could be especially true in the short term if certain packages decide to only stay on certain registries.
    To some extent npm’s existence has marginalized alternatives like bower but recent changes could have an impact on the future role that the npm registry has - likely creating (more) headaches for those who have to depend on it.
  • Meanwhile isolation from JS while operating in the web development space is wishful thinking (and to some degree WebAssembly is only going to complicate things further). Unfortunately at this point most web browser based development is heavily reliant on the Node.js infrastructure and will stay so for the foreseeable future.