On Thursday, 18 June 2015 at 10:36:16 UTC, Joakim wrote:

> Why can't they just admit that the core architecture of the web is horrific, ie an antiquated document format based on some shitty 50-year old IBM markup language (https://en.wikipedia.org/?title=Standard_Generalized_Markup_Language), a programming runtime that was cranked out in 10 days in the middle of the browser wars and certainly shows it (https://en.wikipedia.org/wiki/Brendan_Eich#Netscape_and_JavaScript), and a stylesheet language hacked on top to eliminate some redundancy, _by adding yet another language_?!
>

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. Given that it must be supported else it will break the interweb, what else is there to do but do but to build the new stuff on the side. With a canvas, OpenGL backing and a half-decent 'assembly language' to compile down to, it could be made into (ultimately) a satisfactory development platform. You would only need to use DOM and CSS for the top canvas/OpenGL node and from there down it's all however you want to roll it.

As for performance then granted it seems bizarre to require all these layers below, but I remember watching a very interesting video about how running on the OS is subject to large overheads in the kernel, while running in the browser can bypass that and hence is not such a performance drop as you might expect - unfortunatel I can't dig up the link.

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.

On Thursday, 18 June 2015 at 11:00:37 UTC, ketmar wrote:

> piles of shit on top of piles of shit

A good definition of evolution.

On Thursday, 18 June 2015 at 18:30:24 UTC, Abdulhaq wrote:
> On Thursday, 18 June 2015 at 10:36:16 UTC, Joakim wrote:
>
>> Why can't they just admit that the core architecture of the web is horrific, ie an antiquated document format based on some shitty 50-year old IBM markup language (https://en.wikipedia.org/?title=Standard_Generalized_Markup_Language), a programming runtime that was cranked out in 10 days in the middle of the browser wars and certainly shows it (https://en.wikipedia.org/wiki/Brendan_Eich#Netscape_and_JavaScript), and a stylesheet language hacked on top to eliminate some redundancy, _by adding yet another language_?!
>>
>
> 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.

> Given that it must be supported else it will break the interweb, what else is there to do but do but to build the new stuff on the side. With a canvas, OpenGL backing and a half-decent 'assembly language' to compile down to, it could be made into (ultimately) a satisfactory development platform. You would only need to use DOM and CSS for the top canvas/OpenGL node and from there down it's all however you want to roll it.

I think the reason these efforts have failed so far is because NaCl was still stuck using the existing web stack for the GUI, which is a huge pain.  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.

And this new stuff isn't integrated, I believe canvas doesn't even support hyperlinks.  How is that not broken already?

There appears to be little to no thought put into all these new APIs that are simply mashed into the browser.  A vector graphics format encoded in text, let alone XML?  Yeah, because what I really wanted to do is read bezier curve descriptions in plain text interspersed with hundreds of angle brackets and quotation marks!  Throw that in the browser!

http://www.w3.org/TR/SVG/paths.html

XSLT?  Why not?! Throw that shit with libxml in the browser too, along with all their bugs!

http://neugierig.org/software/chromium/notes/2010/06/roman-numerals.html

If you didn't read Bray's piece I linked above, his conclusion is dead on:

"Historical periods featuring rococo engineering outbursts of colorful duplicative complexity usually end up converging on something simpler that hits the right 80/20 points."

On Thursday, 18 June 2015 at 18:40:50 UTC, Max Samukha wrote:
> On Thursday, 18 June 2015 at 11:00:37 UTC, ketmar wrote:
>
>> piles of shit on top of piles of shit
>
> A good definition of evolution.

Except evolution actually weeds out the crap, as Linus knows:

http://bobweigel.net/projects/index.php?title=Weigel/Notes#Linus_on_Development

What we have here is peacocks on some tropical island- only sustained because all the major browser vendors are now OS vendors, Apple, Microsoft, Google, who either don't want the web to replace their OS APIs or have no idea how to make it better- heading down Bray's "colorful" evolutionary dead-ends before they're finally wiped out.

On 06/18/2015 01:41 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Thursday, 18 June 2015 at 11:00:37 UTC, ketmar wrote:
>> they will never stop, won't they? "modern web: building piles of shit
>> on top of piles of shit". (sigh)
>
> Indeed.
>
> «Even before browsers ship native support for WebAssembly, developers
> can ship applications on the Web using a polyfill which converts
> WebAssembly to JavaScript. »
>

Great, so it'll have the same fundamental problem as asm.js: Claims to be backwards compatible, but really isn't because the backwards fallback method is likely to be prohibitively slow and will especially fuck mobile browsers that use the fallback.

> Basically binary asm.js... What are they thinking?
>

Maybe this suggestion demonstrates ignorance, but I'm thinking "They should just use LLVM IR. It already exists." Maybe toss in some LLVM IR extensions as needed, and boom, done.

But the web world has always been so very NIH-syndrome, though.

> And whyyyyyyy are they calling a binary format "assembly"?
>

Probably because .NET/Mono have already established the name "assembly" for that sort of thing. That'd be my guess. They could call it an "object file" but that would intuitively suggest something more along the lines of ELF/COFF/whatever, which I assume isn't quite what they have in mind.

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.

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

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

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.

> 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 ;)

> 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

-Wyatt

On Thursday, 18 June 2015 at 19:39:58 UTC, Nick Sabalausky wrote:
> Great, so it'll have the same fundamental problem as asm.js: Claims to be backwards compatible, but really isn't because the backwards fallback method is likely to be prohibitively slow and will especially fuck mobile browsers that use the fallback.

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.

> Maybe this suggestion demonstrates ignorance, but I'm thinking "They should just use LLVM IR. It already exists." Maybe toss in some LLVM IR extensions as needed, and boom, done.

The LLVM IR isn't stable, so you need a higher level IR. And that's hard to design. So maybe 5 years before they get it right, and _properly_ implemented, in all browsers?

Of course, in 5 years hardware has changed and regular Javascript JITs have improved, so by then we need WebAssembly2… So, 8 years?

On Thursday, 18 June 2015 at 21:15:35 UTC, Wyatt wrote:
> SVG has animation, input handling, and an audio API(!) and you take issue with paths?  Weeeeeak. :P

I remember demoing inline SVG with animation for students around 2003 as a useful upcoming technology. I got to use it in production around 2013… on some browsers…

Oh, it is a W3C standard now? Cool, oh, I look so much forward to using it… It is right around the corner, like… in-12-years-right-around-the-cornerish.

On Thursday, 18 June 2015 at 08:05:48 UTC, John Colvin wrote:
> This appears to have involvement from all major browser vendors, which provides hope it might actually catch on properly. An llvm backend will be created which will compile to "wasm", hopefully LDC and/or SDC could glue to this.
>
> https://www.w3.org/community/webassembly/
>
> https://github.com/WebAssembly
>
> In particular, see https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md https://github.com/WebAssembly/design/blob/master/FAQ.md and https://github.com/WebAssembly/design/blob/master/MVP.md

What a fucking waste. We had that years ago with NaCl. Mozilla really fucked up on that one.

Let's how that goes. I'd be supportive of any effort for SDC to support this, but really don't have enough bandwidth to work on it myself.

On Thursday, 18 June 2015 at 18:14:09 UTC, David Gileadi wrote:
> On 6/18/15 10:41 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>> And whyyyyyyy are they calling a binary format "assembly"?
>
> Because it sounds faster, of course :)

I can't wait for the GTO version, I bet it is even faster!