Live data from Hacker News

W3C recommends WebAssembly

w3.org

251–260 of 350 posts

Re: W3C recommends WebAssembly

#251
post #249

Earlier quoted context omitted.

I agree that that was a turning point for usage, but we're discussing popularity among developers. Flash was unpopular among developers long before Apple banned it.

Flash was on approximately 30% of websites before. It's hard to understand the argument that it was unpopular amongst devs.

Devs hated Flash for all of the reasons cited above, but browsers didn't support anything better for many use cases.

Re: W3C recommends WebAssembly

#252
post #249

Earlier quoted context omitted.

Flash was on approximately 30% of websites before. It's hard to understand the argument that it was unpopular amongst devs.

Devs hated Flash for all of the reasons cited above, but browsers didn't support anything better for many use cases.

Indeed. As an example for a long time you had to have Flash to play a video on your page. The HTML5 video support eventually ended the need for Flash to do this, but it came much later and very slowly became supported cross-browser.

Re: W3C recommends WebAssembly

#253
post #19

Does anyone have any good intro resources for WebAssembly for noobs? I've read articles here and there seen some in person demos, and honestly struggle to understand what it is / how it would / works relative to the current state of JavaScript frameworks. Often I'm approaching it from a JavaScript framework (React/Vue/Angular) approach as I'm a bit of a noob to the industry and that's generally my day job working on…

I just recently learned a lot about it just by reading spec and few articles on MDN. Wasm is an extremely simple bytecode, very similar to Java bytecode. You can even write it by hand.

Basically you're supposed to use it for some performance-critical parts in your application. You're not supposed to use it instead of React.

Re: W3C recommends WebAssembly

#254
post #52

Earlier quoted context omitted.

When was the last time you were able to unminify a javascript file that you wanted to investigate and were able to make sense out of it?

Within the last month or two, certainly. You have to be willing to edit it, start renaming variables to describe what they hold, rename them again if they get something unexpected assigned, rename functions once you have a good idea of what they're trying to do, and repeat until everything has a name.

Wasm is very easy to understand. I guess it lacks tools for proper reverse-engineering, to allow defining meaningful names, to use some sane language instead of default Wasm text format, but once tools will be there, it'll be much easier to understand than minified JavaScript because it's so simple.

Re: W3C recommends WebAssembly

#255
post #208

Earlier quoted context omitted.

It's ridiculous because you're claiming that HTML is "the web", but that somehow the content that HTML marks up is "not the web." I can guarantee that no one was looking at a Java applet or a Flash site in the 1990s and thinking "I don't know what this is, but it definitely isn't part of the World Wide Web." >Yes, one could say that the Web has "jumped the shark" sometimes after 1997 (took some years), remember the m…

