June 18, 2015
On Thursday, 18 June 2015 at 18:33:16 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 18 June 2015 at 18:15:32 UTC, weaselcat wrote:
>> I didn't even read it, I thought it was going to be like a standardized pnacl from the naming.
>
> Well, it is hard to say what it will become, maybe it is possible come up with an  IR that doesn't sacrifice performance and still can easily be translated into Javascript with reasonable performance.
>
> But what's the point? One could compile an application to both asm.js and WebAssembly instead.
>
> Sounds like politics could turn this into a long stumbling process.

That is already the case. Mozilla dropped the NaCl wagon in the middle of the road, letting Google alone on that one, to promote their concurrent ill advised "standard".

Now there is 2 standard, one that is actually pretty good, but supported only by google, and another one that is retarded, but supported more widely. As nobody want to admit they fucked up, the whole joyous band of over-bloated bogus standard designers decided to bless us with a 3rd "standard" that is roughly equivalent to PNaCl, but is not PNaCl, because pride is more important that webdev's sanity.
June 18, 2015
On Thursday, 18 June 2015 at 21:51:15 UTC, deadalnix wrote:
> Now there is 2 standard, one that is actually pretty good, but supported only by google, and another one that is retarded, but supported more widely. As nobody want to admit they fucked up, the whole joyous band of over-bloated bogus standard designers decided to bless us with a 3rd "standard" that is roughly equivalent to PNaCl, but is not PNaCl, because pride is more important that webdev's sanity.

I looked into PNaCl a bit, but when it comes to Google I always get the feeling that they feel it is sufficient to make native programming possible rather than pleasant. Same for Android NDK, and some might say Go (perhaps unfair).

In that respect WebAssembly is a good thing, if it takes off, the browser-competition means that they will need to focus on tooling/in-browser-debugging.

I haven't been able to figure out if it will support a GC?


June 18, 2015
On Thursday, 18 June 2015 at 22:07:06 UTC, Ola Fosheim Grøstad wrote:
> I looked into PNaCl a bit, but when it comes to Google I always get the feeling that they feel it is sufficient to make native programming possible rather than pleasant. Same for Android NDK, and some might say Go (perhaps unfair).
>
> In that respect WebAssembly is a good thing, if it takes off, the browser-competition means that they will need to focus on tooling/in-browser-debugging.
>
> I haven't been able to figure out if it will support a GC?

PNaCl is not meant to be used as such. You do you code in some other language and compile it to PNaCl.

Mozilla made it a Google thing. They basically dropped the project int he middle of the road to push their alternative standard, asm.js . This created the mess we see here in the first place.

They fucked up and now don't want to admit it, so now we need 3 "standards" instead of one.
June 18, 2015
On 06/18/2015 05:21 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>
> Yeah. This fallback thing does not make much sense. They say WebAssembly
> will reduce the file size by 7% after compression compared to asm.js .
> Who cares?
>
> In my experience performance issues usually are in the layout/render
> engine, or something related to it.
>

The layout/render stuff has to support so much dynamic-DOM cruft on every...single...element...of the page, it's pretty much inevitable that the browser itself is where the bottleneck is on a normal page, rather than network. (Which is really weird if you look at it from the perspective of someone who remembers dial-up.)

June 18, 2015
On Thursday, 18 June 2015 at 22:20:25 UTC, deadalnix wrote:
> On Thursday, 18 June 2015 at 22:07:06 UTC, Ola Fosheim Grøstad wrote:
>> I haven't been able to figure out if it will support a GC?
>
> PNaCl is not meant to be used as such. You do you code in some other language and compile it to PNaCl.

Yeah, I know, I meant the whole environment with Pepper.

For WebAssembly to take off it probably has to support languages like Ruby, Python and others that are used on the server. Guess they could do debugging using "source maps"...

I think too many people care about IE for PNaCl to take off without Microsoft support. asm.js had a strategic advantage by running on all platforms, so browser vendors couldn't avoid supporting it, either add some optimizations for it or appear sluggish.

June 19, 2015
On Thursday, 18 June 2015 at 22:24:09 UTC, Nick Sabalausky wrote:
> On 06/18/2015 05:21 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> The layout/render stuff has to support so much dynamic-DOM cruft on every...single...element...of the page, it's pretty much inevitable that the browser itself is where the bottleneck is on a normal page, rather than network.

