11 ms·

Same with me except I'm using bash and the CLI to all the modern tools. In 6 months I'll still remember how bash works and I get super simple debugging since I

Same with me except I'm using bash and the CLI to all the modern tools. In 6 months I'll still remember how bash works and I get super simple debugging since I can just echo out the command it was about to run and start poking. I'm still not sure why the JS community seems determined to slowly bootstrap an OS in javascript.

dasil003 10y ago
> I'm still not sure why the JS community seems determined to slowly bootstrap an OS in javascript. Portability.
- gbuk2013 10y ago
  This is a valid concern, if it applies to your individual scenario. Nothing wrong with using the right tool for the job.
- Cacti 10y ago
  That's a load of crap, there's nothing portable about a JS environment that requires build xyz of browser pqr, plus the hardware requirements, bandwidth requirements, etc. Take any ONE of those away and you're hosed (e.g., try loading even a single web page from Amazon on 56k). Every technology of the past 40 years has claimed "portability" as its mantra, and yet here we are still.
  - dasil003 10y ago
    Sure, but the web is a unique portability story in the history of computing. Has any other platform been an open standard that ends up being table stakes for any new entrant? Think about it, if you try to make a computer without a web browser today, you'd be laughed out of the market.
    - ktRolster 10y ago
      Has any other platform been an open standard that ends up being table stakes for any new entrant? C, Java. Far more computers run C than run Javascript.
      - esrauch 10y ago
        Number of machines that can run code written in the language isn't really the best metric for realistic portability. Sure, your toaster might run C and not JS, but it isn't going on run your C anyway.
        TeMPOraL 10y ago
        My browser isn't running my JavaScript, it's running yours. In fact, the capability to run my own code in my own browser is being slowly but systematically removed from the browser.
        esrauch 10y ago
        When I said "you" I meant "the developer" not "the user": the class of devices that run C and not JS is also a class of devices that generally don't run third party code. If you aren't a hardware manufacturer (or trying to sell middleware to one) the fact the embedded systems run binaries that were programmed in C isn't in any way relevant.
        c22 10y ago
        If only that toaster had a web browser.
      - moron4hire 10y ago
        Yeah, good luck getting that Qt app running on an iPhone.
        tedunangst 10y ago
        http://doc.qt.io/qt-5/ios-support.html http://doc.qt.io/qt-5/ios-support.html
- stymaar 10y ago
  In my previous job, we had some bash scripts for a lot of things. It worked pretty well among Linux and Mac users in the team, but one day we had a new developer who was a windows user … We rewritten all those scripts in JavaScript using Grunt. Maybe nowaday it's different thanks to Windows subsystem for Linux.
  - bigato 10y ago
    Wouldn't it be better for one developer to learn and adapt to the rest of the team? I don't get why all the rest had to adapt to this single person who didn't know shell.
    - Klathmon 10y ago
      There's a benefit to having multiple platforms on your development team if you are developing something for multiple platforms. It's too often I see projects with "supports Linux, OSX, and Windows" only to find that none of the maintainers actually own a Mac and therefore it is filled with bugs and often requires the user to "find their own dependencies". If we are talking days of time and not weeks, the benefits of making (and keeping) your whole system cross platform could pay off big time in the future when you or someone on your team wants to switch, or you just want to easily test on other platforms.
      - stymaar 10y ago
        Exactly: Having a developer working on windows was a blessing since it allowed someone in the team to test on EI11 before we shipped to the product team, and it really improved our reactivity on this plateform. It wasn't our main target since our product was using webRtc(i.e. Firefox and Chrome), but it was supposed to fail gracefully on IE.
        nawitus 10y ago
        At least these days you can download VirtualBox images for free to test on IE11. But yeah, it's a luxury if there's a Windows developer that you can have fixing all the IE11 bugs ;).
- scintill76 10y ago
  bash, make, and a POSIX suite probably run on many more platforms than nodejs does. There is the caveat that too many people think they're writing portable shell scripts etc., but really they only work with GNU tools on Linux or MacOS. Then again, the same probably applies to many JS build scripts that end up relying on OS-specific behavior somewhere...
