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

Webkit.js

trevorlinton.github.io

Post reply on HN
Print view View original

11–20 of 106 posts

Re: Webkit.js

#11

Post by ndesaulniers »

pfraze wrote: post #8
dag11 wrote: post #7

I thought it was a static rendering, but then I put in a marquee tag and it moved flawlessly across the screen. Impressive. I can't say I see the practical implementations of this, but I'm sure there's some. But it's impressive nonetheless.

Rendering HTML to WebGL textures would be big, which I think this could do - though probably not as performantly as the browser could. It's currently not possible, partially due to security concerns if I remember right.

Awesome idea! I've seen tricks where CSS 3D transforms were used to position the entire DOM within a scene rendered in Canvas, but that approach is extremely limited. [0]

Theoretically, now you could render the DOM to a texture instead of to the screen and do some sweet deferred rending.

== Edit ==

Looks like one of Mozilla's Distinguished Engineers blogged about the technique. [1] [2] The creator of emscripten used this technique to render tweets as a texture in the bannabread demo. [3]

[0] https://medium.com/@deathcap1/six-months-of-voxel-js-494be64...

[1] http://robert.ocallahan.org/2011/11/drawing-dom-content-to-c...

[2] https://developer.mozilla.org/en-US/docs/Web/HTML/Canvas/Dra...

[3] http://kripken.github.io/boon/screens/game.html?low,low

Re: Webkit.js

#12

Post by ndesaulniers »

atonse wrote: post #4
ozten wrote: post #2

FirefoxOS will host Safari / Chrome apps, before iOS will allow a Firefox. Open FTW.

What exactly are iOS users missing in Safari, in your opinion, that they would get from Firefox? I can see that Chrome has some cool sync features if you're into that sort of thing. But it still uses WebKit. And from what I've observed, people seem happy with the "Chrome" app in the app store, even though it uses a handicapped renderer. (Although in iOS 8, it won't be handicapped anymore, and will be as powerful as n…

Most iOS devs aren't clamoring for alternative browser engine implementations because they're happy with the objective C runtime. Web developers shouldn't be happy with only having one browser implementation available because there's no competition on iOS. Safari on iOS can lag in features and not care because there is no competition on iOS. Chrome on iOS offers nothing in the way of additional html5 APIs and is just a new UI on the same old Webkit (to my knowledge).

For instance, as of about a week ago Safari on iOS just got WebGL support (as you alluded to). How long would we have had WebGL support on iOS if we could ship an alternative browser engine implementation with competitive JIT'ing JavaScript engine (like Firefox's Gecko & SpiderMonkey engines) on iOS since the beginning? Would alternative browser engines with more APIs drive the Safari for iOS team to ship features faster? Bottom line: competition is healthy; developers and thus users win.

Re: Webkit.js

#13

Post by zachlipton »

atonse wrote: post #4
ozten wrote: post #2

FirefoxOS will host Safari / Chrome apps, before iOS will allow a Firefox. Open FTW.

