8 ms·

There are no end of alternatives out there today, from mobile platforms to research languages exploring a myriad of aspects of computer science. Just let me kn

There are no end of alternatives out there today, from mobile platforms to research languages exploring a myriad of aspects of computer science. Just let me know when browser vendors are going to break down the two-tiered system, and let us run the legion of alternatives alongside -- instead of under -- JavaScript. Or, they could take their own medicine, and try and write the browser in JS.

pcwalton 11y ago
> Just let me know when browser vendors are going to break down the two-tiered system, and let us run those myriad of alternatives alongside -- instead of under -- JavaScript. The complexity of doing that would be needlessly high compared to just improving JavaScript. Having to integrate a C++ DOM with a JS DOM is hard enough. Think about how you handle cross-language cycles… > Or, they could take their own medicine, and try and write the browser in JS. You mean like Firefox?
- mattmanser 11y ago
  Works on OSes. We have a choice. In browsers, the OSes of the web, nope, just a bad language designed in 10 days that resists all attempts to make it not bad. It doesn't really matter if you like javascript, there's so many people who don't. Why do you get to dictate whether we can or can't develop on the web? You leave us with a horrible choice, use what we consider to be one of the worst modern languages, or not develop. Why do you get to make our professional lives miserable?
  - pcwalton 11y ago
    > Works on OSes. We have a choice. The kernel doesn't have a DOM. On the Web, the number of GC'd objects that every "process" has to deal with exceeds the number of file descriptors by an order of magnitude. Also, you do have a choice: you can compile your favorite language to JS, even low-level ones via asm.js. > Why do you get to dictate whether we can or can't develop on the web? You leave us with a horrible choice, use what we consider to be one of the worst modern languages, or not develop. Why do you get to make our professional lives miserable? That's not the choice: you can compile your favorite language to JavaScript. That's what source maps, asm.js, and the like are for. And JS is being improved all the time; it's not static. Trying to add another language has been tried multiple times and has always failed, because having two languages that both interact with the DOM is much more difficult than just improving JS.
    - ForHackernews 11y ago
      Semi-serious question: Other than backwards compatibility, do browsers need to have a DOM? It seems like many web app devs spend more time fighting against the DOM than working with it. Why not just make the browser expose a generic GUI model? Let web devs interact with Webkit or QT directly?
      - nostrademons 11y ago
        Generic GUI toolkits are very often worse than the DOM. I've worked with Swing, MFC, SWT, Android, and iOS, and all of them are significantly more complicated than the DOM is. They do function at a higher level of abstraction, and the two really nice things they give you are components and a sane layout system (solved by WebComponents and Flexbox, now if only all the major browser vendors would just adopt WebComponents...), but in general I've found that iOS development is about 1.5x-2x slower than web development and native Android development is about 3x slower, roughly on par with Swing or SWT. MFC was a clusterfuck, I wouldn't even go there. The way frontend devs for other platforms deal with it is to specialize in the nuances of the platform and effectively build your app around the capabilities that Google/Apple/Microsoft/Sun provide. That's fine, and makes for a fairly uniform, polished experience if you have good devs, but it significantly restricts the set of apps you can build. The reason web developers like developing for the web is because it doesn't make you a sharecropper in Google/Apple/Microsoft's world, while building a full-featured GUI framework into the browser would.
        bitL 11y ago
        I still remember how super easy and fast was to make a GUI in Delphi/C++ Builder - what took a month in MFC/Swing took about an hour in Delphi. Even Qt feels like a massive step back from this...
        wbillingsley 11y ago
        I've found JavaFX's scenegraph approach rather neat. Effectively it borrows from HTML, but where the basic node set is designed to be UI elements rather than co-opting a set that was designed for text documents. It seems to take a surprisingly small amount of code to sketch up an interface. React's not bad on the web side (especially with Scala.js) but fudging around layouts in components with divs and Bootstrap still feels clunky.
  - TazeTSchnitzel 11y ago
    > Works on OSes. We have a choice. No, it doesn't work on OSes. OSes only handle one language: the native machine code of that platform. Everything else must be compiled to it. This is exactly the same as browsers. Edit: At least two people disagree with me (-1 points) - would you mind elaborating why?
    - serge2k 11y ago
      Your point is irrelevant, then difference then becomes the fact that at an OS level I can choose what code I compile into machine code and in the browser I can't.
      - TazeTSchnitzel 11y ago
        > Your point is irrelevant, then difference then becomes the fact that at an OS level I can choose what code I compile into machine code and in the browser I can't. Uh, what? You do have a choice in the browser. I don't understand.
      - eccenux 11y ago
        No, for OS you decide which compilator to choose. As is with browsers. There are several languages (e.g. TypeScript, CoffeeScript, Dart) which can be compiled to JS. That is not what I personally like (the processes of compilation and deployment I mean), but if you develop for OS then you have to compile before you run... In most OS.
  - acdha 11y ago
    > just a bad language designed in 10 days that resists all attempts to make it not bad. This is unnecessarily inflammatory. I've been writing JavaScript since back when it was called LiveScript and while it's certainly not my vision of the perfect programming language, it's come a long way. The code I write now is considerably cleaner, easier and more reliable than the code I was writing in 2005, much less 1995.
  - nostrademons 11y ago
    It doesn't actually work on (GUI) OSes - there is a strong incentive to write your app in the language and framework that is native to the platform, because you're asking for a lot of pain and a substandard customer experience otherwise. You write your Windows apps in C# and .NET. You write your Android apps in Java. You write your iOS apps in Objective-C, and now Swift. You write your Gnome apps in C with Gtk+, and your KDE apps in C++ with Qt, and your Eclipse plugins in Java with SWT, and your Emacs extensions in Emacs Lisp. In all these cases (except Apple), you can write your apps in a different language, but virtually nobody does, because you end up fighting the platform. Servers and command-line tools are an exception because your interaction with the host platform is limited to a few dozen syscalls that can be easily bound to a number of different languages. Not so with most GUI software.
    - comex 11y ago
      (Including Apple; the rule to the contrary didn't last very long after its introduction a few years ago.)
    - 14paninta 11y ago
      It does work. Incentive is different than requirement. How else would MS ship the CLR for Mac OS X?
  - im3w1l 11y ago
    The web consists of untrusted code. Thus it needs to run in an a sandbox. Creating a secure and fast sandbox is an incredible undertaking.
  - bobajeff 11y ago
    I think the web is getting better in this regard. Since the introduction of emscripten and asm.js there have been some improvements to the tooling and runtime to make it so you can just write your app in C or C++ without really thinking about JavaScript. It's only a matter of time before other languages can have the same level of support.
    - BrendanEich 11y ago
      I think you are onto something ;-).
