5 ms·

On the backend the developer chooses his universe. Whether it'd be ruby, python, mongo, postgresql, nodejs, haskell, go, whatever. If the universe sucks people

On the backend the developer chooses his universe. Whether it'd be ruby, python, mongo, postgresql, nodejs, haskell, go, whatever. If the universe sucks people can change everything. If you hate the mopho stack (mongo and php), that's ok, you got other options. With the browser everyone is stuck with one universe. The only thing that changes are front end frameworks which offer some flexibility. Still, if html sucks we're stuck with it. If you hate html or javascript then you hate the entire front end. You exist outside of that universe because Nothing can change it. End of story. I don't know how it could be done while keeping things secure, but it would be awesome if the browser universe was as flexible as the backend. If I could swap between html and any other kind of media based declarative language as easily as I can swap between python and ruby on the backend, it would change the face of frontend development and make it more accessible. In fact what if I wanted to develop my own language that interfaces with the rendering engine? The browser should permit that, because the Web is too broad to be dominated by a single language(HTML). I think this should be the next step.

isaiahg 11y ago
What would be really nice is something similar to .Net's virtual machine CLR. It would offer the flexibility to design in whatever language you want and possibly a performance boost as well.
- nerraga 11y ago
  That only addresses the language component though, right? You'd still be stuck with HTML and CSS. I'm okay with javascript although I'd love to see another language supported in a similar first class fashion. It's HTML and particularly CSS that feel too overloaded, document-centric, and just plain hacky. I think something a little closer to XAML, or possibly like AML, would be a great addition. It'd be great to have support for a responsive layout without having to deal with responsive design as it exists today (amazing as it is).
- Too 11y ago
  Java applets and Silverlight were attempts on this idea but both failed quite miserably. Not necessarily because the idea itself was bad, in the Java case the execution was bad and the .net case came in a time where moving away from flash was the latest trend and the fear of proprietary lockin from MS too high.