My impression is that browsers focus too much on typical layout, which makes using it as a generic programming platform challenging when you scale up. Like, using lots of absolute positioning ought to be easy on reflow, but in my experience it isn't.

But I think it is unforgivable that Chrome still stutters when doing longer animations. The biggest browsers never need to fix their issues because everybody works around them anyway.

> (Which is really weird if you look at it from the perspective of someone who remembers dial-up.)

I believe I browsed BBSes with a borrowed 300 baud modem with "earmuffs" that you attach physically to a real phone handset. With a font using 4bit wide characters to get 80 columns on a 40 columns computer. Barely readable. :)

June 19, 2015
On Thursday, 18 June 2015 at 21:15:35 UTC, Wyatt wrote:
> On Thursday, 18 June 2015 at 19:23:26 UTC, Joakim wrote:
>> On Thursday, 18 June 2015 at 18:30:24 UTC, Abdulhaq wrote:
>>>
>>> Of course this is exactly true and it drives me mad too, but you can't just jettison it in favour of a better architecture.
>>
>> Why not?  This is exactly what _should_ be done.
>>
> Same reason you can't just stick your head in the sand and pretend the entire existing body of C and C++ code doesn't exist.
>  It sucks, but them's the breaks.

The difference is that "existing body of C and C++ code" actually does something and works.  The existing web stuff is just GUI markup, that as Bray notes never quite works, so it can easily be ditched.  It is _already_ being ditched, for native mobile UIs.  I know of major shopping websites in developing markets that have shut down their mobile websites in favor of their mobile apps.  It's just too much of a pain to keep the web frontend going.

>> I think the reason these efforts have failed so far is because NaCl was still stuck using the existing web stack for the GUI,
>
> NaCl failed because it required a plugin, and did so in a way that made it exclusive to one browser vendor.  It's like Java only worse.  Or that thrice-be-damned Flash.

No, NaCl has been built into Chrome, one of the major browsers, for a while.  I believe it could be used to secure plugins, but did not require you to install one.  At least, I've certainly used it without receiving a plugin prompt.  And Java and Flash were ubiquitous at one point in their histories.

>> But if you're just going to avoid the old web stack altogether and try to deploy your canvas/WebGL/assembly native app everywhere using the web browser as a trojan horse, presumably just to get through security or evade sysadmins more easily, you have to question what the point of making it a "web app" even is.
>>
> The point is it runs in a browser.  Do you need a more compelling feature than the ability to run unchanged anywhere there's a browser (basically everywhere)?  I mean, I too think

Think about that.  Once you're writing your app in WebGL/webasm, what are you really gaining over just making it a mobile app for iOS/Android, both of which support OpenGL/asm? ;)

> most of this "web technology" is trash and really wish the lingua fraca of the Internet wasn't awful--  I would love for text to be foremost and for progressive enhancement to fall back to a normal web site when I visit with elinks.

Those days are gone.  The dynamic model of HTML5, where pages are not even the organizing principle anymore, means they need to rethink the entire model.  But I see no evidence that anybody is doing so, simply piling more stuff on top.

> But realistically? This is a damn sight better than any of the other attempts so far because it's just a new feature in the JS VM.  If it means we can lower code in a proper language to something a browser can run at something resembling the speed of an ordinary scripting language, it'll be a win already.

I agree that if webasm finally delivers on the promise of NaCl, which I said I was hopeful for, it will be a worthwhile improvement.  If it means you can avoid writing javascript entirely and get decent performance, it is definitely a big win.

>> And this new stuff isn't integrated, I believe canvas doesn't even support hyperlinks.  How is that not broken already?
>>
> Look, I don't fundamentally disagree that this all sucks but dude, chill.  Here, go play some Oregon Trail: https://archive.org/details/msdos_Oregon_Trail_The_1990 ;)

Nah, time to break it.

>> http://www.w3.org/TR/SVG/paths.html
>>
> SVG has animation, input handling, and an audio API(!) and you take issue with paths?  Weeeeeak. :P