Some examples of search results from Facebook / Discord / Twitter ? And on the same level as other pages, not in some separate field ? Browsers can do a lot of things these days that are not part of the Web : display pdfs, ftp folders, rtsp streams... The browser becoming an OS inside the OS is at the crux at the issue. (And the main reason is likely Google trying to wrest control of personal computing from Microsoft…

> Some examples of search results from Facebook / Discord / Twitter ? And on the same level as other pages, not in some separate field ?

What does a "separate field" have to do with anything? Now a site is or isn't part of the web based on how Google formats them in their search listings? These sites serve media meta-tags specifically so that Google will index them, they depend on SEO. Find someone famous with a Twitter or Facebook presence and search their username and whatever public information they have, including excerpts of recent posts, will probably show up.

>Browsers can do a lot of things these days that are not part of the Web : display pdfs, ftp folders, rtsp streams...

But your assertion was that websites which use javascript to render text, applets or flash weren't part of the web, but somehow just part of "the internet," despite everything on the web also being on the internet.

We seem to fundamentally disagree on what the web is - it seems like your definition is more aesthetic than technical, and that you believe only static HTML pages should be considered part of the web.

But according to at least the w3C's Help and FAQ page[0], the difference between the internet and the web is:

    The Web, on the other hand, is defined in W3C's 
    Architecture of the World Wide Web, Volume I as 
    follows: "The World Wide Web (WWW, or simply Web) 
    is an information space in which the items of interest, 
    referred to as resources, are identified by global 
    identifiers called Uniform Resource Identifiers (URI)." 
And in the Architecture of the World Wide Web[1] page we see a lot of information about URIs, HTTP requests, XML etc.

But nothing supporting the claim that "If your "web"site can execute arbitrary code, and/or violates HTML guidelines (...) then it might be part of the Internet, but it's certainly not part of the World Wide Web!"

I mean, the and tags were added in HTML 3.2, and the reason had a "type" attribute was that the intent was for browsers to support multiple languages. It seems kind of absurd to argue that somehow embedded code was never intended to be a part of the world wide web, when it was considered so early.

No one who was actually involved in the architecture of the web appears to have ever had such a rigid definition of it, or such a limited vision of what it should or shouldn't be. Here's a thread from the www mailing list from 1995 about web scripting languages[2], I don't see anyone arguing that the concept is fundamentally hostile or antithetical to the web or HTML. Rather, as hackers tend to do, they discuss the ramifications and pros and cons and possible implementation.

You may not like that this is the web, you may not agree that this should be the web, but this is the web.

[0]https://www.w3.org/Help/#webinternet

[1]https://www.w3.org/TR/webarch/

[2]https://lists.w3.org/Archives/Public/www-talk/msg00099.html

Re: W3C recommends WebAssembly

#256

Earlier quoted context omitted.

Why should someone else's website code forced to be "free"?

Because otherwise it's not a website? "By the end of 1990, the first web page was served on the open internet, and in 1991, people outside of CERN were invited to join this new web community. As the web began to grow, Tim realised that its true potential would only be unleashed if anyone, anywhere could use it without paying a fee or having to ask for permission. He explains: “Had the technology been proprietary, and…

1. We're well past websites into web apps. You are not entitled to the source code of these apps, like Gmail/GSuite - that are client heavy web apps, with logic, state, custom-IPs & algorithms.

2. The underlying code of the web's infrastructure is available on a royalty-free basis, and shall remain as such!! There's immense benefit in maintaining this equal-opportunity status-quo.

Re: W3C recommends WebAssembly

#257

Whatever you think about javascript, I love the historic separation between content and interactivity. I dislike that so many static pages won't load without JS and that we're moving further in that direction. I hope the evolution towards "browser as OS" doesn't hurt the content vs interactivity separation. Could we ever lose the HTML centered model? That could mean we lose hackability and the ability to write extens…

There's a push towards more server-side rendering, though it's generally a pain in the butt at the moment.

Also, executing JavaScript when scraping isn't that difficult, depending on what you're using to scrape. Node.js has Puppeteer: https://github.com/puppeteer/puppeteer

Re: W3C recommends WebAssembly

#258

Earlier quoted context omitted.

This is not a design opinion to me. Unless your application state can be represented as pure text, it can not be efficiently conveyed to blind users. So we force you to do that. > It would be better if the web browser world had pixel level render targets We also have escape hatches when you need pixel controls: Canvas, and webGL which can be rendered to a Canvas. The only difference is that they're not the core that…

>In the browser, text is your pixel. Of course you are welcome to build things on top of that with CSS, images, and Canvas. More to the point, I'm not saying that 95% of the time you should abandon your design and make a minimalist terminal interface -- I'm saying that for 95% of the phone apps and native apps I see, HTML would be fine. There is a pretty good chance the design someone has come up with is already repr…

> into something like this

Unless I'm misunderstanding, this example seems to be exactly what I'm talking about.

Even in its current state, there are only 2 or 3 things on this page I can see using Canvas. Everything else is already using HTML and CSS. It's not even lazy-loading the images -- this is a static page that is dynamically generated. And yet despite ultimately being a static page, it works fine. Great even, it's responsive if I resize the browser. HTML is doing everything you would ever need here.

You can use Canvas for the (optional) background animations in the deep water, Canvas (or gifs) for a few minor animations like the waves on the top. You use a very small amount of JS to update the text tracker and swap the sub to a fixed position when you hit its scroll-point. The sub is already an image being animated via CSS, so you're doing that correctly.

To me, this page is the perfect example of something that has an incredibly simple tree-based UI that is nevertheless being dynamically rendered with webGL for some inexplicable reason. I'm actually a little annoyed that it doesn't currently work with JS disabled. I wouldn't expect the depth-tracker to work without Javascript, but I should still be able to at least scroll to the bottom and see all of the pictures and text. It would not be hard to make this page degrade gracefully.

What do you want this page to do that isn't possible with the current state of HTML/CSS? I might be missing something, but I don't see what the complication is.

> In my opinion what you see as 95% of all user interfaces is largely a because HTML and CSS are the rendering target not the other way around.

I'll make a bolder claim then: 95% of native apps are just interactive documents (with a few category exceptions like games), and most native developers who claim that their interfaces couldn't be represented on the web in HTML are kidding themselves. In the majority of cases, HTML/CSS would be fine for what they're building.

Re: W3C recommends WebAssembly

#259
post #160

Earlier quoted context omitted.

Unless I'm completely missing something the "text version" you're talking about is just WASM and there's quite a difference between that and minified JS. ex: end $label121 get_local $var7 get_local $var9 call $func3444 get_local $var7 call $func1500

Yes this is what I am talking about. Once you know the instruction, I fail to see how it is more difficult to understand than javascript.

That's like saying x86_64 assembly is as easy to understand as C. High level languages exist to make code easier to understand.

Re: W3C recommends WebAssembly

#260

Whatever you think about javascript, I love the historic separation between content and interactivity. I dislike that so many static pages won't load without JS and that we're moving further in that direction. I hope the evolution towards "browser as OS" doesn't hurt the content vs interactivity separation. Could we ever lose the HTML centered model? That could mean we lose hackability and the ability to write extens…

Funny thing is, that JS lead to exactly that, separation of content (APIs) and interactivity (PWA/SPA)
Post reply on HN