- sparkie 11y ago
  The CLR isn't really very flexible. Most languages that run on it are pretty similar. If you try to implement a language like Haskell on top of it for example, it quickly becomes obvious that it isn't a good fit - because the CLR has no support for higher kinds, typeclasses, laziness, parametric polymorphism etc. Sure, you can implement a Haskell interpreter/compiler that converts to .NET, but there certainly won't be any performance boost by boxing everything into objects and having several layers of indirection to simply invoke a function (and not really any advantage over writing such interpreter in say, JS). A more ideal VM would be one which doesn't force a particular paradigm on you, but just abstracts over the CPU, using capabilities to restrict which instructions can be invoked. The CLR lacks such capabilities. Perhaps something like SafeHaskell would be in the right direction, where side-effects are limited, and the user can optionally allow websites to invoke trusted modules.
  - jaen 11y ago
    A low-level safe VM? That exists with PNaCl (Portable Native Client), which of course everybody dislikes as a web technology.
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."
pg_is_a_butt 11y ago
how about don't return "text/html" as a response? you're more than welcome to send "application/pdf" instead, and then bitch about all the same problems with PDF. you don't have options on the front end, because you don't control the front end... your users do. you may think the browsers control the front end, because you're dumb, but it's the users who choose the browsers. you'd rather provide a native executable to your users that works to your elegant back end tastes? GOOD. now support every version of every OS every one of your users may ever use... and scramble to fix every one of those every week when moronic OS vendors break something else just to ruin your day. it's like people complaining about mansanto... if you have a better way to feed a billion people TODAY, go ahead and try, and come back for corn when you're broken.
MCRed 11y ago
> "If I could swap ... language as easily as I can swap between python and ruby on the backend, it would change the face of frontend development and make it more accessible. In fact what if I wanted to develop my own language that interfaces with the rendering engine?" I'm building this. I've been working on a side project that was my idea of the ideal internet platform, and for a long time I believed that the front end was a lost cause. I've recently figured out the solution. Had quite a eureka moment, in fact. This will be open source but it may be a startup and I'm not going to talk about it until I have a proof of concept... but let me give you an overview: -- Works on all browsers made since 2013ish -- You can do absolutely anything you want, in any language you want (though a bit of glue will be necessary to a lower level framework) -- Initially there will be a basic implementation on a well known and well supported development platform that will bring this close to WYSIWYG and let you write code in more than one language -- There is a spec for UI elements and you can throw out that initial implementation and write your own complete implementation. This is a non-trivial project, but much easier than creating a browser. -- The UI can be easily implemented in native forms for native applications. So the "page production code" can be the same for all platforms, web and native, and the "client" code merely translates into the local platforms UI elements (or re-creates the spec's UI elements when there isn't a mapping.) -- It might suck. This is highly experimental right now. -- It's no longer a side project, it's my full time obsession. If you're interested in this, follow: https://github.com/nirvana/nirvana https://github.com/nirvana/nirvana or @NirvanaCore on twitter. Or if email is your thing, check out http://nirvana.io http://nirvana.io (ignore what's in that repo right now, the work is happening elsewhere until it's usable for people to start building stuff with. At that point it will be easy enough to wrap your head around that outside contributions will be appreciated. I have a group of hackers I'm working with now, and it's clear things aren't far enough along... yet.)
- gbersac 11y ago
  Why not speaking about it ? It will give you contribution (you can refuse if you don't like it) and no one is going to steal your idea : https://news.ycombinator.com/item?id=9663203 https://news.ycombinator.com/item?id=9663203
  - 11y ago
tnorgaard 11y ago
Maybe we should listen to Alan Kay's proposal: https://youtu.be/FvmTSpJU-Xc?t=1082 https://youtu.be/FvmTSpJU-Xc?t=1082. It might be bad example, but if the Java SE runtime libraries was just a dependency like any other mvn artifact (module), Sun / Oracle would for example have been in a position to introduce immutability to the Collections framework and fix crazy other stuff[1] without breaking backward compatibility. But now we are stuck with those legacies forever[2], since they standardized on a too high level abstraction and choose fewer layers. For Java's, luckily they had layer underneath - JVM byte code, which is why I predict Java is still relevant for many years going forward. The next generation of WWW needs to a very low common abstraction, e.g. bytecode. Something similar to X Windows. [1] See Effective Java Puzzlers. [2] Project Jigsaw might change that.
- davidy123 11y ago
  You don't see the inherently 'open' nature of HTML and common accessories to be a huge benefit? Sure, they can get messy, but are still bound to be more parseable and tow people along to the transformative idea of a giant shared graph with dev tools (inspection) support, compared to byte streams. Over time Flash, Java applets and other approaches have come along but been deprecated, which I'd considered to be emblematic of searching for a more transparent information commons outside one technical requirement (even if the logical conclusion of a 'semantic web' has been elusive so far). The fact that "view source" is available in all major browsers is to me incredibly meaningful and positive compared to alternative visions. Or would your byte code blaster have similar properties?
  - tnorgaard 11y ago
    I think we can build it however closed or open we would like it to be. The sharing of source code I suspect is more social than technical, therefore I don't expect much change. Java Applets, Flash, SilverLight always was at a disadvantage, not being native to the browser runtime. Startup time and the need for a "plugin" hurt them. And they all kinda sucked in their own way. I hoped for a long time that Dart / native DartVM to Chrome could make a stride, but sadly they were fighting uphill battle against the sheer volume of JS developers resisting change. I'm convinced that it's never about the language[1], but the VM and it's abstraction layer. We need a layer that we can compile JavaScript(/HTML/CSS), Scala, Haskell, C#, F# etc. down to, not more languages. I wonder how many man-years has been wasted on vertically aligning div's inside a div. :) [1] Guy Steele, amazing talk on "Growing a Language", https://www.youtube.com/watch?v=_ahvzDzKdB0 https://www.youtube.com/watch?v=_ahvzDzKdB0
vatotemking 11y ago
So flash and silverlight?

isaiahg 11y ago

What would be really nice is something similar to .Net's virtual machine CLR. It would offer the flexibility to design in whatever language you want and possibly a performance boost as well.

nerraga 11y ago
That only addresses the language component though, right? You'd still be stuck with HTML and CSS. I'm okay with javascript although I'd love to see another language supported in a similar first class fashion. It's HTML and particularly CSS that feel too overloaded, document-centric, and just plain hacky. I think something a little closer to XAML, or possibly like AML, would be a great addition. It'd be great to have support for a responsive layout without having to deal with responsive design as it exists today (amazing as it is).
Too 11y ago
Java applets and Silverlight were attempts on this idea but both failed quite miserably. Not necessarily because the idea itself was bad, in the Java case the execution was bad and the .net case came in a time where moving away from flash was the latest trend and the fear of proprietary lockin from MS too high.
sparkie 11y ago
The CLR isn't really very flexible. Most languages that run on it are pretty similar. If you try to implement a language like Haskell on top of it for example, it quickly becomes obvious that it isn't a good fit - because the CLR has no support for higher kinds, typeclasses, laziness, parametric polymorphism etc. Sure, you can implement a Haskell interpreter/compiler that converts to .NET, but there certainly won't be any performance boost by boxing everything into objects and having several layers of indirection to simply invoke a function (and not really any advantage over writing such interpreter in say, JS). A more ideal VM would be one which doesn't force a particular paradigm on you, but just abstracts over the CPU, using capabilities to restrict which instructions can be invoked. The CLR lacks such capabilities. Perhaps something like SafeHaskell would be in the right direction, where side-effects are limited, and the user can optionally allow websites to invoke trusted modules.
- jaen 11y ago
  A low-level safe VM? That exists with PNaCl (Portable Native Client), which of course everybody dislikes as a web technology.

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

pg_is_a_butt 11y ago

how about don't return "text/html" as a response? you're more than welcome to send "application/pdf" instead, and then bitch about all the same problems with PDF. you don't have options on the front end, because you don't control the front end... your users do. you may think the browsers control the front end, because you're dumb, but it's the users who choose the browsers. you'd rather provide a native executable to your users that works to your elegant back end tastes? GOOD. now support every version of every OS every one of your users may ever use... and scramble to fix every one of those every week when moronic OS vendors break something else just to ruin your day. it's like people complaining about mansanto... if you have a better way to feed a billion people TODAY, go ahead and try, and come back for corn when you're broken.

MCRed 11y ago

> "If I could swap ... language as easily as I can swap between python and ruby on the backend, it would change the face of frontend development and make it more accessible. In fact what if I wanted to develop my own language that interfaces with the rendering engine?" I'm building this. I've been working on a side project that was my idea of the ideal internet platform, and for a long time I believed that the front end was a lost cause. I've recently figured out the solution. Had quite a eureka moment, in fact. This will be open source but it may be a startup and I'm not going to talk about it until I have a proof of concept... but let me give you an overview: -- Works on all browsers made since 2013ish -- You can do absolutely anything you want, in any language you want (though a bit of glue will be necessary to a lower level framework) -- Initially there will be a basic implementation on a well known and well supported development platform that will bring this close to WYSIWYG and let you write code in more than one language -- There is a spec for UI elements and you can throw out that initial implementation and write your own complete implementation. This is a non-trivial project, but much easier than creating a browser. -- The UI can be easily implemented in native forms for native applications. So the "page production code" can be the same for all platforms, web and native, and the "client" code merely translates into the local platforms UI elements (or re-creates the spec's UI elements when there isn't a mapping.) -- It might suck. This is highly experimental right now. -- It's no longer a side project, it's my full time obsession. If you're interested in this, follow: https://github.com/nirvana/nirvana https://github.com/nirvana/nirvana or @NirvanaCore on twitter. Or if email is your thing, check out http://nirvana.io http://nirvana.io (ignore what's in that repo right now, the work is happening elsewhere until it's usable for people to start building stuff with. At that point it will be easy enough to wrap your head around that outside contributions will be appreciated. I have a group of hackers I'm working with now, and it's clear things aren't far enough along... yet.)