- 14paninta 11y ago
  > You mean like Firefox? Firefox is entirely written in JS? Or just the parts that fall within what JS can do? The JIT isn't JS. The TLS stack isn't JS. Most of the heavy lifting (e.g. the DOM) isn't JS.
- anon1385 11y ago
  >> Or, they could take their own medicine, and try and write the browser in JS. >You mean like Firefox? This is a very strange comment, especially coming from you. Everybody knows that the bulk of Firefox is not written in JS. You personally have spent years of your life working on a new programming language precisely because JS is not suitable for writing a web browser. I'll take your position on JS seriously when you abandon Rust and begin writing the bulk of Firefox in JS.
  - pcwalton 11y ago
    It would actually be a very interesting experiment to try running Servo Emscriptenified (with SharedArrayBuffer, of course). I wouldn't want to write a browser in the full JS language, but that's precisely what asm.js is for. "You should abandon Rust and write in JS" presupposes exactly the kind of strawman I've been arguing against. You don't have to abandon your favorite language!
TazeTSchnitzel 11y ago
> Just let me know when browser vendors are going to break down the two-tiered system, and let us run the legion of alternatives alongside -- instead of under -- JavaScript. Just let me know when Intel, AMD and VIA are going to break down the two-tiered system, and let us run the legion of alternatives alongside -- instead of under -- x86 assembly language.
- 14paninta 11y ago
  What does that even mean? It's nonsensical. Underneath x86 assembly language is the processor microcode, and underneath that is the actual hardware, and the two are intricately intertwined. You can replace the hardware; C compiles, for example, to everything from ARM to x86 to Atmel's AVR harvard architecture. You can replace the language; everything from C to Swift to Rust can target almost any processor architecture, without externally enforced limitations. Microsoft can ship the CLR for ARM, x86, PowerPC. You can't replace JavaScript. Everything must pass through a JS JIT, and the JS JIT is written using functionality that 1) it requires, and 2) is totally unavailable to you. Microsoft can't ship a fully functioning CLR for JS.
