3 ms·

So Bower and NPM are now basically in control of modern JavaScript development... This is exactly the sort of thing us "JS dependency problem agitators/malconte

So Bower and NPM are now basically in control of modern JavaScript development... This is exactly the sort of thing us "JS dependency problem agitators/malcontents" are unhappy about. The vicious cycle of furious evolution in JavaScript is proving "too fast for comfort" for many of us. We do not all live entirely in the JavaScript ecosystem and no longer have the capacity to keep up with it. However remains the only language we can use in the browser so we are forced to use it and as it continues to accelerate, it becomes like an uncomfortably aggressive personal trainer screaming at us to "push harder" and trying to goad us into moving quicker. We do not have the choice to use JavaScript or not, so when it feels like is it angers us. We feel the parts of the JavaScript development community that push this ever faster, have taken no one else into account and are no longer interested in being good citizens of the web in cooperation with all us other developers. We feel understandably uncomfortable with this sudden "aggressive independence" in the JavaScript community. I'm quite sure a non trivial portion of the support for WebAssembly is because we want an alternative to JavaScript that enables us to escape from this situation. Many developers I talk to are eager to see their language of choice integrated via WASM so the are no longer forced to use JavaScript and much of the desire stems from being ever more unhappy with the direction of the JavaScript community. Everyone is entitled to their opinion, so many of us are glad we will soon have a place where our opinion matters too, not only the opinions of JavaScript developers.

qaq 11y ago
Unless they are C++ developers they will have to wait for a long time :)
- techdragon 11y ago
  You would think that, but as a python developer, I already know a number of projects that will be swiftly attempting to use every angle WASM gives them in order to enable lots of new ways to run Python more reliably in the browser.
pfooti 11y ago
Sure, WASM will make things better, until you have to deal with library and dependency management in your WASM-llvm-deploy toolchain. I get that the javascript world moves pretty fast. On the other hand, what you seem to be saying is, "I don't understand this, _and I do not want to expend the effort to understand it_, so therefore it is bad". There's a lot of things I don't understand, and frankly don't have the time, energy, or training to understand. I leave those things to the engineers who actually worry about them. Example: I can write and optimize SQL queries, but I don't want to work on postgres internals. If you want to be a javascript developer, you should pay attention to the state of the art. FWIW: npm isn't in control of modern javascript development. You are still able to manually find new libraries, download them, add them to your assets directory, include them, and so on. This workflow never stopped working. All npm does is provide a centralized list of library versions and their locations, along with a syntax for declaring dependencies. My current project needs to do some image manipulation, so npm handles downloading and building the mmagic libraries for my development architecture. I could do this on my own, but this is just easier. If it's too hard for you, just do it the old-fashioned way. If you choose to publish a library and not provide npm/bower support because you're old-fashioned, however, don't expect wide adoption.
- techdragon 11y ago
  I hope the hyperbole as far as 'control' goes, is viewed as the half joke it was meant to be. While I'm sure that some as you say "do not want to expend the effort"... I and many others do not have the time left in our days to expend the effort in. As you go on to say, an individual's time and energy are finite. In my case and many other developers cases, the thing we are skilled at is/was web development, which was fine until the effort necessary to keep up with JavaScript and 'client side web development' grew to outpace our remaining time. I want to continue to be a web developer, I have years of practice with this... which apparently means fuck all to most people hiring these days because despite being a good python developer that knows my way around the Django web framework, I can't find the time to work on Django, all the other things I do, like the spare time I've spent learning Django's ORM well enough to begin trying to write a RethinkDB back-end for it... AND after all that, start to rapidly learn the last 3 years of JavaScript in order to catch up to other 'web devs' and become competitive in the job market as web developer again? Because I don't live and breath Ember, Angular, React or whatever new one comes out tomorrow... I'm not a good web developer? "Web developer" suddenly transformed into "JavaScript Developer" while me and others like me weren't looking...? Last time I checked, the web is more than JavaScript, yet we are marginalised by the web development community because the bulk of them are off gazing ever deeper into their own navels. I don't even mean that insultingly, "navel gazing" as a euphemism for being 'introspective' is about the only way to explain the 'staring inwards' that seems to be going on in the JS community, the transpilers, then Babel, ES6, ES7, and onwards, before they are done with one version there are transpilers from the next ultra experimental one to come from the future, to the one from yesterday, in order to implement the one from last Tuesday... which is the one that transforms all my CSS into JavaScript... and I'm already losing myself in my description of how convoluted the ecosystem can get.
