4 ms·

Isn't this problem solved by having HTML/JS/CSS as a compile target, which is what we are heading to now, with languages and technologies like CoffeeScript, Pur

by wz1000 11y ago

Isn't this problem solved by having HTML/JS/CSS as a compile target, which is what we are heading to now, with languages and technologies like CoffeeScript, PureScript, Elm, ClojureScript, ghcjs, emscripten etc. Even on the backend, in the end you have to run native machine instructions. HTML/JS/CSS substitute for that on the front end. Of course, x86_64 may be a better compile target, but the advantage of the existing languages over any new system is that there has been a lot of work that has already gone into making them fast, backwards compatibility, all browsers already implement them, and there are a lot of things that can target them now. See also: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

crimsonalucard 11y ago
Personally to me that's "ugh." HTML and CSS as a compile target? What's the lowest level primitive in html? A div? A span? ew. It should be compiled to something that has access to primitives such as lines, polygons or pixels. Compiling to js is ok as that language is as close to the metal as you can get on a vm anyway. So long as performance isn't affected then it's really no different to the developer. Still the platform would be more elegant if it didn't compile to some intermediary high level language.
- vonkow 11y ago
  Access to primitives such as lines, polygons or pixels, you say? Canvas, SVG, and WebGL fit that bill.
  - crimsonalucard 11y ago
    Sure. And I know about these. The original poster was talking about languages with HTML+CSS+JAVASCRIPT as compile targets, not canvas, svg or webgl. I'm simply addressing his comment. Either way, WebGL/canvas operate as child elements in an html page, you still need to use javascript, and SVG isn't GPU accelerated. It's still, overall, an ugly mess. But definitely, with improvements, canvas, svg and webgl are all candidates for my aforementioned "next steps."
- _RPM 11y ago
  > Compiling to js is ok as that language is as close to the metal as you can get on a vm anyway JavaScript is as low as the metal you can get in a Virtual Machine? hmm...
  - crimsonalucard 11y ago
    Of course you can go lower, but there will be sacrifices. Brendan Eich actually addressed this same topic in response to some other thread I started a while back. I quote him below: "Apart from syntax wins, you can't get much lower-level semantically and keep both safety and linear-time verifiability. Java bytecode with unrestricted goto and type confusion at join points makes for O(n^4) verification complexity. asm.js type checking is linear. New and more concise syntax may come, but it's not a priority (gzip helps a lot), and doing it early makes two problem-kids to feed (JS as source language; new syntax for asm.js), which not only costs more but can make for divergence and can overconstrain either child. (This bit Java, pretty badly.)"
  - reagency 11y ago
    asm.JS carries you rather close to bare metal.
- pron 11y ago
  You need HTML for search.
- Houshalter 11y ago
  How is it that much different than using OS APIs to do common tasks like text, windows, buttons, scroll bars, etc? If you really want to do pixel level stuff, there is canvases and images and SVGs.
  - crimsonalucard 11y ago
    How would I replace html in the browser? Create a new rendering api in canvas? Can it be done? Sure. Will it be pretty? Not so sure. Imagine your operating system can only compile one single language: Perl. And with perl the only way you can render anything on the screen is with a QT api and QT UI primitives. Programmers can still do anything within this ecosystem. Technically you can have perl as compile targets for any other language. Lets also pretend that QT has this little UI element called canvas that has a api allowing you pixel level control. While technically you could do anything in a platform like the one I described above, I'm sure you can easily see why it's still bad.
afarrell 11y ago
> HTML/JS/CSS as a compile target That only works if your abstractions don't leak and your libraries are stable enough so that you can avoid having to debug on the lower level anyway.

by wz1000 11y ago

crimsonalucard 11y ago

Personally to me that's "ugh." HTML and CSS as a compile target? What's the lowest level primitive in html? A div? A span? ew. It should be compiled to something that has access to primitives such as lines, polygons or pixels. Compiling to js is ok as that language is as close to the metal as you can get on a vm anyway. So long as performance isn't affected then it's really no different to the developer. Still the platform would be more elegant if it didn't compile to some intermediary high level language.

vonkow 11y ago
Access to primitives such as lines, polygons or pixels, you say? Canvas, SVG, and WebGL fit that bill.
- crimsonalucard 11y ago
  Sure. And I know about these. The original poster was talking about languages with HTML+CSS+JAVASCRIPT as compile targets, not canvas, svg or webgl. I'm simply addressing his comment. Either way, WebGL/canvas operate as child elements in an html page, you still need to use javascript, and SVG isn't GPU accelerated. It's still, overall, an ugly mess. But definitely, with improvements, canvas, svg and webgl are all candidates for my aforementioned "next steps."
_RPM 11y ago
> Compiling to js is ok as that language is as close to the metal as you can get on a vm anyway JavaScript is as low as the metal you can get in a Virtual Machine? hmm...
- crimsonalucard 11y ago
  Of course you can go lower, but there will be sacrifices. Brendan Eich actually addressed this same topic in response to some other thread I started a while back. I quote him below: "Apart from syntax wins, you can't get much lower-level semantically and keep both safety and linear-time verifiability. Java bytecode with unrestricted goto and type confusion at join points makes for O(n^4) verification complexity. asm.js type checking is linear. New and more concise syntax may come, but it's not a priority (gzip helps a lot), and doing it early makes two problem-kids to feed (JS as source language; new syntax for asm.js), which not only costs more but can make for divergence and can overconstrain either child. (This bit Java, pretty badly.)"
- reagency 11y ago
  asm.JS carries you rather close to bare metal.
pron 11y ago
You need HTML for search.
Houshalter 11y ago
How is it that much different than using OS APIs to do common tasks like text, windows, buttons, scroll bars, etc? If you really want to do pixel level stuff, there is canvases and images and SVGs.
- crimsonalucard 11y ago
  How would I replace html in the browser? Create a new rendering api in canvas? Can it be done? Sure. Will it be pretty? Not so sure. Imagine your operating system can only compile one single language: Perl. And with perl the only way you can render anything on the screen is with a QT api and QT UI primitives. Programmers can still do anything within this ecosystem. Technically you can have perl as compile targets for any other language. Lets also pretend that QT has this little UI element called canvas that has a api allowing you pixel level control. While technically you could do anything in a platform like the one I described above, I'm sure you can easily see why it's still bad.

afarrell 11y ago

> HTML/JS/CSS as a compile target That only works if your abstractions don't leak and your libraries are stable enough so that you can avoid having to debug on the lower level anyway.