- TazeTSchnitzel 11y ago
  14paninta replied to this, but their comment's dead (shadowban?) - anyway, I'll repost it here and respond to it. > What does that even mean? It's nonsensical. What it means is that the situation with browsers is not much different from the situation on native platforms. CPUs support one language, the browser supports one language. And yet I don't see anyone complain about CPUs only supporting one language, because you can compile anything to it. The same is true for JS, so why do people complain? >Underneath x86 assembly language is the processor microcode, and underneath that is the actual hardware, and the two are intricately intertwined. Underneath JavaScript is native code produced by a JIT compiler. It's not super-intricately intertwined with the underlying OS and hardware, but it's not incredibly abstract either. >You can replace the hardware; C compiles, for example, to everything from ARM to x86 to Atmel's AVR harvard architecture. >You can replace the language; everything from C to Swift to Rust can target almost any processor architecture, without externally enforced limitations. You can also retarget stuff compiling to JS to compile to something else, like Lua. >Microsoft can ship the CLR for ARM, x86, PowerPC. > You can't replace JavaScript. Everything must pass through a JS JIT, and the JS JIT is written using functionality that 1) it requires, and 2) is totally unavailable to you. Yes, everything must pass through a JS JIT... you don't have access to the underlying native code. But everything on a CPU must pass through its microcode translator. That uses functionality it requires which is unavailable to you. > Microsoft can't ship a fully functioning CLR for JS. This simply isn't true. You can write a CLR for JS that compiles to something like asm.js at runtime. Bytecode VMs with JIT compilation have been written in JS before, see Emterpreter for instance.
ender7 11y ago
Chrome was trying to do this: https://developer.chrome.com/native-client https://developer.chrome.com/native-client However, cries of foul "vendor lockin" erupted. So I dunno what to tell you, man.
- TazeTSchnitzel 11y ago
  ...no they weren't? They let you embed native code (platform-specific) or LLVM IR (vendor-specific) into a webpage. I don't see what that has to do with support for other languages. Anything NaCl can do, asm.js can do too, but one of these has multiple implementations, is backwards-compatible, is truly cross-platform, is well-specified, and is standardised. (Hint: it's not the first one.)
  - 14paninta 11y ago
    asm.js doesn't support threading. it can't run native code. it doesn't support meaningful debugging. it doesn't have a post-DOM API surface like pepper.
  - cwyers 11y ago
    I think you're right that they weren't trying to do this with NaCl. They really were trying to do this with Dart, though.
    - TazeTSchnitzel 11y ago
      Well, Dart would've been one other language in the browser, sure. But it's a language not that different from JavaScript in actuality. The benefits seem few for the work needed to support two different languages. Compiling to JS, which fits Dart quite well (probably because it was designed to compile to JS well), seems more productive to me. Some were excited Dart might lead to some sort of bytecode VM being added, but that didn't lead anywhere. And since then, JS has become more bytecode-like, so it doesn't really matter now anyway.
      - tosh 11y ago
rjsw 11y ago
Internet Explorer had a pretty clean API for adding extra scripting languages.
- TazeTSchnitzel 11y ago
  Yes, the Windows Script Host. But I don't believe two languages could very effectively talk to eachother, right? Couldn't they only really interact with the native code stuff (DOM etc.), i.e. the easy part?
  - rjsw 11y ago
    It wasn't too difficult to add an interface to COM from a new language, that seemed the easiest way to call "out" to something else.
- tracker1 11y ago
  And in practice, that separation layer lead to objects tied together across COM boundaries, and severe memory leaks for any significant applications.
sqren 11y ago
> Or, they could take their own medicine, and try and write the browser in JS. Like Blink-in-JavaScript[0] ? ;) [0] https://www.chromium.org/blink/blink-in-js https://www.chromium.org/blink/blink-in-js

