5 ms·

<rant>Yeah I really love how I now not only need Node and npm, but also gcc to install/build a frickin' web project. Because f*ck the platform-independence we g

by xrstf 11y ago

<rant>Yeah I really love how I now not only need Node and npm, but also gcc to install/build a frickin' web project. Because f*ck the platform-independence we got with Node, who cares if a simple `npm install` takes 30 minutes to complete.</rant>

pyre 11y ago
Nothing is requiring you to use these tools, but as web projects become more and more complex we develop tools to deal with the complexity. You could just as easily ignore all of this and use server-side rendering in your language of choice.
rubiquity 11y ago
You would need GCC to install Node anyway. Not to mention the fact that you probably have GCC or Clang already anyway...
- xrstf 11y ago
  Nope, I'm on Windows. I don't need GCC (or any other C compiler for that matter) to install Node, but now I need one because some of my coworkers on Macs decided to throw every possible dependency they could find into the project.
chillingeffect 11y ago
I don't use it, so I don't know, but I'm just wondering, why is it necessary to use gcc to use libsass? Isn't there a PPA for it? Would a PPA be the proper way to distrib what sounds like a really valuable program? Thank you.
- lotyrin 11y ago
  System level package management falls quite short of what you want for applications in a lot of ways still. Different apps will want to specify and build against extremely specific and different versions of their dependencies, and developers will want to be able to change these versions without lots of organizational coordination between owners of dev/CI/stage/production environments. Currently, this is solved by things like npm/bower/bundler/composer/maven/etc. etc. The code repository describes all the dependencies and they get installed just for that app, testing and deployment process simply incorporate the app's packaging tools. However, for any dependencies which use native extensions, you tend to need to be able to compile those - across all your environments - which means having working toolchain everywhere. Not that this is strange or hard in my opinion, but it seems to discourage people somehow.
- xrstf 11y ago
  I'm on Windows and I don't want to install Visual Studio just because of libsass...
  - pyre 11y ago
    Should the people that wrote libsass have decided whether or not to write it in C based on whether or not you would have to install Visual Studio to get it working on Windows? As a C library, it allows linking from several different languages, so maybe their motivations were getting a non-Ruby Sass implementation that could be used in whatever language you need it in. Maybe then the people that wrote the JS to link against the C library are the people that burdened you with this hardship then? Should every person that wants to use libsass from JavaScript be deterred against creating that JS library linking against libsass just because it might cause you some sort of "software installation hardship?" I'm really confused what you feel the "ideal world" of your rant is. That the libsass people should have written it in JavaScript? How then would (e.g.) Python compile Sass? By installing Node and calling out to run the JavaScript libsass? Wouldn't that just lead to more people saying things like "Why should I have to install Node just to compile some Sass?" I'm sure the initial implementation of Sass being in Ruby was great for Rails developers because Ruby was already a part of their toolchain. For other projects that were not using Ruby though, Sass required an install of Ruby just for the purpose of compiling Sass.
lotyrin 11y ago
I can't help but feel like the anti-native-extensions point of view is short sighted. Why shouldn't we have optimized implementations of algorithms that we can share across various languages?
- e12e 11y ago
  I generally agree with you sentiment -- but with js being within an order of magnitude of C -- it seems the likelihood of incompatibilities between the js version (that could run in rhino, nodejs and the browser for in-place use of sass over css) outweigh the benefits of maintaining a C version (especially as specifications evolve, and need to be ported to C). Then again, having (at least) two implementations is one way to test compatibility and nail down unclear specs...
nfriedly 11y ago
FWIW it is possible to ship a native node.js module that falls back to an emscripten version when a c++ compiler isn't available - see http://insertafter.com/en/blog/native-node-module.html http://insertafter.com/en/blog/native-node-module.html for an example.

by xrstf 11y ago

pyre 11y ago

Nothing is requiring you to use these tools, but as web projects become more and more complex we develop tools to deal with the complexity. You could just as easily ignore all of this and use server-side rendering in your language of choice.

rubiquity 11y ago

You would need GCC to install Node anyway. Not to mention the fact that you probably have GCC or Clang already anyway...

xrstf 11y ago
Nope, I'm on Windows. I don't need GCC (or any other C compiler for that matter) to install Node, but now I need one because some of my coworkers on Macs decided to throw every possible dependency they could find into the project.

chillingeffect 11y ago

I don't use it, so I don't know, but I'm just wondering, why is it necessary to use gcc to use libsass? Isn't there a PPA for it? Would a PPA be the proper way to distrib what sounds like a really valuable program? Thank you.

lotyrin 11y ago
System level package management falls quite short of what you want for applications in a lot of ways still. Different apps will want to specify and build against extremely specific and different versions of their dependencies, and developers will want to be able to change these versions without lots of organizational coordination between owners of dev/CI/stage/production environments. Currently, this is solved by things like npm/bower/bundler/composer/maven/etc. etc. The code repository describes all the dependencies and they get installed just for that app, testing and deployment process simply incorporate the app's packaging tools. However, for any dependencies which use native extensions, you tend to need to be able to compile those - across all your environments - which means having working toolchain everywhere. Not that this is strange or hard in my opinion, but it seems to discourage people somehow.
xrstf 11y ago
I'm on Windows and I don't want to install Visual Studio just because of libsass...
- pyre 11y ago
  Should the people that wrote libsass have decided whether or not to write it in C based on whether or not you would have to install Visual Studio to get it working on Windows? As a C library, it allows linking from several different languages, so maybe their motivations were getting a non-Ruby Sass implementation that could be used in whatever language you need it in. Maybe then the people that wrote the JS to link against the C library are the people that burdened you with this hardship then? Should every person that wants to use libsass from JavaScript be deterred against creating that JS library linking against libsass just because it might cause you some sort of "software installation hardship?" I'm really confused what you feel the "ideal world" of your rant is. That the libsass people should have written it in JavaScript? How then would (e.g.) Python compile Sass? By installing Node and calling out to run the JavaScript libsass? Wouldn't that just lead to more people saying things like "Why should I have to install Node just to compile some Sass?" I'm sure the initial implementation of Sass being in Ruby was great for Rails developers because Ruby was already a part of their toolchain. For other projects that were not using Ruby though, Sass required an install of Ruby just for the purpose of compiling Sass.

lotyrin 11y ago

I can't help but feel like the anti-native-extensions point of view is short sighted. Why shouldn't we have optimized implementations of algorithms that we can share across various languages?

e12e 11y ago
I generally agree with you sentiment -- but with js being within an order of magnitude of C -- it seems the likelihood of incompatibilities between the js version (that could run in rhino, nodejs and the browser for in-place use of sass over css) outweigh the benefits of maintaining a C version (especially as specifications evolve, and need to be ported to C). Then again, having (at least) two implementations is one way to test compatibility and nail down unclear specs...

nfriedly 11y ago

FWIW it is possible to ship a native node.js module that falls back to an emscripten version when a c++ compiler isn't available - see http://insertafter.com/en/blog/native-node-module.html http://insertafter.com/en/blog/native-node-module.html for an example.