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