pcwalton 11y ago

> Just let me know when browser vendors are going to break down the two-tiered system, and let us run those myriad of alternatives alongside -- instead of under -- JavaScript. The complexity of doing that would be needlessly high compared to just improving JavaScript. Having to integrate a C++ DOM with a JS DOM is hard enough. Think about how you handle cross-language cycles… > Or, they could take their own medicine, and try and write the browser in JS. You mean like Firefox?

mattmanser 11y ago
Works on OSes. We have a choice. In browsers, the OSes of the web, nope, just a bad language designed in 10 days that resists all attempts to make it not bad. It doesn't really matter if you like javascript, there's so many people who don't. Why do you get to dictate whether we can or can't develop on the web? You leave us with a horrible choice, use what we consider to be one of the worst modern languages, or not develop. Why do you get to make our professional lives miserable?
- pcwalton 11y ago
  > Works on OSes. We have a choice. The kernel doesn't have a DOM. On the Web, the number of GC'd objects that every "process" has to deal with exceeds the number of file descriptors by an order of magnitude. Also, you do have a choice: you can compile your favorite language to JS, even low-level ones via asm.js. > Why do you get to dictate whether we can or can't develop on the web? You leave us with a horrible choice, use what we consider to be one of the worst modern languages, or not develop. Why do you get to make our professional lives miserable? That's not the choice: you can compile your favorite language to JavaScript. That's what source maps, asm.js, and the like are for. And JS is being improved all the time; it's not static. Trying to add another language has been tried multiple times and has always failed, because having two languages that both interact with the DOM is much more difficult than just improving JS.
  - ForHackernews 11y ago
    Semi-serious question: Other than backwards compatibility, do browsers need to have a DOM? It seems like many web app devs spend more time fighting against the DOM than working with it. Why not just make the browser expose a generic GUI model? Let web devs interact with Webkit or QT directly?
    - nostrademons 11y ago
      Generic GUI toolkits are very often worse than the DOM. I've worked with Swing, MFC, SWT, Android, and iOS, and all of them are significantly more complicated than the DOM is. They do function at a higher level of abstraction, and the two really nice things they give you are components and a sane layout system (solved by WebComponents and Flexbox, now if only all the major browser vendors would just adopt WebComponents...), but in general I've found that iOS development is about 1.5x-2x slower than web development and native Android development is about 3x slower, roughly on par with Swing or SWT. MFC was a clusterfuck, I wouldn't even go there. The way frontend devs for other platforms deal with it is to specialize in the nuances of the platform and effectively build your app around the capabilities that Google/Apple/Microsoft/Sun provide. That's fine, and makes for a fairly uniform, polished experience if you have good devs, but it significantly restricts the set of apps you can build. The reason web developers like developing for the web is because it doesn't make you a sharecropper in Google/Apple/Microsoft's world, while building a full-featured GUI framework into the browser would.
      - bitL 11y ago
        I still remember how super easy and fast was to make a GUI in Delphi/C++ Builder - what took a month in MFC/Swing took about an hour in Delphi. Even Qt feels like a massive step back from this...
      - wbillingsley 11y ago
        I've found JavaFX's scenegraph approach rather neat. Effectively it borrows from HTML, but where the basic node set is designed to be UI elements rather than co-opting a set that was designed for text documents. It seems to take a surprisingly small amount of code to sketch up an interface. React's not bad on the web side (especially with Scala.js) but fudging around layouts in components with divs and Bootstrap still feels clunky.
