Hacker News Reader

Comment by noir_lord | Hacker News Reader

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.

View on HN

>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://node-os.com/

The future is coming!

https://www.destroyallsoftware.com/talks/the-birth-and-death...

We'll know os-js is finished when they finally put in a web browser. :)

Right on schedule. Mandatory XKCD: [1]

[1] https://xkcd.com/1508/

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.

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

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

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).

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.

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

Portability.

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.

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.

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.

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.

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.

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.

If only that toaster had a web browser.

Yeah, good luck getting that Qt app running on an iPhone.

http://doc.qt.io/qt-5/ios-support.html

Wow , that was beautiful

QT is not C

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

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.

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.

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.

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.

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 ;).

I was under the impression that IE was standards compliant enough by version 11 that this shouldn't be necessary, but I guess not.

Well, it's pretty complaint to standards now. The problem is that it's just 2-3 year old standards.

There's plenty of other POSIX userlands for Windows before WSL (cygwin, Ming). There are also plenty of other cross platform programming environments before Grunt (Perl, Python, Ruby, Lua, Haskell, numerous lisps, etc).

JavaScript isn't unique. It's not even the best at what it does. It just has a monopoly in the browser so people latched on to it.

Cygwin or msys2 would probably have let that dev run the build scripts.

Asking that new dev to install cygwin might have been easier!

As if JavaScript would be the only option.

This is a valid concern, if it applies to your individual scenario. Nothing wrong with using the right tool for the job.

I don't care whether or not this is a joke, it's hilarious.

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

Neat, always nice to learn new things :).

Reply on news.ycombinator.com