Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebKit.js: Pure JavaScript Port of WebKit

github.com

Post reply on HN
Print view View original

51–60 of 96 posts

Re: WebKit.js: Pure JavaScript Port of WebKit

#51

Post by angersock »

Touche wrote: post #31
captainmuon wrote: post #28

Earlier quoted context omitted.

Yeah, but I imagine a future where an "operating system" is just a OpenGL + Networking + JS API, and you just load in HTML5.exe . The benefit of something like this is that it puts the power back in the hands of the people. You don't have to worry about Google and Apple restricting what you can do, you just load in the HTML5.exe that you know works. Want a new feature? Fork Firefox on GitHub. (I don't want to belittl…

Arbitrarily running x86 machine code fetched over the net? Pass.

This is different than Chrome or whatever autoupdating how exactly?

Re: WebKit.js: Pure JavaScript Port of WebKit

#52

Post by TheMakeA »

0x0 wrote: post #48
TheMakeA wrote: post #10

I may be the only one excited about this, but I think it's awesome. I imagine a future where a "web browser" is just a WebGL + Networking + JS API, and you just load in HTML5.js. The benefit of something like this is that it puts the power back in the hands of the people. You don't have to worry about Microsoft ignoring standards, you just load in the HTML5.js that you know works. Want a new feature? Fork HTML5.js on…

Leaving HTML5 rendering implementation up to each website, while only providing a "dumb" 2d or 3d pipeline (webgl), would make for a terrible non-native browsing experience. No native font rendering, no right-clicking text selection to choose from a dozen OS-provided services, no user-based keyboard shortcuts in text fields like this comment field, and so on. It would also make it much more difficult to peek at the s…

  No native font rendering
True, but you can render some pretty good looking fonts[0].

   no right-clicking text selection to choose from a dozen OS-provided services, no user-based keyboard shortcuts in text fields like this comment field, and so on.
Could be part of a JS api exposed and used by HTML5.js.

  there wouldn't be a working DOM inspector in your browser
FireBug, and the Chrome Dev Tools are written in HTML. Could be integrated into HTML5.js.

There would be differences for sure, but I think the benefits would outweigh the downsides.

[0] http://research.microsoft.com/en-us/um/people/cloop/LoopBlin...

Re: WebKit.js: Pure JavaScript Port of WebKit

#53

Post by mikeash »

elwell wrote: post #27
eseehausen wrote: post #20

Earlier quoted context omitted.

It's 50MB. That probably revises #2. As for #1, isn't this a good thing in itself?

Oh meant to write 50MB; doesn't revise #2.

Looks like it uses Emscripten to convert from C++ to JS, so it's not really humanly possible.

Re: WebKit.js: Pure JavaScript Port of WebKit

#54

Post by derefr »

skrebbel wrote: post #29
captainmuon wrote: post #28

Earlier quoted context omitted.

Yeah, but I imagine a future where an "operating system" is just a OpenGL + Networking + JS API, and you just load in HTML5.exe . The benefit of something like this is that it puts the power back in the hands of the people. You don't have to worry about Google and Apple restricting what you can do, you just load in the HTML5.exe that you know works. Want a new feature? Fork Firefox on GitHub. (I don't want to belittl…

True, but, deployment.

An operating system that has more fundamental concept of "URI access" than "file system"; and which does zero-install of any application you type in the URL of, temporarily for as long as you visit the site, isn't really not a web browser, is it?

Re: WebKit.js: Pure JavaScript Port of WebKit

#55

Post by janjongboom »

0x0 wrote: post #48
TheMakeA wrote: post #10

I may be the only one excited about this, but I think it's awesome. I imagine a future where a "web browser" is just a WebGL + Networking + JS API, and you just load in HTML5.js. The benefit of something like this is that it puts the power back in the hands of the people. You don't have to worry about Microsoft ignoring standards, you just load in the HTML5.js that you know works. Want a new feature? Fork HTML5.js on…

Leaving HTML5 rendering implementation up to each website, while only providing a "dumb" 2d or 3d pipeline (webgl), would make for a terrible non-native browsing experience. No native font rendering, no right-clicking text selection to choose from a dozen OS-provided services, no user-based keyboard shortcuts in text fields like this comment field, and so on. It would also make it much more difficult to peek at the s…

> no right-clicking text selection to choose from a dozen OS-provided services

Ah well, this stuff is added into the browser engine already in Firefox OS.

Re: WebKit.js: Pure JavaScript Port of WebKit

#56

Post by Helianthus »

thatthatis wrote: post #40
tlrobinson wrote: post #36

Earlier quoted context omitted.

[ insert obligatory tlrobinson's Law quote here ] (tlrobinson's Law: any submission to Hacker News about a novel JavaScript program will contain a comment referencing Atwood's Law. https://twitter.com/tlrobinson/status/395636386671235072 )

throw StopIteration; //For the love of god, please no more laws. I know it's tempting to coin a law about tlrobinson being brought up whenever atwood's law is brought up, but enough is enough already

[ insert obligatory thatthatis's recursive-reference-escape coining reference here ]

Re: WebKit.js: Pure JavaScript Port of WebKit

#57

Post by roma1n »

TheMakeA wrote: post #24
elwell wrote: post #21

Earlier quoted context omitted.

IE JS API would still be outdated.

You could probably reduce the browser to just WebGL + BSD Sockets JS APIs. Far less surface area for vendors to screw up.

So no sound, no storage, no access to peripherals (e.g. webcam, geolocation, accelerometer)... ?

Re: WebKit.js: Pure JavaScript Port of WebKit

#58

Post by Someone »

0x0 wrote: post #48
TheMakeA wrote: post #10

I may be the only one excited about this, but I think it's awesome. I imagine a future where a "web browser" is just a WebGL + Networking + JS API, and you just load in HTML5.js. The benefit of something like this is that it puts the power back in the hands of the people. You don't have to worry about Microsoft ignoring standards, you just load in the HTML5.js that you know works. Want a new feature? Fork HTML5.js on…

Leaving HTML5 rendering implementation up to each website, while only providing a "dumb" 2d or 3d pipeline (webgl), would make for a terrible non-native browsing experience. No native font rendering, no right-clicking text selection to choose from a dozen OS-provided services, no user-based keyboard shortcuts in text fields like this comment field, and so on. It would also make it much more difficult to peek at the s…

I think the idea would be that there would not be native font rendering or OS-provided services. All that would move up a layer.

Yes, that would give a lot of flexibility. Usability would suffer, though. It would be like the old (1) times of X Windows, where there were zillions (read: > 1) ways to handle a clipboard, multiple conventions for the format of the data on the clipboard, where one application could find your TrueType fonts, while another couldn't, etc.

(1) some people will feel I'm being polite here. Maybe I am, but that is something for another discussion, and I know too little about modern X applications to contribute there.

Re: WebKit.js: Pure JavaScript Port of WebKit

#59

Post by ygra »

TheMakeA wrote: post #10

I may be the only one excited about this, but I think it's awesome. I imagine a future where a "web browser" is just a WebGL + Networking + JS API, and you just load in HTML5.js. The benefit of something like this is that it puts the power back in the hands of the people. You don't have to worry about Microsoft ignoring standards, you just load in the HTML5.js that you know works. Want a new feature? Fork HTML5.js on…

What you propose there reminds me of Atlantis: http://research.microsoft.com/apps/pubs/default.aspx?id=1546... – James Mickens did a talk as well: http://www.youtube.com/watch?v=4c0DdOvH6lg

Basically they reduce the browser to a VM where everything except a few core things run in the page's context (including the protocol implementations, layout and scripting) which enables a few nice things.

Post reply on HN