Raphmedia 11y ago
The choice of a package manager is on a project by project basis. It's not as if you were required to use Bower or NPM to manage your dependancies. Those are simply two tools used by the JS community to manage its dependancies. There are a lot[1] of them. Where I work, everything was pushed by the back-end guys for a long time. This made the front-end developer dependant on them. With tools that use front-end languages (JavaScript), the front-end team is now free to experiment with package management and build systems (Grunt.js, Gulp.js). This made it so that we now have a very complex but quick and useful front-end workflow. We wouldn't have this if we had not freed the front end team dependancy on the back end team for builds, dependancies, etc. [1] https://www.npmjs.com/ https://www.npmjs.com/ http://bower.io/ http://bower.io/ http://duojs.org/ http://duojs.org/ http://webpack.github.io/ http://webpack.github.io/ https://github.com/componentjs/component https://github.com/componentjs/component http://enderjs.com/ http://enderjs.com/ http://jamjs.org/ http://jamjs.org/ http://volojs.org/ http://volojs.org/ etc.

qaq 11y ago

Unless they are C++ developers they will have to wait for a long time :)

techdragon 11y ago
You would think that, but as a python developer, I already know a number of projects that will be swiftly attempting to use every angle WASM gives them in order to enable lots of new ways to run Python more reliably in the browser.

pfooti 11y ago

Sure, WASM will make things better, until you have to deal with library and dependency management in your WASM-llvm-deploy toolchain. I get that the javascript world moves pretty fast. On the other hand, what you seem to be saying is, "I don't understand this, _and I do not want to expend the effort to understand it_, so therefore it is bad". There's a lot of things I don't understand, and frankly don't have the time, energy, or training to understand. I leave those things to the engineers who actually worry about them. Example: I can write and optimize SQL queries, but I don't want to work on postgres internals. If you want to be a javascript developer, you should pay attention to the state of the art. FWIW: npm isn't in control of modern javascript development. You are still able to manually find new libraries, download them, add them to your assets directory, include them, and so on. This workflow never stopped working. All npm does is provide a centralized list of library versions and their locations, along with a syntax for declaring dependencies. My current project needs to do some image manipulation, so npm handles downloading and building the mmagic libraries for my development architecture. I could do this on my own, but this is just easier. If it's too hard for you, just do it the old-fashioned way. If you choose to publish a library and not provide npm/bower support because you're old-fashioned, however, don't expect wide adoption.

techdragon 11y ago
I hope the hyperbole as far as 'control' goes, is viewed as the half joke it was meant to be. While I'm sure that some as you say "do not want to expend the effort"... I and many others do not have the time left in our days to expend the effort in. As you go on to say, an individual's time and energy are finite. In my case and many other developers cases, the thing we are skilled at is/was web development, which was fine until the effort necessary to keep up with JavaScript and 'client side web development' grew to outpace our remaining time. I want to continue to be a web developer, I have years of practice with this... which apparently means fuck all to most people hiring these days because despite being a good python developer that knows my way around the Django web framework, I can't find the time to work on Django, all the other things I do, like the spare time I've spent learning Django's ORM well enough to begin trying to write a RethinkDB back-end for it... AND after all that, start to rapidly learn the last 3 years of JavaScript in order to catch up to other 'web devs' and become competitive in the job market as web developer again? Because I don't live and breath Ember, Angular, React or whatever new one comes out tomorrow... I'm not a good web developer? "Web developer" suddenly transformed into "JavaScript Developer" while me and others like me weren't looking...? Last time I checked, the web is more than JavaScript, yet we are marginalised by the web development community because the bulk of them are off gazing ever deeper into their own navels. I don't even mean that insultingly, "navel gazing" as a euphemism for being 'introspective' is about the only way to explain the 'staring inwards' that seems to be going on in the JS community, the transpilers, then Babel, ES6, ES7, and onwards, before they are done with one version there are transpilers from the next ultra experimental one to come from the future, to the one from yesterday, in order to implement the one from last Tuesday... which is the one that transforms all my CSS into JavaScript... and I'm already losing myself in my description of how convoluted the ecosystem can get.

Raphmedia 11y ago

The choice of a package manager is on a project by project basis. It's not as if you were required to use Bower or NPM to manage your dependancies. Those are simply two tools used by the JS community to manage its dependancies. There are a lot[1] of them. Where I work, everything was pushed by the back-end guys for a long time. This made the front-end developer dependant on them. With tools that use front-end languages (JavaScript), the front-end team is now free to experiment with package management and build systems (Grunt.js, Gulp.js). This made it so that we now have a very complex but quick and useful front-end workflow. We wouldn't have this if we had not freed the front end team dependancy on the back end team for builds, dependancies, etc. [1] https://www.npmjs.com/ https://www.npmjs.com/ http://bower.io/ http://bower.io/ http://duojs.org/ http://duojs.org/ http://webpack.github.io/ http://webpack.github.io/ https://github.com/componentjs/component https://github.com/componentjs/component http://enderjs.com/ http://enderjs.com/ http://jamjs.org/ http://jamjs.org/ http://volojs.org/ http://volojs.org/ etc.