- TazeTSchnitzel 11y ago
  > Works on OSes. We have a choice. No, it doesn't work on OSes. OSes only handle one language: the native machine code of that platform. Everything else must be compiled to it. This is exactly the same as browsers. Edit: At least two people disagree with me (-1 points) - would you mind elaborating why?
  - serge2k 11y ago
    Your point is irrelevant, then difference then becomes the fact that at an OS level I can choose what code I compile into machine code and in the browser I can't.
    - TazeTSchnitzel 11y ago
      > Your point is irrelevant, then difference then becomes the fact that at an OS level I can choose what code I compile into machine code and in the browser I can't. Uh, what? You do have a choice in the browser. I don't understand.
    - eccenux 11y ago
      No, for OS you decide which compilator to choose. As is with browsers. There are several languages (e.g. TypeScript, CoffeeScript, Dart) which can be compiled to JS. That is not what I personally like (the processes of compilation and deployment I mean), but if you develop for OS then you have to compile before you run... In most OS.
- acdha 11y ago
  > just a bad language designed in 10 days that resists all attempts to make it not bad. This is unnecessarily inflammatory. I've been writing JavaScript since back when it was called LiveScript and while it's certainly not my vision of the perfect programming language, it's come a long way. The code I write now is considerably cleaner, easier and more reliable than the code I was writing in 2005, much less 1995.
- nostrademons 11y ago
  It doesn't actually work on (GUI) OSes - there is a strong incentive to write your app in the language and framework that is native to the platform, because you're asking for a lot of pain and a substandard customer experience otherwise. You write your Windows apps in C# and .NET. You write your Android apps in Java. You write your iOS apps in Objective-C, and now Swift. You write your Gnome apps in C with Gtk+, and your KDE apps in C++ with Qt, and your Eclipse plugins in Java with SWT, and your Emacs extensions in Emacs Lisp. In all these cases (except Apple), you can write your apps in a different language, but virtually nobody does, because you end up fighting the platform. Servers and command-line tools are an exception because your interaction with the host platform is limited to a few dozen syscalls that can be easily bound to a number of different languages. Not so with most GUI software.
  - comex 11y ago
    (Including Apple; the rule to the contrary didn't last very long after its introduction a few years ago.)
  - 14paninta 11y ago
    It does work. Incentive is different than requirement. How else would MS ship the CLR for Mac OS X?
- im3w1l 11y ago
  The web consists of untrusted code. Thus it needs to run in an a sandbox. Creating a secure and fast sandbox is an incredible undertaking.
- bobajeff 11y ago
  I think the web is getting better in this regard. Since the introduction of emscripten and asm.js there have been some improvements to the tooling and runtime to make it so you can just write your app in C or C++ without really thinking about JavaScript. It's only a matter of time before other languages can have the same level of support.
  - BrendanEich 11y ago
    I think you are onto something ;-).
14paninta 11y ago
> You mean like Firefox? Firefox is entirely written in JS? Or just the parts that fall within what JS can do? The JIT isn't JS. The TLS stack isn't JS. Most of the heavy lifting (e.g. the DOM) isn't JS.
anon1385 11y ago
>> Or, they could take their own medicine, and try and write the browser in JS. >You mean like Firefox? This is a very strange comment, especially coming from you. Everybody knows that the bulk of Firefox is not written in JS. You personally have spent years of your life working on a new programming language precisely because JS is not suitable for writing a web browser. I'll take your position on JS seriously when you abandon Rust and begin writing the bulk of Firefox in JS.
- pcwalton 11y ago
  It would actually be a very interesting experiment to try running Servo Emscriptenified (with SharedArrayBuffer, of course). I wouldn't want to write a browser in the full JS language, but that's precisely what asm.js is for. "You should abandon Rust and write in JS" presupposes exactly the kind of strawman I've been arguing against. You don't have to abandon your favorite language!

TazeTSchnitzel 11y ago

> Just let me know when browser vendors are going to break down the two-tiered system, and let us run the legion of alternatives alongside -- instead of under -- JavaScript. Just let me know when Intel, AMD and VIA are going to break down the two-tiered system, and let us run the legion of alternatives alongside -- instead of under -- x86 assembly language.