No, I take issue with the text format, especially XML.  That was a horrible idea, regardless of how many good features they built in.
June 19, 2015
On Thursday, 18 June 2015 at 22:20:25 UTC, deadalnix wrote:
> On Thursday, 18 June 2015 at 22:07:06 UTC, Ola Fosheim Grøstad wrote:
>> I looked into PNaCl a bit, but when it comes to Google I always get the feeling that they feel it is sufficient to make native programming possible rather than pleasant. Same for Android NDK, and some might say Go (perhaps unfair).
>>
>> In that respect WebAssembly is a good thing, if it takes off, the browser-competition means that they will need to focus on tooling/in-browser-debugging.
>>
>> I haven't been able to figure out if it will support a GC?
>
> PNaCl is not meant to be used as such. You do you code in some other language and compile it to PNaCl.
>
> Mozilla made it a Google thing. They basically dropped the project int he middle of the road to push their alternative standard, asm.js . This created the mess we see here in the first place.
>
> They fucked up and now don't want to admit it, so now we need 3 "standards" instead of one.

This appears to be the coming together of all those teams to finally work together, as noted by a Chrome developer, Peter Kasting:

http://arstechnica.com/information-technology/2015/06/the-web-is-getting-its-bytecode-webassembly/?comments=1&post=29227533

He justifies the previous efforts as laying the groundwork for this standard, which is certainly reasonable.
June 19, 2015
On Friday, 19 June 2015 at 04:18:59 UTC, Joakim wrote:
> Think about that.  Once you're writing your app in WebGL/webasm, what are you really gaining over just making it a mobile app for iOS/Android, both of which support OpenGL/asm? ;)

1. You write one app.

- Want asm on Android? Woops, many different configurations.
- Want asm on iOS? Woops, no more, moving to LLVM.
- New version of iOS? Gotta update the app to stay fresh.

2. Instant access. Direct load from advertisment-link.

3. No update procedure, no lingering messed up version.

4. No AppStore-related censorship/constraints.

5. No extra fees.

> Those days are gone.  The dynamic model of HTML5, where pages are not even the organizing principle anymore, means they need to rethink the entire model.  But I see no evidence that anybody is doing so, simply piling more stuff on top.

Polymer, web components.

>>> http://www.w3.org/TR/SVG/paths.html
>>>
>> SVG has animation, input handling, and an audio API(!) and you take issue with paths?  Weeeeeak. :P
>
> No, I take issue with the text format, especially XML.  That was a horrible idea, regardless of how many good features they built in.

PDF is text format too. SVG is pretty good actually, but the integration with HTML5 could be better.

June 19, 2015
On 06/19/2015 01:17 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Friday, 19 June 2015 at 04:18:59 UTC, Joakim wrote:
>> Think about that.  Once you're writing your app in WebGL/webasm, what
>> are you really gaining over just making it a mobile app for
>> iOS/Android, both of which support OpenGL/asm? ;)
>
> 1. You write one app.
>
> - Want asm on Android? Woops, many different configurations.
> - Want asm on iOS? Woops, no more, moving to LLVM.
> - New version of iOS? Gotta update the app to stay fresh.
>

Seriously? Web is just as bad.

Form factors and web standards compliance both vary wildly, rendering it "write once, TEST everywhere". That's all the more true if you go all HTML5, web-as-an-applications-platform.

> 2. Instant access. Direct load from advertisment-link.
>

If by "instant" you mean "this web 'app' leaves my mobile browser completely unresponsive for up to a full minute every time I tap a link, every time I use it".

> 3. No update procedure, no lingering messed up version.
>

A lot of native apps have seamless updating, too. Ex: The browsers themselves. And webdevs do occasionally mess up caching.

> 4. No AppStore-related censorship/constraints.
>
> 5. No extra fees.
>

True (for modern mobile), although that really isn't anything inherent to "native app", as proven by desktops/laptops and pre-iOS mobiles like PalmOS. Plus, so called "side-loading" is seriously freaking easy on Android.

>> Those days are gone.  The dynamic model of HTML5, where pages are not
>> even the organizing principle anymore, means they need to rethink the
>> entire model.  But I see no evidence that anybody is doing so, simply
>> piling more stuff on top.
>
> Polymer, web components.
>

Exactly. Piling more stuff on top. ;)

http://www.quirksmode.org/blog/archives/2015/05/tools_dont_solv.html