gbersac 11y ago
Why not speaking about it ? It will give you contribution (you can refuse if you don't like it) and no one is going to steal your idea : https://news.ycombinator.com/item?id=9663203 https://news.ycombinator.com/item?id=9663203
- 11y ago

tnorgaard 11y ago

Maybe we should listen to Alan Kay's proposal: https://youtu.be/FvmTSpJU-Xc?t=1082 https://youtu.be/FvmTSpJU-Xc?t=1082. It might be bad example, but if the Java SE runtime libraries was just a dependency like any other mvn artifact (module), Sun / Oracle would for example have been in a position to introduce immutability to the Collections framework and fix crazy other stuff[1] without breaking backward compatibility. But now we are stuck with those legacies forever[2], since they standardized on a too high level abstraction and choose fewer layers. For Java's, luckily they had layer underneath - JVM byte code, which is why I predict Java is still relevant for many years going forward. The next generation of WWW needs to a very low common abstraction, e.g. bytecode. Something similar to X Windows. [1] See Effective Java Puzzlers. [2] Project Jigsaw might change that.

davidy123 11y ago
You don't see the inherently 'open' nature of HTML and common accessories to be a huge benefit? Sure, they can get messy, but are still bound to be more parseable and tow people along to the transformative idea of a giant shared graph with dev tools (inspection) support, compared to byte streams. Over time Flash, Java applets and other approaches have come along but been deprecated, which I'd considered to be emblematic of searching for a more transparent information commons outside one technical requirement (even if the logical conclusion of a 'semantic web' has been elusive so far). The fact that "view source" is available in all major browsers is to me incredibly meaningful and positive compared to alternative visions. Or would your byte code blaster have similar properties?
- tnorgaard 11y ago
  I think we can build it however closed or open we would like it to be. The sharing of source code I suspect is more social than technical, therefore I don't expect much change. Java Applets, Flash, SilverLight always was at a disadvantage, not being native to the browser runtime. Startup time and the need for a "plugin" hurt them. And they all kinda sucked in their own way. I hoped for a long time that Dart / native DartVM to Chrome could make a stride, but sadly they were fighting uphill battle against the sheer volume of JS developers resisting change. I'm convinced that it's never about the language[1], but the VM and it's abstraction layer. We need a layer that we can compile JavaScript(/HTML/CSS), Scala, Haskell, C#, F# etc. down to, not more languages. I wonder how many man-years has been wasted on vertically aligning div's inside a div. :) [1] Guy Steele, amazing talk on "Growing a Language", https://www.youtube.com/watch?v=_ahvzDzKdB0 https://www.youtube.com/watch?v=_ahvzDzKdB0

vatotemking 11y ago

So flash and silverlight?