7 ms·

Instead of yet another .js to run * in the browser, maybe we should return the web and browser back to it's pure days of marked up text documents with images an

Instead of yet another .js to run * in the browser, maybe we should return the web and browser back to it's pure days of marked up text documents with images and move "web apps" to a generalized, native runtime designed explicitly to run dynamically fetched untrusted code. Might be better than the current mess. Edit: And to all those thinking "but that's the browser", that's my point. We have the browser and while it works, it's incredibly broken in a lot of ways. I'm proposing a system designed from the ground up to do the job that the browser has currently been hacked and add-on'd into doing.

RussianCow 11y ago
I think WebAssembly is more or less going to solve this problem in the long run.
pjmlp 11y ago
Maybe WebAssembly and WebComponents will finally fix this. However I started to feel the same way a few years ago when the HTML 5 wave started, after several years of doing web development as well.
Yahivin 11y ago
> a generalized, native runtime designed explicitly to run dynamically fetched untrusted code. You mean like a browser?
- sdegutis 11y ago
  Browsers have evolved into exactly what people wanted Java for all along. Except it evolved from the wrong base. Kind of like if an elephant evolved to have intelligence and communication like ours instead of monkeys. That's pretty much the DOM & JS.
  - djsumdog 11y ago
    When you look at browsers, web, html, http ... the whole stack. It's pretty horrible. How did we get to this point? ...could be worse. At least it's not E-mail.
    - alexro 11y ago
      >> It's pretty horrible. How did we get to this point? Because ads... are more important to get right than other stuff /sarcasm
    - tracker1 11y ago
      There's always Notes.. ;-) Honestly, I don't think the browser is so bad. And once wasm takes hold and tooling catches up, you'll have lots of options.
- corndoge 11y ago
  Yeah, except not completely broken with shit like "let's run python in the browser with javascript!" and "let's animate UI components originally designed to be static with an overloaded scripting language!" and a million other things. The browser and web were originally designed to view webpages (read documents) and not run arbitrary untrusted code... tl;dr you are making the point I refuted in my original post.