- afdsadf 10y ago
  I don't care whether or not this is a joke, it's hilarious.
adamsea 10y ago
For projects with not-overly-complicated builds, I have had success writing each desired script as a shell script, but then calling said shell script with an npm script. The shell scripts are nice for longevity, self-documenting, and if you have to call them with non-javascripty things. Calling them with npm scripts is nice for consistency, readability for many devs, and some of the path-setting/node.js process.env-var stuff that you are able to do in an npm script.
clock_tower 10y ago
I'm guessing it's the inner-platform effect in action, but I could have sworn that there's a more detailed name for it in reference to Javascript in particular -- something about systems always existing on the edge of acceptability or of legibility, or thereabouts. I think this was on Ward's Wiki, but I can't find it...
zaptheimpaler 10y ago
>I'm still not sure why the JS community seems determined to slowly bootstrap an OS in javascript. Oh if only this was a joke. No.. its happening. https://www.os-js.org/ https://www.os-js.org/ https://node-os.com/ https://node-os.com/
- Animats 10y ago
  Right on schedule. Mandatory XKCD: [1] [1] https://xkcd.com/1508/ https://xkcd.com/1508/
- jryan49 10y ago
  We'll know os-js is finished when they finally put in a web browser. :)
  - deleted 10y ago
    [deleted]
- nitemice 10y ago
  The future is coming! https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
kbutler 10y ago
bash -x script Echoes all the commands for you for easier tracing/debugging...
- noir_lord 10y ago
  Neat, always nice to learn new things :).
adrianratnapala 10y ago
> I'm still not sure why the JS community seems determined to slowly bootstrap an OS in javascript. Well it worked for Emacs didn't it?
- TeMPOraL 10y ago
  It works for Emacs because it gives everything a consistent yet very powerful user interface, that facilitates heavy interoperability. In fact, that interface is more consistent and more powerful than most people have in their operating system. Browsers, on the other hand, promote the exact opposite - inconsistent and weak interfaces, and no interop.
- marcosdumay 10y ago
  You joke, but Emacs commands just interface the standard tools on your system, not replace them. And yes, Emacs programs get deprecated fast (compared to UNIX programs, they are way, way slow compared to JS code), but somehow people don't suffer to update them (mostly because people developing for Emacs know about that "compatibility" word).

dasil003 10y ago

> I'm still not sure why the JS community seems determined to slowly bootstrap an OS in javascript. Portability.

gbuk2013 10y ago
This is a valid concern, if it applies to your individual scenario. Nothing wrong with using the right tool for the job.
Cacti 10y ago
That's a load of crap, there's nothing portable about a JS environment that requires build xyz of browser pqr, plus the hardware requirements, bandwidth requirements, etc. Take any ONE of those away and you're hosed (e.g., try loading even a single web page from Amazon on 56k). Every technology of the past 40 years has claimed "portability" as its mantra, and yet here we are still.
- dasil003 10y ago
  Sure, but the web is a unique portability story in the history of computing. Has any other platform been an open standard that ends up being table stakes for any new entrant? Think about it, if you try to make a computer without a web browser today, you'd be laughed out of the market.
  - ktRolster 10y ago
    Has any other platform been an open standard that ends up being table stakes for any new entrant? C, Java. Far more computers run C than run Javascript.
    - esrauch 10y ago
      Number of machines that can run code written in the language isn't really the best metric for realistic portability. Sure, your toaster might run C and not JS, but it isn't going on run your C anyway.
      - TeMPOraL 10y ago
        My browser isn't running my JavaScript, it's running yours. In fact, the capability to run my own code in my own browser is being slowly but systematically removed from the browser.
        esrauch 10y ago
        When I said "you" I meant "the developer" not "the user": the class of devices that run C and not JS is also a class of devices that generally don't run third party code. If you aren't a hardware manufacturer (or trying to sell middleware to one) the fact the embedded systems run binaries that were programmed in C isn't in any way relevant.
        c22 10y ago
        If only that toaster had a web browser.
    - moron4hire 10y ago
      Yeah, good luck getting that Qt app running on an iPhone.
      - tedunangst 10y ago
        http://doc.qt.io/qt-5/ios-support.html http://doc.qt.io/qt-5/ios-support.html