14paninta 11y ago
What does that even mean? It's nonsensical. Underneath x86 assembly language is the processor microcode, and underneath that is the actual hardware, and the two are intricately intertwined. You can replace the hardware; C compiles, for example, to everything from ARM to x86 to Atmel's AVR harvard architecture. You can replace the language; everything from C to Swift to Rust can target almost any processor architecture, without externally enforced limitations. Microsoft can ship the CLR for ARM, x86, PowerPC. You can't replace JavaScript. Everything must pass through a JS JIT, and the JS JIT is written using functionality that 1) it requires, and 2) is totally unavailable to you. Microsoft can't ship a fully functioning CLR for JS.
TazeTSchnitzel 11y ago
14paninta replied to this, but their comment's dead (shadowban?) - anyway, I'll repost it here and respond to it. > What does that even mean? It's nonsensical. What it means is that the situation with browsers is not much different from the situation on native platforms. CPUs support one language, the browser supports one language. And yet I don't see anyone complain about CPUs only supporting one language, because you can compile anything to it. The same is true for JS, so why do people complain? >Underneath x86 assembly language is the processor microcode, and underneath that is the actual hardware, and the two are intricately intertwined. Underneath JavaScript is native code produced by a JIT compiler. It's not super-intricately intertwined with the underlying OS and hardware, but it's not incredibly abstract either. >You can replace the hardware; C compiles, for example, to everything from ARM to x86 to Atmel's AVR harvard architecture. >You can replace the language; everything from C to Swift to Rust can target almost any processor architecture, without externally enforced limitations. You can also retarget stuff compiling to JS to compile to something else, like Lua. >Microsoft can ship the CLR for ARM, x86, PowerPC. > You can't replace JavaScript. Everything must pass through a JS JIT, and the JS JIT is written using functionality that 1) it requires, and 2) is totally unavailable to you. Yes, everything must pass through a JS JIT... you don't have access to the underlying native code. But everything on a CPU must pass through its microcode translator. That uses functionality it requires which is unavailable to you. > Microsoft can't ship a fully functioning CLR for JS. This simply isn't true. You can write a CLR for JS that compiles to something like asm.js at runtime. Bytecode VMs with JIT compilation have been written in JS before, see Emterpreter for instance.

ender7 11y ago

Chrome was trying to do this: https://developer.chrome.com/native-client https://developer.chrome.com/native-client However, cries of foul "vendor lockin" erupted. So I dunno what to tell you, man.

TazeTSchnitzel 11y ago
...no they weren't? They let you embed native code (platform-specific) or LLVM IR (vendor-specific) into a webpage. I don't see what that has to do with support for other languages. Anything NaCl can do, asm.js can do too, but one of these has multiple implementations, is backwards-compatible, is truly cross-platform, is well-specified, and is standardised. (Hint: it's not the first one.)
- 14paninta 11y ago
  asm.js doesn't support threading. it can't run native code. it doesn't support meaningful debugging. it doesn't have a post-DOM API surface like pepper.
- cwyers 11y ago
  I think you're right that they weren't trying to do this with NaCl. They really were trying to do this with Dart, though.
  - TazeTSchnitzel 11y ago
    Well, Dart would've been one other language in the browser, sure. But it's a language not that different from JavaScript in actuality. The benefits seem few for the work needed to support two different languages. Compiling to JS, which fits Dart quite well (probably because it was designed to compile to JS well), seems more productive to me. Some were excited Dart might lead to some sort of bytecode VM being added, but that didn't lead anywhere. And since then, JS has become more bytecode-like, so it doesn't really matter now anyway.
    - tosh 11y ago

rjsw 11y ago

Internet Explorer had a pretty clean API for adding extra scripting languages.

TazeTSchnitzel 11y ago
Yes, the Windows Script Host. But I don't believe two languages could very effectively talk to eachother, right? Couldn't they only really interact with the native code stuff (DOM etc.), i.e. the easy part?
- rjsw 11y ago
  It wasn't too difficult to add an interface to COM from a new language, that seemed the easiest way to call "out" to something else.
tracker1 11y ago
And in practice, that separation layer lead to objects tied together across COM boundaries, and severe memory leaks for any significant applications.

sqren 11y ago

> Or, they could take their own medicine, and try and write the browser in JS. Like Blink-in-JavaScript[0] ? ;) [0] https://www.chromium.org/blink/blink-in-js https://www.chromium.org/blink/blink-in-js