smacktoward 11y ago
You mean like Flash and Java?
- samfisher83 11y ago
  Its ironic.
  - coldtea 11y ago
    No, he means a properly done sandbox but native and 2D accelerated platform without the DOM cruft. Not sure why it's so hard, probably because it's in nobody's interests but the users (as every major just wants to promote their own platform and have the web play second fiddle to it).
    - zbyte64 11y ago
      So like a canvas element then?
      - coldtea 11y ago
        In the sense that Cocoa or Windows top level window hierarchy is also like a "canvas element". In other words, like a canvas element which has a full, comprehensive, standard UI library with tons of standard, pre-built widgets (not just the meagre web form controls), including a full featured text widget with all the trimmings, plus a free drawing component of its own (for totally custom UIs and controls).
    - wtetzner 11y ago
      Doesn't sound so different from Java applets.
      - coldtea 11y ago
        The core concept, maybe. Then again, a top tier BMW doesn't sound so different than an Edsel either. They both have internal combustion engines, 4 wheels, a steering wheel, and they take you from place A to place B in similar speeds (in orders of magnitude). That's because you're focusing on the similarities which don't say anything -- what's important in all cases are the differences. Which in this case are mostly about the implementation. - the UI wouldn't be a part of a page, it would be THE page. - it shouldn't be an over-engineered mess of a GUI toolkit like Swing. - it should offer modern and capable widgets, instead of the bizarro, limited and uncanny value one's that Swing offers (if you don't get into intricate customization of your own). - it should be faster than the web app it replaces -- applets were often slow to load AND slow to run. - it shouldn't be controller by a single company. - it shouldn't be proprietary. - it should, if possible, cater to many programming languages. - it should play natively with the HTTP model, AJAX etc.
jnowlan 11y ago
While I completely agree, since it will never happen, why not strip javascript out of a browser (FF?), come up with a new catchy name, and market it as a safe browser. Just need a catchy name..., hmm, maybe Lynx? ;
- AdmiralACK 11y ago
  Links, perhaps...
  - ciupicri 11y ago
    Links used to support JavaScript some time ago [1]. [1]: http://links.twibright.com/user_en.html#ap-javascript http://links.twibright.com/user_en.html#ap-javascript
- TazeTSchnitzel 11y ago
  NetSurf?
- eeZi 11y ago
  Lynx actually had its fair share of vulnerabilities due to bugs in the parsing code. Ain't that easy.
jdc 11y ago
I agree that there is a mess, but what kind of mess is it? What about it makes it a mess? Is perhaps because the JS interpreter is embedded (the DOM calls it)? Is it that the DOM is poorly suited for what we used to call "rich" internet applications? Or is it Javascript itself that is the problem?
- michaelmcmillan 11y ago
  For starters, the DOM API is horrible.
  - jdc 11y ago
    Beyond the unpleasant experience of using it, what is actually wrong with it?
    - lqdc13 11y ago
      Very easy to have all kinds of memory leaks right now for one. It is really a combination of Javascript and the DOM. Unpleasant to use is definitely a big thing too. If it was easy and pleasant, nobody would complain.
      - zbyte64 11y ago
        Given any abstraction on a turing machine you will find it is easy to have memory leaks.
      - bzbarsky 11y ago
        Is it really easier to have memory leaks here than in any other garbage-collected language with first-class functions and closures? If you stick references to objects somewhere permanent, you will leak them. If you don't, you won't....
        lqdc13 11y ago
        Ok, it's not that simple: http://www.javascriptkit.com/javatutors/closuresleak/index3.shtml http://www.javascriptkit.com/javatutors/closuresleak/index3.... The last example is a good demonstration that. Sure, at the end of the day it's all about not cleaning the references. All I'm saying is that it is super easy to accidentally not clean the references. In other languages or even in javascript itself without the DOM, it's not nearly that easy.
nbadg 11y ago
I think taking this sentiment to its conclusion is a bit more of a drastic change than that. It would mean the end of the web, not a return to its beginnings. You wouldn't be dealing with marked-up text, you'd be dealing with binary files (text markup, of course, being a subset thereof). The internet (and whatever emerged on top of it to replace the web) would then be concerned with content, sharing, and identity management only, and applications would be built on top of that.[1] The trick, as you said, is how to securely run untrusted code. That's what the web (well, I suppose more technically, browsers) are trying to solve; the problem is that the same origin policy, which is at the core of web security, just doesn't work very well. There are a lot of examples where this breaks; here are three off the top of my head: 1. Tracking using javascript to look for unique browser identifiers 2. XSS, CSRF, etc 3. Legitimate cross-site communication So clearly our existing solution to the "how do you securely execute dynamic, untrusted code" problem isn't cutting it. There's a lot of research (and production code, for the record) going into potentially better approaches though, so I think it's likely we'll see change, if we can get past the inertia behind today's hairball. [1] Incidentally this is exactly the approach we're taking with implementations of the Muse protocol (https://github.com/Muterra/doc-muse https://github.com/Muterra/doc-muse), which uses encryption to provide private content/sharing/identity management on untrusted servers.
vegabook 11y ago
seems like the browser is becoming another virtual machine.
bobajeff 11y ago
>maybe we should return the web and browser back to it's pure days of marked up text documents with images Good luck with that. You should bring back Gopher while you're at it.
- swiley 11y ago
  Honestly, Gopher is clean and pleasant.
- endgame 11y ago
  That would be fantastic.
haberman 11y ago
What you're describing is exactly what Java Applets were designed to do 20 years ago. And yet they never achieved a fraction of what "the current mess" has achieved.
- dTal 11y ago
  As a communications platform, sure. As an application platform, I'm not sure I agree. I have used many actual applications packaged as .jar files. They're generally more featureful and performant than we have come to expect from web apps[1]. As a platform-independent, single-file distribution format, Java actually works very well. Java wasn't ever intended to compete with the Web; it was the Web that got ideas. [1] I know, citation needed. Okay. Show me the web app that looks like this, that doesn't kill my EeePC: https://upload.wikimedia.org/wikipedia/commons/2/27/Gephi-07beta-screenshot.png https://upload.wikimedia.org/wikipedia/commons/2/27/Gephi-07...
- AlphaSite 11y ago
  Honestly, the things people did with applets probably haven't been replicated by JS in the browser, especially when native got involved (if I'm remembering correctly).
- warbiscuit 11y ago
  I think java apps failed to achieve more mainly because they didn't have decent access to the DOM, and the HTML rendering engine that goes with it. IMHO that's the killer app of the browser... for all it's faults, the HTML+CSS rendering engine is a superior UI description api than anything previously devised. I remember the brief period I wrote some java apps. The main pain was choosing between rendering a native java gui, or establishing hooks to have it instrument an html interface from behind the scenes. The native gui had better connection to the code... whereas using the DOM was insanely flexible, but talking to the DOM was like trying to drive a car by reaching through the tailpipe. That I think is why java apps never prospered (outside of the whole "loading" issue... which could have been optimized away if the motivation was there). --- JS currently has the best of both worlds, and not because of anything native to the language (though it does have many positive points). I feel like WebAssembly, and things like PyPy.js, are a step in the right direction. Making the DOM and HTML+CSS just another ui library available to the language of the moment. Having PyPy.js is great, because (I assume) where PyPy's python goes, all the other pypy interpreters (Hippy, etc) can follow.
shriek 11y ago
Are you perhaps talking something like seif project from Crockford/Paypal?
tracker1 11y ago
Nobody is stoping you from making a browser that doesn't run JS at all.. nobody will use it, but nobody is stopping you from doing it... there's several decent rendering codebases you could strip JS out of and disable by default. Of course you won't be able to get to most content, but hell, it will be PURE.
nailer 11y ago
WebAssembly is a generalised, native runtime for dynamic untreated code. You can do things that wouldn't be possible in JS.

RussianCow 11y ago

I think WebAssembly is more or less going to solve this problem in the long run.

pjmlp 11y ago

Maybe WebAssembly and WebComponents will finally fix this. However I started to feel the same way a few years ago when the HTML 5 wave started, after several years of doing web development as well.

Yahivin 11y ago

> a generalized, native runtime designed explicitly to run dynamically fetched untrusted code. You mean like a browser?

sdegutis 11y ago
Browsers have evolved into exactly what people wanted Java for all along. Except it evolved from the wrong base. Kind of like if an elephant evolved to have intelligence and communication like ours instead of monkeys. That's pretty much the DOM & JS.
- djsumdog 11y ago
  When you look at browsers, web, html, http ... the whole stack. It's pretty horrible. How did we get to this point? ...could be worse. At least it's not E-mail.
  - alexro 11y ago
    >> It's pretty horrible. How did we get to this point? Because ads... are more important to get right than other stuff /sarcasm
  - tracker1 11y ago
    There's always Notes.. ;-) Honestly, I don't think the browser is so bad. And once wasm takes hold and tooling catches up, you'll have lots of options.
corndoge 11y ago
Yeah, except not completely broken with shit like "let's run python in the browser with javascript!" and "let's animate UI components originally designed to be static with an overloaded scripting language!" and a million other things. The browser and web were originally designed to view webpages (read documents) and not run arbitrary untrusted code... tl;dr you are making the point I refuted in my original post.

smacktoward 11y ago

You mean like Flash and Java?

samfisher83 11y ago
Its ironic.
- coldtea 11y ago
  No, he means a properly done sandbox but native and 2D accelerated platform without the DOM cruft. Not sure why it's so hard, probably because it's in nobody's interests but the users (as every major just wants to promote their own platform and have the web play second fiddle to it).
  - zbyte64 11y ago
    So like a canvas element then?
    - coldtea 11y ago
      In the sense that Cocoa or Windows top level window hierarchy is also like a "canvas element". In other words, like a canvas element which has a full, comprehensive, standard UI library with tons of standard, pre-built widgets (not just the meagre web form controls), including a full featured text widget with all the trimmings, plus a free drawing component of its own (for totally custom UIs and controls).
  - wtetzner 11y ago
    Doesn't sound so different from Java applets.
    - coldtea 11y ago
      The core concept, maybe. Then again, a top tier BMW doesn't sound so different than an Edsel either. They both have internal combustion engines, 4 wheels, a steering wheel, and they take you from place A to place B in similar speeds (in orders of magnitude). That's because you're focusing on the similarities which don't say anything -- what's important in all cases are the differences. Which in this case are mostly about the implementation. - the UI wouldn't be a part of a page, it would be THE page. - it shouldn't be an over-engineered mess of a GUI toolkit like Swing. - it should offer modern and capable widgets, instead of the bizarro, limited and uncanny value one's that Swing offers (if you don't get into intricate customization of your own). - it should be faster than the web app it replaces -- applets were often slow to load AND slow to run. - it shouldn't be controller by a single company. - it shouldn't be proprietary. - it should, if possible, cater to many programming languages. - it should play natively with the HTTP model, AJAX etc.

jnowlan 11y ago

While I completely agree, since it will never happen, why not strip javascript out of a browser (FF?), come up with a new catchy name, and market it as a safe browser. Just need a catchy name..., hmm, maybe Lynx? ;

AdmiralACK 11y ago
Links, perhaps...
- ciupicri 11y ago
  Links used to support JavaScript some time ago [1]. [1]: http://links.twibright.com/user_en.html#ap-javascript http://links.twibright.com/user_en.html#ap-javascript
TazeTSchnitzel 11y ago
NetSurf?
eeZi 11y ago
Lynx actually had its fair share of vulnerabilities due to bugs in the parsing code. Ain't that easy.

jdc 11y ago

I agree that there is a mess, but what kind of mess is it? What about it makes it a mess? Is perhaps because the JS interpreter is embedded (the DOM calls it)? Is it that the DOM is poorly suited for what we used to call "rich" internet applications? Or is it Javascript itself that is the problem?

michaelmcmillan 11y ago
For starters, the DOM API is horrible.
- jdc 11y ago
  Beyond the unpleasant experience of using it, what is actually wrong with it?
  - lqdc13 11y ago
    Very easy to have all kinds of memory leaks right now for one. It is really a combination of Javascript and the DOM. Unpleasant to use is definitely a big thing too. If it was easy and pleasant, nobody would complain.
    - zbyte64 11y ago
      Given any abstraction on a turing machine you will find it is easy to have memory leaks.
    - bzbarsky 11y ago
      Is it really easier to have memory leaks here than in any other garbage-collected language with first-class functions and closures? If you stick references to objects somewhere permanent, you will leak them. If you don't, you won't....
      - lqdc13 11y ago
        Ok, it's not that simple: http://www.javascriptkit.com/javatutors/closuresleak/index3.shtml http://www.javascriptkit.com/javatutors/closuresleak/index3.... The last example is a good demonstration that. Sure, at the end of the day it's all about not cleaning the references. All I'm saying is that it is super easy to accidentally not clean the references. In other languages or even in javascript itself without the DOM, it's not nearly that easy.

nbadg 11y ago

I think taking this sentiment to its conclusion is a bit more of a drastic change than that. It would mean the end of the web, not a return to its beginnings. You wouldn't be dealing with marked-up text, you'd be dealing with binary files (text markup, of course, being a subset thereof). The internet (and whatever emerged on top of it to replace the web) would then be concerned with content, sharing, and identity management only, and applications would be built on top of that.[1] The trick, as you said, is how to securely run untrusted code. That's what the web (well, I suppose more technically, browsers) are trying to solve; the problem is that the same origin policy, which is at the core of web security, just doesn't work very well. There are a lot of examples where this breaks; here are three off the top of my head: 1. Tracking using javascript to look for unique browser identifiers 2. XSS, CSRF, etc 3. Legitimate cross-site communication So clearly our existing solution to the "how do you securely execute dynamic, untrusted code" problem isn't cutting it. There's a lot of research (and production code, for the record) going into potentially better approaches though, so I think it's likely we'll see change, if we can get past the inertia behind today's hairball. [1] Incidentally this is exactly the approach we're taking with implementations of the Muse protocol (https://github.com/Muterra/doc-muse https://github.com/Muterra/doc-muse), which uses encryption to provide private content/sharing/identity management on untrusted servers.

vegabook 11y ago

seems like the browser is becoming another virtual machine.

bobajeff 11y ago

>maybe we should return the web and browser back to it's pure days of marked up text documents with images Good luck with that. You should bring back Gopher while you're at it.

swiley 11y ago
Honestly, Gopher is clean and pleasant.
endgame 11y ago
That would be fantastic.

haberman 11y ago

What you're describing is exactly what Java Applets were designed to do 20 years ago. And yet they never achieved a fraction of what "the current mess" has achieved.

dTal 11y ago
As a communications platform, sure. As an application platform, I'm not sure I agree. I have used many actual applications packaged as .jar files. They're generally more featureful and performant than we have come to expect from web apps[1]. As a platform-independent, single-file distribution format, Java actually works very well. Java wasn't ever intended to compete with the Web; it was the Web that got ideas. [1] I know, citation needed. Okay. Show me the web app that looks like this, that doesn't kill my EeePC: https://upload.wikimedia.org/wikipedia/commons/2/27/Gephi-07beta-screenshot.png https://upload.wikimedia.org/wikipedia/commons/2/27/Gephi-07...
AlphaSite 11y ago
Honestly, the things people did with applets probably haven't been replicated by JS in the browser, especially when native got involved (if I'm remembering correctly).
warbiscuit 11y ago
I think java apps failed to achieve more mainly because they didn't have decent access to the DOM, and the HTML rendering engine that goes with it. IMHO that's the killer app of the browser... for all it's faults, the HTML+CSS rendering engine is a superior UI description api than anything previously devised. I remember the brief period I wrote some java apps. The main pain was choosing between rendering a native java gui, or establishing hooks to have it instrument an html interface from behind the scenes. The native gui had better connection to the code... whereas using the DOM was insanely flexible, but talking to the DOM was like trying to drive a car by reaching through the tailpipe. That I think is why java apps never prospered (outside of the whole "loading" issue... which could have been optimized away if the motivation was there). --- JS currently has the best of both worlds, and not because of anything native to the language (though it does have many positive points). I feel like WebAssembly, and things like PyPy.js, are a step in the right direction. Making the DOM and HTML+CSS just another ui library available to the language of the moment. Having PyPy.js is great, because (I assume) where PyPy's python goes, all the other pypy interpreters (Hippy, etc) can follow.

shriek 11y ago

Are you perhaps talking something like seif project from Crockford/Paypal?

tracker1 11y ago

Nobody is stoping you from making a browser that doesn't run JS at all.. nobody will use it, but nobody is stopping you from doing it... there's several decent rendering codebases you could strip JS out of and disable by default. Of course you won't be able to get to most content, but hell, it will be PURE.

nailer 11y ago

WebAssembly is a generalised, native runtime for dynamic untreated code. You can do things that wouldn't be possible in JS.