Hacker News Reader

Comment by fijal | Hacker News Reader

For the sake of my future self I hope the answer is no. However bad the current platforms are (and I'm certainly not a huge fan of apples policy w.r.t. implementing own languages), you can think about writing your own application without writing in Javascript and using e.g. kivy. I don't mind Javascript capturing mindshare, since it's choice to use it, I don't like the situation where it's not a choice, it's ENFORCED upon me, like on the web. With all the talk about open platforms and freedom, mozilla is sticking to it's guns with "everyone should use javascript, all the time". For one I would like to keep my freedom to use other things, thanks mozilla :-)

View on HN

List of languages that compile to JavaScript [1]

[1] https://github.com/jashkenas/coffeescript/wiki/List-of-langu...

None of that helps if you want to do something that is prohibited by the javascript sandbox.

To pre-empt the inevitable response that everything you want to do is possible inside the javascript sandbox: for a lot of people everything they want to do is possible inside the iOS app store restrictions. That still doesn't make iOS an open platform suitable for general computing, and neither is FirefoxOS.

I don't see what that has to do with language choice.

Criticising FirefoxOS for being 'javascript only' can mean a variety of things. It can mean the author doesn't like the javascript language and thinks they will inevitably be forced to use it at some point. Or it can mean they don't like only being able to target a very restrictive sandbox that is defined by a couple of very powerful corporations. Or both.

FirefoxOS and ChromeOS are attacks on general purpose computing just as much as iOS is.

It can mean anything you like; I just think that makes little sense.

Every platform has one "base" language - even rms' laptop can only run MIPS instructions; everything else must be compiled or interpreted. FirefoxOS just uses JS as its base language.

And it can use Asm.js to run LLVM code.

Not really, because your not restricted by store policies but rather the runtime and it's APIs. Your free to make a app for whatever purpose you want without worrying about whether it's fits in line with how the platform holder wants you to use it.

If having restrictions on the runtime is your criteria for judging whether or not it's "general purpose" or not then every platform with a kernel fails because everything is subject to the restrictions it imposes.

Or it can mean they don't like only being able to target a very restrictive sandbox that is defined by a couple of very powerful corporations. Or both.

But Firefox is in control of its sandbox. It has provided a lot of native API access that other platforms don't have.

The correct test is simply whether the owner of the device has a clear path to root.

Trying to divine somethings "general purpose" via just evaluating the runtime is murky and distracts from the core issue.

By the root standard iOS fails completely.

ChromeOS, Android and FirefoxOS all get middling grades in this.

I would disagree with FirefoxOS, as you can root the device it runs on without doing hardware modifications, unlike ChromeOS.

That being said, consumer devices need to be able to pass a sort of "slave test"; if your device can't hook up to a printer/scanner, or other peripherals, it is a device meant to enslave you in a digital jail.

Mozilla seems to be the best citizen thus far when it comes to user rights, and I wouldn't expect that stance to change much due to a different formfactor. this is still very much the same project JWZ founded.

It should be noted that Chrome (and hence ChromeOS) has USB, Bluetooth and even serial port APIs¹ for its apps. Though you do have to include the specific device codes in the app manifest, so it's probably not very useful for general purpose devices.

¹ https://developer.chrome.com/apps/app_usb

Right, and for that reason, I view ChromeOS as sort of a "House Arrest" sort of situation; still a jail (hardware bypass required to write to the drive? Wtf.), but more lenient. A kinder, gentler slavery, as George HW Bush might have said.

This is ridiculous. I want a real language, like Python or Ruby, not something that is ESSENTIALLY JavaScript with an altered syntax and few goodies.

> I want a real language, like Python or Ruby

First, by what criteria is JavaScript not "a real language" whereas Ruby and Python are "real" languages?

Second, in any case, among the languages on that list that compile to JavaScript are both Ruby and Python, which I think meets any reasonable definition of a "a real language, like Python or Ruby".

JavaScript is a real language. I should make it more explicit - I want a real language that's sufficiently different than JS. Any of the list is not. If you look closely, none of the languages is actually python or ruby (or anything else that's sufficiently different), just JS with altered syntax. Getting all the semantic differences is REALLY hard and once you do it it's slow (e.g. untranslated pypy slow, ~60x slowdown), so you can't use it. My problem is not with JS per se it's with the absolute lack of choice.

What about ClojureScript? From what I gather it's quite fast and it couldn't be more different from javascript.

Or even C via asm.js?

In what way is Brython just JS with altered syntax, and not actually Python?

2004 called. they want their opinion back.

I don't think JS is really "enforced" - there's even standard provision for using alternate scripting language if browser supports it (e.g. IE supports - or used to, haven't checked recently - VBscript) via type attribute of script tag.

The problem with alternate languages is that people won't use them if browsers don't support them, and browsers won't add support for them if people don't use them. JS became a de-facto standard due to being included in early browsers and is certainly hard to unseat due to the tremendous momentum it gained.

Use any compile-to-JS language, or use any LLVM language (such as C++) to compile to asm.js.

I tried kivy with a lot of enthusiasm, and the experience was not good. React native does a better job, I think (or just React in FF OS). I say it as a programmer whose favorite language was Python for many years, I even coded a Python-to-JS compiler with classes, inheritance and stuff where other attempts were very too basic or too slow... Now my favorite language is CoffeeScript.

Repeat after me: JS is not an ideal compilation target.

The sooner this idea dies, the sooner we can solve the actual problem of being locked to an insanely high level VM and calling it a platform -- while writing that platform with much more powerful tools that aren't available to anyone else.

Repeat after me: JS is the compilation target we have.

The sooner this idea dies, the sooner we can solve the actual problem of being locked to an insanely high level VM

So, the sooner we stop making actual things, we can take a step back and start making a thing that makes things?

By all means, try to solve this problem. But if the history of the web has shown anything, it's that it's extremely difficult to entirely reboot anything. JavaScript is all pervasive, and an alternative is going to have to come up with something brilliant to displace it. I haven't seen it yet.

> Repeat after me: JS is the compilation target we have.

No, it's the compilation target web developers have. The rest of us don't target the web.

We're going to see a few interesting things play out: GWT got a new user-base within Google because the Inbox team is using GWT for the non-UI part of the Web implementation (and j2objc for iOS).

compile-to-JS languages are generally just syntactic sugar. How do I access DOM from my LLVM language? Seriously, the question was not what's YOUR favorite language, if you happen to be in the JS camp, that's perfectly fine. However, if JS is not your favorite language, you're out of luck. Sucks to be you.

You can call JS functions from LLVM code. How else can the asm.js based engines call the canvas functions and emulate a FS with localStorage?

Reply on news.ycombinator.com