7
AleCx04
2y

!rant but kinda

Rails 7 got rid of webpack and Node as a requirement, and for this I am super happy. I heavily disliked having to depend on Node for what is in fact a Ruby framework. I understood the need for it, and I always applaud Rails for being at the forefront of the web dev world and all of the trends that it contains. But maintaining both the node modules required, plus the gemfiles etc was just a big hassle for the simple projects I ever worked on.

This is coming from someone that actually likes JS and Node, but I am thankful this was decoupled.

Comments
  • 0
    This sounds like a sane decision to me.

    I _hate_ the node environment.
  • 0
    @IntrusionCM I honestly can't fault anyone for not liking it. I am particularly disturbed at how it went on to be used EVERYWHERE as if it was the one stop solution for everything.

    I still have a couple of simple apps laying around that were built on Node with Express, they work fine for what they do and are meant to do, but for anything bigger than that I am not entirely sure how I could go ahead and recommend them.
  • 1
    @AleCx04 I think it started when I read about an MP3 decoder or PDF decoder in JS which should run inside the browser.

    My thought was more or less: Ok... Possible solution - but why the hell would anyone do that?

    Later started all the madness with V8 and optimizing JS to a point where it could run fast.

    At that point I was kinda annoyed - why would anyone choose a broken language, which could never been fixed as it is _fundamentally_ broken / obviously misdesigned, for stuff like that?

    Somewhere round that time ECMA Script 5 was released and at least browser interoperability became a possible thing.

    Internet Explorer 7 or 8 I think. ActiveX existed and was widely used, JS interoperability was like fucking a hornets nest willingly.

    Node gained rapidly traction...

    ... and I was kinda pissed right from the beginning. The general idea of NPM wasn't bad per se - but it lacked a structural approach and Javascripts shortcomings bit hard.

    Importability - requirejs, AMD, UMD, npm - "build tools" to generate script sourceable files (bower / gulp / browserify / ...), ... .

    Everybody hyped up NodeJS and "modern" Javascript, but whenever I came in contact with a node environment or "modern JavaScript" it felt like it was in fact a mother echidna giving birth to a trillion of new problems.

    Which made it worse was that the "fragmentation" that was already like "hey just reinvent the wheel a thousand times, it cannot get worse"... Got worse.

    Enter ECMA 6.

    Suddenly we add on the top of madness another madness - a transpiler to allow ECMA version interoperability.

    For me Babel was like: Ok. We fucked up. We fucked it again. Now we try to unfuck the fuckening of fucks by adding another fuck on top.

    The language was fundamentally broken and it became obvious that ECMA Script and transpiling would be the only viable solution to keep JavaScript ""alive"". In my opinion FAANG should have pulled the plug at that moment. Typescript was in it's infants back then....
  • 1
    ... around the time of the ECMA 6 becoming was I think the whole drama lama with NPM registry and package withdrawals.

    ... It didn't get better with internal fights and other things.

    Roughly at that time I decided to stay the farthest fuck away from anything with JS.

    It was just pointless to follow the endless myriad of new packages, "we solve this better, here's a new framework" or "yeah my hello world program uses 2 GB of node_modules and is so fancy" or "I learned to write Makefiles today cause the plethora of build and packaging tools is too slow for me".
  • 0
    But you still have gems for JS libraries, which is even worse...
  • 1
    @hitko Not really, I trust gem devs, maintainers and repo contributors more than I do npm package writers.
Add Comment