stymaar 10y ago
In my previous job, we had some bash scripts for a lot of things. It worked pretty well among Linux and Mac users in the team, but one day we had a new developer who was a windows user … We rewritten all those scripts in JavaScript using Grunt. Maybe nowaday it's different thanks to Windows subsystem for Linux.
- bigato 10y ago
  Wouldn't it be better for one developer to learn and adapt to the rest of the team? I don't get why all the rest had to adapt to this single person who didn't know shell.
  - Klathmon 10y ago
    There's a benefit to having multiple platforms on your development team if you are developing something for multiple platforms. It's too often I see projects with "supports Linux, OSX, and Windows" only to find that none of the maintainers actually own a Mac and therefore it is filled with bugs and often requires the user to "find their own dependencies". If we are talking days of time and not weeks, the benefits of making (and keeping) your whole system cross platform could pay off big time in the future when you or someone on your team wants to switch, or you just want to easily test on other platforms.
    - stymaar 10y ago
      Exactly: Having a developer working on windows was a blessing since it allowed someone in the team to test on EI11 before we shipped to the product team, and it really improved our reactivity on this plateform. It wasn't our main target since our product was using webRtc(i.e. Firefox and Chrome), but it was supposed to fail gracefully on IE.
      - nawitus 10y ago
        At least these days you can download VirtualBox images for free to test on IE11. But yeah, it's a luxury if there's a Windows developer that you can have fixing all the IE11 bugs ;).
scintill76 10y ago
bash, make, and a POSIX suite probably run on many more platforms than nodejs does. There is the caveat that too many people think they're writing portable shell scripts etc., but really they only work with GNU tools on Linux or MacOS. Then again, the same probably applies to many JS build scripts that end up relying on OS-specific behavior somewhere...
afdsadf 10y ago
I don't care whether or not this is a joke, it's hilarious.

adamsea 10y ago

For projects with not-overly-complicated builds, I have had success writing each desired script as a shell script, but then calling said shell script with an npm script. The shell scripts are nice for longevity, self-documenting, and if you have to call them with non-javascripty things. Calling them with npm scripts is nice for consistency, readability for many devs, and some of the path-setting/node.js process.env-var stuff that you are able to do in an npm script.

clock_tower 10y ago

I'm guessing it's the inner-platform effect in action, but I could have sworn that there's a more detailed name for it in reference to Javascript in particular -- something about systems always existing on the edge of acceptability or of legibility, or thereabouts. I think this was on Ward's Wiki, but I can't find it...

zaptheimpaler 10y ago

>I'm still not sure why the JS community seems determined to slowly bootstrap an OS in javascript. Oh if only this was a joke. No.. its happening. https://www.os-js.org/ https://www.os-js.org/ https://node-os.com/ https://node-os.com/

Animats 10y ago
Right on schedule. Mandatory XKCD: [1] [1] https://xkcd.com/1508/ https://xkcd.com/1508/
jryan49 10y ago
We'll know os-js is finished when they finally put in a web browser. :)
- deleted 10y ago
  [deleted]
nitemice 10y ago
The future is coming! https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

kbutler 10y ago

bash -x script Echoes all the commands for you for easier tracing/debugging...

noir_lord 10y ago
Neat, always nice to learn new things :).

adrianratnapala 10y ago

> I'm still not sure why the JS community seems determined to slowly bootstrap an OS in javascript. Well it worked for Emacs didn't it?

TeMPOraL 10y ago
It works for Emacs because it gives everything a consistent yet very powerful user interface, that facilitates heavy interoperability. In fact, that interface is more consistent and more powerful than most people have in their operating system. Browsers, on the other hand, promote the exact opposite - inconsistent and weak interfaces, and no interop.
marcosdumay 10y ago
You joke, but Emacs commands just interface the standard tools on your system, not replace them. And yes, Emacs programs get deprecated fast (compared to UNIX programs, they are way, way slow compared to JS code), but somehow people don't suffer to update them (mostly because people developing for Emacs know about that "compatibility" word).