What exactly are iOS users missing in Safari, in your opinion, that they would get from Firefox? I can see that Chrome has some cool sync features if you're into that sort of thing. But it still uses WebKit. And from what I've observed, people seem happy with the "Chrome" app in the app store, even though it uses a handicapped renderer. (Although in iOS 8, it won't be handicapped anymore, and will be as powerful as n…

Because competition in the browser market is vital to keep the web platform progressing and to prevent a single party from controlling web standards. Do you remember the dark ages when IE ruled the web and things like HTML5, canvas, webgl, etc... couldn't happen?

Re: Webkit.js

#14

Post by anon1385 »

ndesaulniers wrote: post #12
atonse wrote: post #4

Earlier quoted context omitted.

What exactly are iOS users missing in Safari, in your opinion, that they would get from Firefox? I can see that Chrome has some cool sync features if you're into that sort of thing. But it still uses WebKit. And from what I've observed, people seem happy with the "Chrome" app in the app store, even though it uses a handicapped renderer. (Although in iOS 8, it won't be handicapped anymore, and will be as powerful as n…

Most iOS devs aren't clamoring for alternative browser engine implementations because they're happy with the objective C runtime. Web developers shouldn't be happy with only having one browser implementation available because there's no competition on iOS. Safari on iOS can lag in features and not care because there is no competition on iOS. Chrome on iOS offers nothing in the way of additional html5 APIs and is just…

> if we could ship an alternative browser engine implementation with competitive JIT'ing JavaScript engine

Which is not possible on FirefoxOS. So I don't see how 'open' wins here (I'm using 'open' as the GP used it: a marketing buzzword synonymous with Mozilla).

Re: Webkit.js

#15

Post by ozten »

atonse wrote: post #4
ozten wrote: post #2

FirefoxOS will host Safari / Chrome apps, before iOS will allow a Firefox. Open FTW.

What exactly are iOS users missing in Safari, in your opinion, that they would get from Firefox? I can see that Chrome has some cool sync features if you're into that sort of thing. But it still uses WebKit. And from what I've observed, people seem happy with the "Chrome" app in the app store, even though it uses a handicapped renderer. (Although in iOS 8, it won't be handicapped anymore, and will be as powerful as n…

Firefox for Android is very popular and highly rated in the Google play store.

The browsers that are in the Apple App store are handicapped by legal limitations, which are not present on other, more open operating systems.

Re: Webkit.js

#16

Post by nnnnni »

msvan wrote: post #6
PLenz wrote: post #3

Anyway to get this to run in node with the output going to say Cairo? It'd be a fun little project to see if you could build a simple but working browser in nothing but JS.

And then, getting the browser running itself in the in-browser browser.

Now THAT would be a sandboxed browser.

Also, even though people tend to not like this kind of thing here, it has to be said: Yo dawg...

Re: Webkit.js

#17

Post by nnnnni »

atonse wrote: post #4
ozten wrote: post #2

FirefoxOS will host Safari / Chrome apps, before iOS will allow a Firefox. Open FTW.

What exactly are iOS users missing in Safari, in your opinion, that they would get from Firefox? I can see that Chrome has some cool sync features if you're into that sort of thing. But it still uses WebKit. And from what I've observed, people seem happy with the "Chrome" app in the app store, even though it uses a handicapped renderer. (Although in iOS 8, it won't be handicapped anymore, and will be as powerful as n…

The funny thing is that the "RAWR NO SAFARI, ONLY CHROME!" people don't seem to realize that both are WebKit at the core. Sure, some features are in Chrome first, but that's only because Apple is very cautious when releasing the new features to the general public.

Re: Webkit.js

#18

Post by tlinton »

pfraze wrote: post #8
dag11 wrote: post #7

I thought it was a static rendering, but then I put in a marquee tag and it moved flawlessly across the screen. Impressive. I can't say I see the practical implementations of this, but I'm sure there's some. But it's impressive nonetheless.

Rendering HTML to WebGL textures would be big, which I think this could do - though probably not as performantly as the browser could. It's currently not possible, partially due to security concerns if I remember right.

It actually does, turn on chrome's canvas profiler its kicking up bindTextures for everything. On the demo it even says its a hardware accelerated version and requires WebGL.

Re: Webkit.js

#19

Post by anon1385 »

zachlipton wrote: post #13
atonse wrote: post #4

Earlier quoted context omitted.

What exactly are iOS users missing in Safari, in your opinion, that they would get from Firefox? I can see that Chrome has some cool sync features if you're into that sort of thing. But it still uses WebKit. And from what I've observed, people seem happy with the "Chrome" app in the app store, even though it uses a handicapped renderer. (Although in iOS 8, it won't be handicapped anymore, and will be as powerful as n…

Because competition in the browser market is vital to keep the web platform progressing and to prevent a single party from controlling web standards. Do you remember the dark ages when IE ruled the web and things like HTML5, canvas, webgl, etc... couldn't happen?

>competition in the browser market is vital to keep the web platform progressing and to prevent a single party from controlling web standards

I don't see much difference between a single party and a cartel of 3-4 parties. They are all mega corporations that don't share my interests and even when there are several parties any one effectively has veto power over any changes to standards.

The push for browser-as-OS is only going to make things worse. You don't get any browser choice at all when your hardware is running ChromeOS or FirefoxOS

Re: Webkit.js

#20

Post by [deleted] »

pfraze wrote: post #8
dag11 wrote: post #7

I thought it was a static rendering, but then I put in a marquee tag and it moved flawlessly across the screen. Impressive. I can't say I see the practical implementations of this, but I'm sure there's some. But it's impressive nonetheless.

Rendering HTML to WebGL textures would be big, which I think this could do - though probably not as performantly as the browser could. It's currently not possible, partially due to security concerns if I remember right.

[deleted]
Post reply on HN