W3C recommends WebAssembly
w3.org
w3.org
That could mean we lose hackability and the ability to write extensions or even scrape the web without a BigCo webcrawler's level of infra investment. Is everything going to turn into an opaque single page app? Technically, webassembly is really cool, but I worry about where the browser is headed.
I'm not trying to be overly cynical here, all of these topics remind me of high school when I'd download mildly-sketchy executables, decompile them, and try figure out whether or not they were safe to run. I would love to poke around with reverse engineering wasm, but I'd rather not have to do that every time I visit a new website.
(Trackers using these kinds of tactics was only a matter of time between trackers and blockers...)
(Example of the day, Parsec; example from yesterday, NVidia's driver-update software :( )
If your "web"site can execute arbitrary code, and/or violates HTML guidelines (required for web crawlers or accessibility software to work, or for browsers to tweak the layout) and/or requires JavaScript / Flash / Java to run properly, then it might be part of the Internet, but it's certainly not part of the World Wide Web!
The WWW is a network built on a set of protocols. HTML is a markup language that allows for (indeed, that is is designed to facilitate) embedding and linking binary and executable content, including javascript, flash, java, audio, video, as well as marking up text. HTML is one, but not the only, content-type which can be distributed across the WWW. This is fundamental to the design of HTTP and the intent of HTML and the web itself.
By your rationale, no site created after the addition of the <SCRIPT>, <APPLET> or <OBJECT> tags in HTML could be considered a part of the WWW, which would exclude the entirety of the web after HTML 3.2. This is "not even wrong" levels of ridiculousness.
Yes, one could say that the Web has "jumped the shark" sometimes after 1997 (took some years), remember the mess when Flash and Java applets were everywhere ? (WebAssembly might be more sleek, but the issue is likely to be the same...)
I guess that multimedia could be part of the Web, but support for basic features like audio/video search is (still!) sorely lacking... (Though I'm pretty sure that the capability has been here for more than a decade.)
With the ability to run arbitrary code comes the loss of a common standard, and therefore the inability to communicate, especially for machines - you might have noticed that you hardly see search engines pulling up results for supposedly "Web"Sites like Facebook or Discord or Twitter ?
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 mess when Flash and Java applets were everywhere ?
On the other hand, Flash allowed animators and game developers an outlet for creative expression and distribution and led to an explosion of content, and launch more than a few professional careers. And Java applets... existed.
At the very least, I think it's controversial to say the web jumped the shark at that point.
>you might have noticed that you hardly see search engines pulling up results for supposedly "Web"Sites like Facebook or Discord or Twitter ?
I do see those results in search engines. Visibility in a search engine is a result of SEO and those sites' indexing rules, it has nothing to do with whether or not a site is part of the web - if I can reach it in a browser, it's part of the web by definition.
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.)
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)."
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 <SCRIPT> and <APPLET> tags were added in HTML 3.2, and the reason <SCRIPT> 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
It's about trying to push too many things on the Internet through HTTP, about trying to transform the browser into an OS inside an OS (which is a lot about the Microsoft vs Google battle over personal computing).
Protocols, not platforms ! https://news.ycombinator.com/item?id=20841059
HTML and CSS standards were always at least 10 years too late. If you wanted something that looked modern you've always had to use browser-specific extensions, plugins or, at best, "beta" features.
Seriously, I know that nowadays many devs have started straight with web technologies and don't have a lot of experience besides that but if that's your case do yourself a favor and give a quick look at a proper UI toolkit like Qt. Would it blow your mind if I told you that you can create a complex treeview without having to use third-party libraries or reinventing half the wheel yourself? Crazy, I know.
If anything this "historic separation" and people who still hold onto it might be one of the reasons the modern web is such a messy patchwork of technologies, if web engineers had accepted that an open source Flash was actually the endgame and not a problem we might have saved us some time and some trouble.
To be clear I'm not saying that it's a bad idea per-se, I personally believe that the web is way too complicated as it is, I just feel like it's similar to arguing that "literally" shouldn't be used to mean "extremely" in modern English. Sure, I get your point, but I don't think it's a battle you can win.
No, not any more than C#'s giant standard library blows my mind.
Keeping the web small is a strategic decision -- it may look like chaos, but it's really just that we realized that embracing 3rd-party libraries is a better architectural decision than polluting the core spec with features that will be outdated in a few years.
QT doesn't have these problems because QT doesn't have to be infinitely backwards-compatible. If QT makes a mistake, it can fix it in the next version. The web can't do that, so we have to be more careful. If anything, my biggest criticism of the web is that we move too quickly and stick too many "modern" features in. I would have been happy to drop Classes and Arrow Functions from the JS spec, and I would have been happy to drop `sticky` from the CSS spec. As an engineer, I absolutely don't want a hamburger menu as a core HTML component.
I've had people argue to me that HTML needs more 2-way data binding and element types -- they want the ability to tie a list to a JSON object or something, instead of needing to render out separate `<li>` elements. These people are missing the point.
HTML is your user-presented state. We have a few elements that break this convention, but for the most part we want your final HTML to be static and human-readable. It's not for you, it's for your users. And 2-way data bindings would get in the way of that.
For laying things out and creating complicated lists, we have third-party libraries/frameworks -- and honestly, they work fine. If you think the web is overcomplicated or has too many frameworks right now, just wait until we start stuffing a new first-party component into it every time any design trend becomes popular.
And even if we did add all of that nonsense, people would just ignore those components anyway. No manager I've ever worked with has ever said to me, "you know, pure HTML select inputs look great and I don't mind them rendering differently in different browsers." I would be reimplementing them in JS anyway just to get the styling consistent between IE and Firefox. The good HTML components I can actually use are the low-level ones like simple input fields -- because they're small and simple enough that they can be styled and incorporated into larger custom-built solutions.
Heck, I've had managers complain to me about scroll-bar styling before. But sure, they'd totally be happy with a giant, pre-built, monolithic tree-view component that's using mid-2000s styling.
Maybe not.
If data binding, dynamic markup, reactivity, etc, were baked into browser we'd save a ton of kbs and CPU cycles.
This is one place where HTML does not give enough primitives for a quality library-based solution.
For better or worse the web never did that work, HTML+CSS+JS is meant to be both a way to make static websites, but also interactive e-shops, but also mail clients, but also videogames, but also ultra-heavy single-page apps like Discord etc...
And that's the greatest power of the web, but I can't see how this state of affair won't lead, one way or the other, towards a more monolithic architecture. Keeping HTML and CSS cleanly separated and JS only for the fancy stuff (but always optional!) is noble but it's a pipe dream when the use cases are so diverse. WebAssembly, or something like it, seems to be clearly the path forward.
Overall I think we should be happy too, at least it's not a closed source blob. Remember how long it took us to get rid of bloody Flash? Actually if Steve Jobs hadn't decided to drop it from iPhones I wouldn't be surprised if it had survived in common use to this day.
It shouldn't be necessary to toss out the cookie jar, the HTTP connection handler, the XSS protection just because one wants to do something a bit different with the final rendering stage.
And, as they say : > It would be useful to establish guidelines for "firewall-friendly" protocols, to make it easier for existing firewalls to be compatible with new protocols.
I believe that the Internet is fundamentally about protocols, and that platforms are to be banned if we care about it : https://knightcolumbia.org/content/protocols-not-platforms-a...
To turn the question sideways a bit, there's nothing stopping some conglomeration from developing an alternative to 802.11 standards. All they have to do is create the hardware, convince people to use the hardware, create software to adapt a novel protocol to the higher layers of the networking stack to make it usable by application software (including addressing all of the ways that a new lower layer inevitably breaks an abstraction or two), and create the tooling necessary to make an ecosystem of non-802.11 wireless devices easy to install, maintain, and interoperate.
... But outside of particular special applications where something about 802.11 protocols or the frequencies they communicate upon makes them an ill-fit, there aren't many reasons to do so. Good enough displaces perfect in the common case.
The opportunity cost to do that with a brand new protocol instead of taking advantage of HTTP's flexibility to build new protocol atop HTTP is high.
Nobody's stopping anyone from building new protocols... Except, of course, the fact that nobody wants to adopt a new protocol. But if someone does come up with an indispensable alternative to HTTP(s), it should find traction, right?
"Why use the HyperTEXT Transfer Protocol for things completely unrelated to text..."
If Google agrees with you, would we want to stop them?
It's not just text transfer... HTTP also goes hand-in-glove with HTTPS, which is a technology few people want to build an alternative for (and fewer people should be trusted to do correctly).
There's a very good reason that so many systems block everything except port 80. Does the idea of protocols instead of platforms address that reason? Because most people don't want to make themselves vulnerable to attacks along threat vectors they aren't even aware exist.
Elaborate? Rather than using different ports for different protocols and filtering what you don't want/need, you instead tunnel everything through port 80 and effectively don't filter at all?
HTTP has both elaborate tooling for deep packet analysis and a battle-hardened secured protocol, which we don't get with new protocols.
These days, don't you think that consumer routers sold without firewalls should be about as illegal as selling cars with only motor braking ?
We have globally networked local Networks of locally networkable Networks and most of us naively think that this Global Network of Local Networks networking Local Networks actually functions as a universally internetworking Internetwork of universally internetworkable Internetworks internetworking internetworkable Internetworks internetworking internetworkable Networks[([¹]1)], because we trust the people who've labeled both IPv4 and IPv6 as the "Internet Protocol" despite it not in any way, shape or form having the ability to perform what the people who came up with the concept of internetworking (no, NOT the ARPA people.) actually meant by the term.[2]
As the simplest proof of this fact: We've almost reached 2020 and all of our 'solutions' for multi homing don't ACTUALLY work in a not-pants-on-head-dysfunctional despite the fact that we've faced that issue since, to quote Wikipedia, "In 1972, Tinker Air Force Base wanted connections to two different IMPs for redundancy. ARPANET designers realized that they couldn't support this feature because host addresses were the addresses of the IMP port number the host was connected to (borrowing from telephony)."
Our 'Inter'net at the moment still resembles just a global network, aka just plain old phone calls, with extra steps. Which explains both the mess we call the WWW, and the global dominance of large telcos.Can't give an AS number and BGP access to just anyone[([²]4)] , as we know ever since L0pht Heavy Industries testified before the US Senate, over 2 decades ago, back in 1998.[3] NOTHING has fundamentally changed about this since. We've just written bigger and bigger macros ignorant of why we keep having to fight windmills & having to reinvent the wheel over and over again.
[1 (¹ yes, I did intentionally phrase that in & as a reference to a certain Cisco exam question.)]
[2 see https://news.ycombinator.com/item?id=21108796, but also see http://ict-arcfire.eu/index.php/rina/ & http://ict-arcfire.eu/wp-content/uploads/2018/06/OCARINA-ind... ]
[3 https://youtu.be/VVJldn_MmMY]
[4 (² Of course, I don't advocate that we should. No. I do however argue that each of these situations shouldn't exist in the first place.)]
I think that while this is technically true, technical adequacy didn't lure developers away from Flash player. I believe that the real turning point was when Apple decided to break Adobe's monopoly on the web by disallowing Flash player on all their products.
The G3 iMac did not include a CD writer, so if you wanted to use writable CD to get data out of your iMac, you needed to buy an external drive.
You aren't quite right on writable CD being wide spread then--you are early by at least a year or two. When the G3 iMac came out CD-R drives were still above $300, and CD-RW drives were above $450. CD-R discs were around $2 a disc, and CD-RW discs were more like $15-20 a disc. (I'm getting prices from the November 1998 issue of MacWorld).
My recollection is that the usual ways people dealt with the lack of floppy were:
1. External floppy drive.
2. Iomega Zip drive. An external Zip drive suitable for use with the G3 iMac was about $120 when that iMac came out.
3. Ethernet to exchange files with another computer on the LAN that does have a floppy.
I thought HTML was developed with HATEOAS in mind. So I don't see the seperation as a technical limitation but a powerful abstraction. Flash was what people wanted but HTML was what a good web needed (imagine the internet with only Flash/WebAsm from the beginning).
For example I’m a huge fan of the declarative UI trend going on in the web community. Now, granted, Microsoft came out with MVVM and XAML way before React or Angular existed, but native UI libraries are so historically imperative that declarative UI wasn’t making much of a dent in the native sphere.
But even though these older native frameworks are imperative, they are much more powerful than anything like React out of the box. They’re much more comparable to component frameworks like Bootstrap, SemanticUI, AntD, etc. But even still, those libraries don’t come anywhere close to the power of Qt or UIKit in iOS. If you’ve used both, I can’t imagine you saying that it’s even close.
But it’s precisely because of the tension between the web as a document platform vs. the web as an application platform. The web has never doubled down on being an application platform, it always keeps its document roots in the background in some way. Personally, I’m torn. I love the transparency and inspectability of the web. Literally yesterday I opened up the dev tools inn twitter and I learned about its timeline architecture just from inspecting the requests. This is the biggest thing I miss when I’m working on a native app.
But WebAssembly may be the web finally doubling down on being an application platform. Whether that’s good or bad is irrelevant at this point. It’s the direction it’s headed in.
QT is a third party library that wraps the underlying OS primitives.
A really fancy tree view in JS is 10KB, maybe 15KB, given desktop+mobile support, proper accessibility, and good support for theming.
And that is if you are getting really fancy. A simple one is just some DIVs and a CSS animation for opening and closing.
That is assuming you even bother with JS, since you can do a treeview in the browser with CSS alone[1].
UI toolkits exist for the web as well, and they tend to be rather small, browsers ship with a lot of UI primitives after all!
The UI portion of code for my B2B web-app with all custom UI elements and with mobile+desktop support is around 100KB unminified.
Now the libraries I pull in to do the real time database streaming and authentication to my back end? Those dwarf the UI code (they are hundreds of KB each), but the native versions of those libraries are far larger (10x)[2], than the JavaScript equivalents.
> Would it blow your mind if I told you that you can create a complex treeview without having to use third-party libraries or reinventing half the wheel yourself?
The browser comes with a lot of wheels included, very few are getting re-invented unless someone wants indulge themself.
> To be clear I'm not saying that it's a bad idea per-se, I personally believe that the web is way too complicated as it is
Get rid of the weird things that happen to make advertising possible and most websites are pretty simple. Even complex web-apps are pretty easy to understand now days, though you'll have to learn whatever data-binding technique the dev team decided to use, but that is the same case for modern desktop applications.
[1]https://codepen.io/kobusvanwykk/pen/NqXVNQ
[2]https://stackoverflow.com/questions/41750553/what-is-the-est...
This is what people should be worried about, not replacing JS. It became a kind of popular hot-take for a while to say that separation of concerns was a mistake, and that's not how apps get built in the real world, and what we really need is a way to encapsulate all of our DOM and CSS in JS. We need to start pushing back against that idea and keep emphasizing that separation of concerns is really important for end users.
HTML is the interface you write to. It's not a document layout language for authoring, it is a render target that is understandable and manipulable by the end-user. It's a fantastic idea that enables a lot of user-land innovation, and it's one of the biggest reasons why the web is still a relatively good platform to interact with as an end-user.
A lot of architecture decisions on the web haven't aged well, but separating content, styling, and logic was a fantastic architecture decision that is still as relevant today as it ever was. And the rise of the web as an application platform has only made it more important, not less.
Separation of concerns happens because the render target is a over complicated mess. So separate the good parts out of the mess as much as possible but the mess is still there.
Of course HTML for interfaces is more complicated than something like canvas, because it forces you to think about your UX on a deeper level than "this component should be on the left". The point of HTML is that it forces you to build a universal interface that works for everyone -- it forces you to sit down and build a human-digestible, pure-text tree that communicates your current application state to users.
HTML on its own is a render target. CSS is a completely optional secondary display modifier that you put on top of that render target.
This is why adblockers work, it's why stuff like Reader View works in Firefox. Because it turns out that forcing interfaces to be pure-text has substantial benefits for end-users. Try building something like a UI-level adblocker for a native app. You can't do it -- it's impossible.
This is a design opinion. I disagree with it. Minimalism is simply a design philosophy just like brutalism or complexity. The underlying mechanisms should be design agnostic.
>HTML on its own is a render target. CSS is a completely optional secondary display modifier that you put on top of that render target.
Sort of like turing completeness, HTML on its own is not "render" complete. There are many objectives that cannot be achieved with HTML alone. You must consider aspects within and outside of your "design philosophy" as the modern browser is intended to be a universal platform for multimedia applications. This is why HTML alone cannot be the render target.
Render targets are usually more fundamental with libraries built on top for more specific use cases. It would be better if the web browser world had pixel level render targets with HTML built on top as a library. This is how most graphical APIs work. Rather then what is now, HTML as the render target, and canvas as a child object of HTML.
This maintains "render completeness" and gives users the ability to use higher level DSLs like HTML + CSS or to (switch to)/write another library.
>This is why adblockers work, it's why stuff like Reader View works in Firefox. Because it turns out that forcing interfaces to be pure-text has substantial benefits for end-users. Try building something like a UI-level adblocker for a native app. You can't do it -- it's impossible.
while this is true I wouldn't center the design of a platform on whether or not ad blockers work for it. It is not central to the problem which is the creation of a universal platform that is versatile. Rather it is the implementer of the adblocker who must conform to the platform.
> 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 HTML is based on. This is on purpose, because using Canvas should be very rare. You should embed your (rare) pixel-based rendered component into an HTML tree with appropriate non-visual markup around it to describe what it is and what it does.
Pixel-level render targets are a design antipattern for most apps. Not all apps (games for example), but the vast majority of them.
To me this isn't a design thing -- it's a purely practical decision. Your app state needs to be accessible to people, people need to be able to build on it, programs need to be able to parse it and manipulate it, it needs to be responsive when high-definition displays or Apple Watches come out in the future, and it needs to degrade gracefully when parts of the browser stop working. We've been able to observe for a long time that apps that are built this way are better for end-users.
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 representable in pure text, and they just haven't thought hard enough about how to do it. I'm not saying design everything minimalist, I'm saying your design is probably already a lot more minimalist than you think, and it probably wouldn't be that hard to separate content from pixel-positioning and style for most apps.
This is your opinion, and your opinion deserves to be fulfilled. My opinion is that the web is a multimedia platform that can do combinatorial designs where text motion and visualizations can be combined into something like this:
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. There are less games and those types of UI interfaces on web browsers because HTML + CSS is bad for doing those things.
So if we have different opinions what's the best way to fulfill both? Libraries. One library for your text based philosophy and one for mine. The lower level technology should be agnostic to both of our opinions. What I don't like is having to submit myself to your design philosophy and write my canvas library on top of HTML + CSS.
webassembly makes logic language agnostic on the front end. It's time to do the same for the "render target"
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.
The point isn't whether or not you can do this in CSS + HTML. (Which by the way CSS + HTML is proven to be turing complete so you can actually do anything in CSS + HTML including writing a JS interpreter so you can use javascript on non-JS enabled pages)
The point is to get to the above, you need to basically hack your way there. HTML + CSS is not the ideal medium to program something like that in. It would be better to have a library written over a pixel level API to construct the interfaces you see in the page rather then either hack your way through HTML and CSS or create a library of hacks on top of HTML and CSS.
>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.
Sure make that claim, even if it were true nobody wants a computer to just be a platform for text based UI. Nobody wants the internet to be JUST that. People want the computer to be a universal computing platform. Games may be category but it's a huge category as no one will buy a computer that only has the capability of displaying text, they buy it for the computing potential to do anything.
Heck under your logic, why even have the OS expose the pixel level api? Just have the OS expose a DOM. 95% of apps are that way so an OS that does this is perfectly fine.
If you want to restrict the potential of what the internet is, then yes. If you want to expand it while keeping your design philosophy in place then the platform must expose a pixel level API and HTML and CSS must be moved to a library. It makes no sense for a lower level library to be written as a component of a higher level library, it should be reversed.
It won't look right because it literally blanks out the page if Javascript and CSS aren't enabled. That's not a limitation of the web, that's a conscious design choice by the author.
Without CSS, what this would look like is pure data -- a list of animals with a picture and their relevant depth printed next to them. It would be perfectly functional. This is your render target: "what is the information that I wish to convey?"
Now we move to CSS and we make things pretty. A pure CSS/HTML version of this page would look pretty much the same, it just wouldn't have animated backgrounds or an interactive depth calculation. But it would still look nice, and it would still get the point across.
Now we move to JS and we add fun touches like an animated background and interactive depth view. And at this point, we're back to the original page layout and we haven't sacrificed anything at all to get there.
> The point is to get to the above, you need to basically hack your way there.
I want to be clear here -- I'm not advocating for a less experimental, uglier web. The reason you (or whoever the author is) needed to hack their way to this page is because they are over-complicating and over-engineering their UI. This page is using a CSS grid, for no reason at all. It's pulling in webGL code to render a background that could be handled with a simple Canvas. None of the elements on the page are in the right order, so good heckin luck trying to read this if you're blind. Even though, to be clear, the information this page is displaying is an ordered list of animals with some text next to them.
There is zero reason for this page not to be accessible to blind people. There is zero reason why this page can't degrade gracefully without Javascript. Making it accessible would not require you to compromise on the design or the visuals in any way at all. It doesn't need React, it doesn't need inline styles, it doesn't need CSS grid -- you could build the exact same page with no frameworks, and the code would be cleaner and easier to understand.
> Heck under your logic, why even have the OS expose the pixel level api? Just have the OS expose a DOM. 95% of apps are that way so an OS that does this is perfectly fine.
I'm not going to go quite so far as to advocate that native apps shouldn't have direct access to a pixel-level API. And from a pure engineering perspective, it does make sense to build high-level controls on top of low-level ones. But what I will say is that on Linux right now, we still don't have fractional scaling in Gnome, very few of the native apps are responsive, and most will break layouts if you try to mess too much with your OS's font-size or settings. The last time I talked to the MyPaint devs about building a touch-friendly version of MyPaint with bigger buttons, they told me it was impossible because of whatever Python-based widget library they were using. And holy crap, the menu/toolbar in MyPaint is not complicated. If the widget library doesn't support fractional scaling, it doesn't mean that MyPaint menus are doing something crazy or revolutionary, it means the Python widget library being used is crap.
And that kind of makes me think, if we had forced native developers to use an HTML-like interface instead of building pixel-perfect interfaces that aren't future-proof, would touchscreen Linux on HDPI screens be in such an awful state today? Would Purism have needed to rewrite half of Gnome's apps to get them working on a phone?
I'm not sure I agree that the state of native apps is perfectly fine. And I definitely disagree that caring about stuff like accessibility necessarily means that you can't be creative, or that we'll be holding the web back. I think that 95% of the native apps on your computer are probably text based UIs, except they've got a little bit of styling applied on top of them to turn unordered lists into drop-down menus. We have escape hatches for the web apps that are more complicated, that genuinely need to do crazy pixel-level things. Most of them don't.
It's not about getting rid of that styling, it's not about making things ugly. It's about recognizing that we're working twice as hard for interfaces that are half as functional as they could be, and we wouldn't need to sacrifice any of the fun visual stuff we're doing to improve that situation.
No. The author wishes to convey a multimedia experience. This is evident, the page is unique because of this.
The author does not care to convey just textual information. You're just breaking down the core components of the system and picking the one that's required to have any semblance of a page. The "fun touches" are ultimately required. It's like a script vs. a movie, the movie isn't required and the script is ultimately all that's needed but nobody cares about the script do they? It's not even embedded in the movie.
>I want to be clear here -- I'm not advocating for a less experimental, uglier web. The reason you (or whoever the author is) needed to hack their way to this page is because they are over-complicating and over-engineering their UI. This page is using a CSS grid, for no reason at all. It's pulling in webGL code to render a background that could be handled with a simple Canvas. None of the elements on the page are in the right order, so good heckin luck trying to read this if you're blind. Even though, to be clear, the information this page is displaying is an ordered list of animals with some text next to them.
I have to be honest with you, and this is cruel. But when I design a page... I don't care for blind people. I don't focus my design so that it will cascade down into something blind people can read. Books don't have this property, movies don't and because of this... neither should web pages. It is not worth the effort.
>I'm not sure I agree that the state of native apps is perfectly fine. And I definitely disagree that caring about stuff like accessibility necessarily means that you can't be creative, or that we'll be holding the web back. I think that 95% of the native apps on your computer are probably text based UIs, except they've got a little bit of styling applied on top of them to turn unordered lists into drop-down menus. We have escape hatches for the web apps that are more complicated, that genuinely need to do crazy pixel-level things. Most of them don't.
I never said native apps are perfectly fine. I'm also not advocating all sites be designed with pixels. What I am advocating is freedom from HTML and CSS. If the platform of the browser exposed pixel level control with HTML and CSS only as a library and given the amount of people who hate the CSS + HTML... it's almost a guarantee that people will create sibling API's that are on the same High level as HTML + CSS but offering different philosophies. There are multitudes of UI layout languages and tools out there, who said HTML and CSS was the best, and why does it have to be the only way?
That's all I'm saying. You expose pixel level control at the core for the purpose of being able to use and create multiple high level libraries rather being vendor locked into HTML and CSS.
I do want to mention very quickly that on the subject of books and movies, literally every Hollywood movie you can buy ships with subtitles for the deaf, and since ~2015 US law has required that new theaters also include equipment that provides audio descriptions for blind viewers[0]. And I don't know anyone who would seriously claim that the Godfather is lessened as an artistic expression just because deaf people can turn on subtitles.
[0]: https://www.govinfo.gov/content/pkg/FR-2016-12-02/html/2016-...
This world already exists. You're delusional if it doesn't. I use the word cruel, but you must know that cruel = reality. That's all I'm saying. 99% of the world is not designed for deaf people or blind people. There are arbitrary restrictions on certain things but this is reality and it's not going to change because engineering everything to account for these people come with an engineering cost.
It is not "pointlessly excluding," it's just not worth the engineering cost. But you know this. Any person is aware of this and the reality of the world. There is zero need to call it "pointlessly excluding" that's just a manipulative way of advocating your agenda.
>And I don't know anyone who would seriously claim that the Godfather is lessened as an artistic expression just because deaf people can turn on subtitles.
I don't know either. Did you or I make this claim? Perhaps nobody made this claim and your pulling this example out of nowhere to serve your agenda. You know video games don't account for blind people. This is purely out of cruelty of course, no way does it have anything to do with engineering cost. Obviously you don't know a thing about the cost of engineering mechanisms to get these games to work for blind people so that's why you didn't mention it. Of course it wasn't at all a deliberate choice not to mention the engineering cost to serve your own agenda.
It's not a coincidence that this design also increases accessibility -- it encodes the most meaning.
Please stop accusing everyone of being biased and having an agenda. Not that there is anything wrong with that, since everyone is biased and has an agenda (including you), but the way you're saying it makes it sound like you think it's an important component of other people's comments but not yours.
Ok first of all. There is no universal law that says everyone has to be biased and have an agenda. There's no logic to it. This false notion comes from the fact that most people (not all) people are biased and that when people are biased they are unaware of it. However this does not mean that people can't be unbiased or have no agenda.
Second: Examine the sentence in reference to that phrase. It is literally word for word referring to "engineering" and Not a specific set of engineering projects.
Literally what you are doing is inserting your own opinion onto what that "engineering" is referring to and I am taking it at face value. So I am not wrong when I say that your observations are biased. There is no accusation here, just observation of events.
Being biased is pretty much a part of the human condition since we are limited, finite beings. Do you have all the information? Are you certain you have all the information? Have you taken into account everyone's wishes, desires, needs, analyzed every possible scenario in existence according to some yet-unspecified objective reasoning system? Then you are biased. You are missing something, you are concluding something erroneously. (using the generic you as a stand-in for anyone)
Your agenda is to incorporate a pixel-level API into the web. And that's okay. Mine is to prevent the web into devolving into an opaque black box. That's okay too.
As to the topic at hand, I won't try dissecting comments word for word, because I think this is a loss of time and devolves into a lot of who-said-what, when we can sidestep it by concentrating on the most charitable explanation.
Reading through the thread again, I think the other poster's point was that there are many situations (not all) where designing things in the simplest and most direct way, using HTML as the semantic underpinning, leads to both less engineering effort and to a more accessible design.
Specifically, I do not think he was arguing doubling or tripling a movie budget in order to make another similar movie for blind people. But then again, we weren't talking about movies. We were talking about web sites, in which the loss of HTML would lead to a net loss compared to what we have now.
No. statements of observation do not have agendas. "The sky is blue" is a statement without an agenda. Statements can be made separate from agendas, which makes the statement unbiased.
>Being biased is pretty much a part of the human condition since we are limited, finite beings. Do you have all the information? Are you certain you have all the information? Have you taken into account everyone's wishes, desires, needs, analyzed every possible scenario in existence according to some yet-unspecified objective reasoning system? Then you are biased. You are missing something, you are concluding something erroneously. (using the generic you as a stand-in for anyone)
This is completely false. Biased, means a leaning of ones mind towards a particular viewpoint. People usually use this word in the context of a leaning of ones mind despite being aware of evidence to the contrary or lack of supporting evidence. If the mind does not lean then it is unbiased.
Your judgement of the statement has leaning towards your agenda despite you being aware of lack of evidence supporting it. My statement does not have leaning.
>Your agenda is to incorporate a pixel-level API into the web. And that's okay. Mine is to prevent the web into devolving into an opaque black box. That's okay too.
This "agenda" had nothing to do with my observations, but for yours it colored your interpretation of words. Your observations were biased, mine were not. This is not something that is Okay. Biased observations are usually false.
Given at face value the sentence is referring to a world of engineering with the context of the web as a specific example out of a more general point. You need to make a biased modification to the sentence in order for it to fit your world view.
>As to the topic at hand, I won't try dissecting comments word for word, because I think this is a loss of time and devolves into a lot of who-said-what, when we can sidestep it by concentrating on the most charitable explanation.
The most charitable explanation is here:
Given the original sentence we are referring to:
"You're not advocating for a bold, artistic world when you talk about engineering things to pointlessly exclude people."
The terms:
"Bold artistic world" "engineering things"
"Bold artistic web" "engineering web pages"
"You're not advocating for a bold, artistic web when you talk about engineering web pages to pointlessly exclude people."
You applied context to the statement relevant to your agenda. I did not. There is no doubt when I say that your perspective is in alignment with your agenda given lack of supporting evidence within the sentence itself. When you are biased you are unaware of it.
Definitively from the logic your statement is biased, mine is not.
>Specifically, I do not think he was arguing doubling or tripling a movie budget in order to make another similar movie for blind people. But then again, we weren't talking about movies. We were talking about web sites, in which the loss of HTML would lead to a net loss compared to what we have now.
Earlier you were rude to me. Therefore I don't care to debate this topic with you. Keep your opinion. I care little for it. If you had chosen more wisely earlier I would have gladly engaged with you on this very topic but since you chose not to, there is now zero possibility of further discussion on this topic.
But the web is not a graphical API and that is precisely the point. The web is a semantic API and its components represent meaning. Devolving to pixels makes drawing graphics easier but it destroys meaning.
When you want to simply draw meaningless graphics, you get an element which represents an element into which you can draw pixels which aren't expected to be meaningfully structured: canvas. What's the problem with rendering into a canvas, again?
And no, HTML not being similar to graphics APIs doesn't count as a downside of canvas being a child object.
> while this is true I wouldn't center the design of a platform on whether or not ad blockers work for it. It is not central to the problem which is the creation of a universal platform that is versatile. Rather it is the implementer of the adblocker who must conform to the platform.
It should most certainly be the center point of this design if you truly want this platform to be universal and versatile, or even usable. It's not like we need to guess how an ad-infested web would look like -- we've experimented with the web of ads, we've seen how horrible it is and the only reason we are still using the web is because we can block those ads.
I'm genuinely surprised how easily some people are to dismiss the openness of the web, surrendering users' freedom in the process, simply for... I'm not sure why actually. I don't understand the argument.
Make the semantic API a library. Or how about seperating semantics from component. Semantics are listed in a single file which can be crawled and only possesses meta data that links to other semantic files. The pixel level API and web crawlers have libraries that can interpret these files. This is a much better design then the adhoc way the web formed.
>What's the problem with rendering into a canvas, again?
It's using low level components as a composition of high level components. The design is backwards and vendor locks people into html. There are other ways to display semantic UI. Html is an arbitrary choice.
> And no, HTML not being similar to graphics APIs doesn't count as a downside of canvas being a child object.
How can you be so sure footed about your argument when you literally say you don't understand the argument later on. You don't understand the argument therefore your entire argument is baseless. Little lesson for you: you need to ask questions and understand before you compose an argument otherwise your wasting time.
>It should most certainly be the center point of this design if you truly want this platform to be universal and versatile, or even usable.
Your saying ad blockers should be the center point of design? You realize that right now in html and css ad blockers aren't the center point of design. An adblock centered design implies something along the lines of replacing the html tag with one that has the word adblock in it. Literally adblockers are designed for the platform not the other way around.
>I'm genuinely surprised how easily some people are to dismiss the openness of the web, surrendering users' freedom in the process, simply for... I'm not sure why actually. I don't understand the argument.
You should of put your declaration of lack of understanding and comprehension in the beginning. That way readers can dismiss your entire argument without first reading it because things need to be understood first before you can make a counter argument to it. Reread my argument until you understand or take some classes at reading comprehension then you'll have what it takes to make an argument.
Honestly let's get a little more meta at what's going on here. Someone has composed a response that is rather rude. The responder dismisses my argument by implying that my arguments are so baseless that he doesn't "understand." Highly offensive. When you play games like this nobody wants to participate in an informed discussion. I'll play his game and say that his lack of understanding makes his whole counter argument ludicrous but literally this argument was over before it even began when the responder decided to be a rude and offensive. If I were the rude responder, I'd just walk away because nobody cares for his opinion anymore.
I'm not convinced it's a better design. It just makes semantics a separate, additional concern, rather than a frontal concern which you have to think about. It allows you to be lazy by not supplying the semantical layer at all, in any shape or form. Granted, you can have document websites with some pretty opaque form even today, but I would argue that enforcing the basic structure of HTML still keeps us in a much better place than we would otherwise end up.
I also don't think the way the web formed was ad hoc when you consider it from a semantical perspective. The most ad hoc bit about it is JavaScript, which was of course necessary due to the expansion of the web into being an application platform.
Pixel-level control sounds wrong to me as a default choice. You don't need pixel-level control in most cases, whereas meaning is crucial, both for humans and for ease of interoperability and extension.
> It's using low level components as a composition of high level components. The design is backwards ...
This is only so due the arbitrary meanings of "low" and "high" you picked here. You're imagining pixels as fundamental, meaningless atoms out of which meaning is built. Why not have meaning at the forecenter, though?
I would argue that having a semantic layer exposed as the front is the right design, not backwards. By default, you have a set of meaningful components composed in a meaningful way. One of those components can be "an array of arbitrary pixels", a canvas to draw on. That doesn't sound wrong nor difficult to me.
Does this argument boil down to the design being "wrong" due to some kind of first principles, or does it genuinely make things substantially harder in a large number of cases? Bear in mind that changing the web like this would also be an exceedingly hard effort.
> vendor locks people into html.
Which vendor would that be?
> There are other ways to display semantic UI. Html is an arbitrary choice.
I agree, but HTML is what we have and it's not half-bad compared to some other things we could have ended up with.
> Your saying ad blockers should be the center point of design? You realize that right now in html and css ad blockers aren't the center point of design. An adblock centered design implies something along the lines of replacing the html tag with one that has the word adblock in it. Literally adblockers are designed for the platform not the other way around.
Let's not get too literal. I was clearly pushing back to your suggestion that we shouldn't take requirement of ad blockers as a design consideration at all.
What I meant to say was that, given the knowledge we have today, any design should take the possibility of ad blockers as one of its central points. Ad blockers need to remain easy and they will remain easy as long as the platform forces you to encode basic meaning in a transparent way.
> You should of put your declaration of lack of understanding and comprehension in the beginning. That way readers can dismiss your entire argument without first reading it because things need to be understood first before you can make a counter argument to it. Reread my argument until you understand or take some classes at reading comprehension then you'll have what it takes to make an argument.
That's uncalled for. I read your argument multiple times and the best I've found is "I don't like being forced to write HTML." Even though you'd need only a small amount of boilerplate HTML in order to get a canvas which then gets you the pixel API you wanted.
I only realized I don't really understand your argument midway through writing that since I consider your request to have a pixel interface reasonable. I just don't consider it reasonable to request to uppend the web fundamentally -- to the detriment of the document platform facet and the use case of writing freely interoperable, transparent documents -- in order to cut away a small bit of boilerplate.
I decided to leave my comment as it was to reflect the time evolution of my thought. You may not like the style of my comment, but it's a bad reason for rudeness and instructing me to take reading comprehension classes.
> Honestly let's get a little more meta at what's going on here. Someone has composed a response that is rather rude. The responder dismisses my argument by implying that my arguments are so baseless that he doesn't "understand." Highly offensive. When you play games like this nobody wants to participate in an informed discussion. I'll play his game and say that his lack of understanding makes his whole counter argument ludicrous but literally this argument was over before it even began when the responder decided to be a rude and offensive. If I were the rude responder, I'd just walk away because nobody cares for his opinion anymore.
I'm not sure, but are you talking about me? I'm truly sorry if I was rude and offensive, it was not my intention to be. That said, I got the same feeling about your responses to other people and the topics of lock-down, opacity and vendor lock-in are dear to me, so I may have got a bit worked up.
React.js has been the most significant JavaScript library in the past decade. Over 50% of JS developers on the web are writing HTML inside JavaScript. In recent years, CSS-in-JS libraries like Styled-components are becoming standard.
We’re killing HTML templates and writing JSX. We’re killing CSS classes and building styled-components. It’s all compiling to HTML, CSS and JS in the end. We just get to do our jobs faster. Why people have a problem with that is beyond me.
Perhaps webassembly doesn't change this either?
I hate the sheer number of files people create in projects. The worst one I've seen is a ".types.ts" file. Everywhere.
I don't generally have a problem with this. I use JSX at work too. My take is it's just another templating system, I don't think it's special. I don't have anything against templating. To a certain extent, my point is that template systems are good -- put your two-way data bindings and special components in them.
When I write JSX though, I make sure it renders out as semantic HTML. If your approach to JSX is, "I'm going to write my render code in JS and output HTML", I don't have a problem with you, you're doing great. If your approach to JSX is, "my interface is just Javascript, so it's fine to spit out poorly organized divs that are absolute-positioned everywhere", then I think you've missed the point of HTML.
React isn't an antipattern. But React doesn't remove your need to think about the final HTML that your app is going to spit out. Apps like Youtube and Twitter are particularly bad at this -- Youtube's DOM is a horrifying mess, it's completely unreadable and way too difficult to work with or style. It's not because they're using a component system to build it, it's because they're fine treating the HTML as a non-readable render target. They don't care about HTML as a user interface.
The broad mistake people make on the web is to look at HTML and say, "because I can't build a scalable app on JQuery and hand-coded HTML, therefore HTML is bad." Google's hot-take with HTML custom components is not that you could put your template logic inside your other component logic -- it's that the HTML layer shouldn't matter at all and you should stop thinking about it.
Separation of concerns is for users, not for you. It's not about where you organize your logic, or even if you mix up your languages into the same file. It's about what gets spit out onto the final page.
> We’re killing CSS classes and building styled-components.
I would caution a bit against doing styles in JS -- not because adding a template layer or JS layer that generates CSS is bad, but because many codebases that I've worked with use CSS-in-JS as an excuse to rewrite basic CSS controls like hover effects in Javascript and inline the remaining styles. That doesn't mean you shouldn't do CSS in JS, it just means you should take the time to use a library that spits out actual CSS and that allows you to take advantage of native selectors and pseudo-elements. React does itself a disservice by using tutorials that teach people to apply styles directly to elements instead of pointing people towards any of the more decent companion libraries that will let you do styling correctly.
Unless your engineering team is the size of Facebook's and you can't communicate about your components at all, you probably should still be using classes. Of course that doesn't mean you can't use JS to restrict class scope or template that CSS. I personally tend to be more of a proponent of BEM than I am of JS styles, but I'm not going to fight someone over that.
Styled-components solves all these problems, randomly generating CSS classes under the hood, while still creating CSS files for you. Check out https://www.styled-components.com/docs/basics#motivation.
I'm not sure I can be sympathetic to "the final HTML DOM output" matching your expectations here. Think about a Dropdown select. We still need to create a library with a bunch of absolutely positioned <div>s here because you literally can't build a good looking dropdown with normal HTML. It's really hard for me to think fondly of HTML/CSS when all they provide is assembly-code level specification. Flexbox and Grid are great counter-examples here. Still no nice looking dropdown.
I want to push back against this in particular, not only because I think it does HTML/CSS a disservice, but because I've maintained codebases that took this approach and they're really bad to work with. You're trading a little bit of CSS annoyance for constant positioning/z-index errors -- and you'll need to update your positions whenever your page scrolls or a component grows... there are just so many ways for this to go wrong, and there's always an edge case that developers miss.
Nothing is absolute, but most of the time the proper way to do something like a custom dropdown selector or tooltip is to semantically group it with the component it's attached to, and then at most absolute-position one element to center it relative to its parent.
<div class="Input">
<input class="Input__Field">
<ul class="Input__Options Input__Options--hidden">
<li>Option One</li>
<li>Option Two</li>
</ul>
</div>
.Input { position: relative; }
.Input__Options { position: absolute; /* etc */ }
.Input__Options--hidden { display: none; }
Again, this doesn't mean you can't compose your CSS in JS. But separation of concerns is not for you. The point is to let me as a user override or ignore your styles, and to keep your styles away from your core content. When you spit out HTML and CSS, you are spitting out an application interface.
You're really worried about where you write your CSS, and I couldn't care less. I just want devs to render clean styles that I can work with as a user, and to stop using JS mouseover events to poorly recreate a hover selector.
I disagree. Build a drop down field using the normal form field elements; it is up to the browser to render them in a suitable way. (Which way is suitable may depend on details which the author is unaware of.)
> The point is to let me as a user override or ignore your styles, and to keep your styles away from your core content. ... I just want devs to render clean styles that I can work with as a user, and to stop using JS mouseover events to poorly recreate a hover selector.
That I agree. Let the user to override/ignore the styles, or to use them without changing if that is what the user wish.
Writing a web application is different than writing a web document (or set of documents). I think what people are anxious about here is that many, if not most, sites are documents or sets of documents, but FE trends are "everything is an app", which leads to difficult situations like "in order to talk to my mom on the Internet, I essentially have to buy into the surveillance state".
We haven't done a good job at letting people do only what they want on the web, because so much of the web has been built by companies with ulterior motives. What people are worried about here--and this is true whether we're talking about WASM, Flash, Java Applets, Silverlight, etc.--is this is a giant leap down the road to a co-opted web, devoid of user choice and controlled entirely by moneyed or state interests.
Personally I feel like this happened a long time ago, so WASM doesn't worry me any more than I already am. But I think it's important to keep in mind more is at stake here than CSS-in-JS, or any one FE's career.
they have a problem with it in that unless you are rendering server side your pages won't work for someone who does not want to enable JS.
In the same way it goes against lots of ways the web has worked for 2 decades in regards to user customization, the ability to scrape content etc. so these things are irritating to anyone familiar with how "things used to be" in the same way that new freeway development destroying an ecosystem can be irritating to people familiar with the beauties of that ecosystem.
For what it's worth I also make my living doing the same thing, but I can certainly see the benefits to the other way.
I'm with you on speration of concerns but HTML is not for rendering; it's for structuring and adding semantics to your documents. (CSS is for presentation control and JavaScript is for behavior.)
It is a matter of time till we see desktop application hosted in a wasm enabled browser.
Rust on the other hand is doing some genuinely exciting, powerful stuff with allowing WASM to talk to the DOM and allowing native developers to target HTML directly within their apps. Rust's approach is to treat the language like a minimal, drop-in replacement for Javascript that doesn't require you to ship an entire rendering engine alongside it.
It is yet to be seen which approach to web portability is going to win. Obviously I'm rooting for Rust, and I personally think apps that are written using Rust's strategy will nearly always be higher quality than apps written using QT's strategy. But that doesn't necessarily mean that Rust will win, there are a lot of factors at play here. It'll be interesting to see.
But agreed, native apps are definitely coming to the web in some form or another. Funnily, the opposite is also true, since there's been a lot of buzz about using WASM for native sandboxing. I like to think that Gary Bernhardt[0] is pleased about that.
[0]: https://www.destroyallsoftware.com/talks/the-birth-and-death...
The kind of jerks who liked adding Javascript to block right-clicking, blocking "Paste" into password fields, etc, are going to absolutely love using the browser-in-a-browser product to deliver their "website".
For the inevitable replies: Yes-- you can already do this with minified Javascript. WASM, being targeted for performance, is just going to make this kind of asshattery faster.
All it will take is for ADK to a have button that produces a wasm version of your app.
To be honest, it's a unique property of the web for you to be able to easily read the source; however, users of other platforms such as Qt are not expected to read the source. The web is simply moving in the direction of all other UI platforms, so I don't quite understand the outrage. Yes, it sucks, but it'll make apps faster than the Electron mess we have now.
Also, arguments of the form of "X is unique, all others are doing the bad thing" are suspicious to me. This would mean we should cherish and preserve X, bringing the good aspect to other platforms, not devolving it into mediocrity or worse.
Every webpage pays for the traffic in some way, and everybody tries to save web traffic as much as possible (optimizing images, videos, minifying JS, CSS ...). It makes no sense to expect, that websites would turn the opposite way just for fun.
I would be very glad, if you can emulate a computer in a browser, so you can e.g. use VirtualBox or VMWare comfortably in your browser. Still, it will be sandboxed (it can not turn off your computer, or clear your hard drive, etc.).
I think the web is the most open, independent, secure and versatile platform today. And I hope it will become even better and more powerful in the future.
Have you not worked in tech long? One of my 'favourite' things about one tech stack I once worked on was that someone decided to implement a file-system inside the a database that is stored on the file system. Even better, the database itself effectively just reimplements the features of a database.
So we have a file-system storing a database that exposes a completely different database that holds a file system.
I'm not talking about the sandboxed browser being able to "clear your hard drive", etc. I'm talking about users having no real agency when it comes to controlling the presentation of websites. (Sure, it's code running on your computer. You're free to attach a debugger to step thru native code that runs a VM that runs a nested VM that's ultimately running the code you'd actually like to influence. Let me know how that goes for you.)
Have you seen JSLinux[1]?
If the embedded browser uses the host's HTTP implementation, then you can filter and edit content there.
If it implements HTTP itself on top of raw sockets, then you can intercept traffic on socket level (although you'd need to MITM any SSL connection).
So, on something like iOS, it could be game over (but I'm also curious what Apple is going to do with wasm there, given that it goes contrary to their strategy of being the gatekeeper for all code running on the platform). But not for the rest.
I think blocking ads is a game you can never win. If you are able to block ads on some websites today, it is just because the site owners allow you to do so (they could easily prevent you from doing so). Ads technologies can evolve to a point when you as a human can not distinguish between ads and the rest of the content.
I can easily imagine a "platform" WASM module which acts as a runtime for other WASM modules built by "app" developers. This Platform module can be easily cached by FAANG or other big commercial interests, similar to AMP by Google (maybe even be pre-bundled into the browser?). The only way to discover, download and run these other apps is through this curated Platform module. All this could be rendered through something like the Canvas API instead of the DOM, which again is managed on a low level by the Platform and in turn exposes higher level API's for the Apps. The Platform also has built in support for Ad networks, tracking, etc., which cannot be disabled without disabling the whole ecosystem of apps. And of course, like any good play/app store, it is completely incompatible with anything else, leading to new levels of Balkanization of the web.
I hope that this isn't the case, and I'm completely wrong about this. But I just can't shake the feeling that as a community, we are championing WebAssembly as purely a performance win, without considering how big commercial interests might seek to exploit this new technology.
Edit: typo with AMP
And from there it is just the next step to run a base platform like Android user space or a simple runtime like blazor.
In the end wasm is a runtime. There were physical Java Processors and I am pretty sure there will be webassembly processors.
Thanks for dooming us all, hombre. I'm holding you personally responsible when it happens.
In fact I think it may already have. Took a look at a web based learning portal for my niece the other day, and after poking around in devtoolsfound it was pretty similar to what you described.
Browsers are large and complicated software packages for a reason. Best of luck to whoever tries to compete with it in a browser in a browser.
Sounds like a slippery slope to me. What makes you think users will be satisfied with load times for something like that, which also probably will have a frustrating-to-use interface?
A third party that offers a way to run that on their iPad at the cost of a one-time 100MB download will find customers.
archive.org also might find something like it useful. How else are you going to show old sites in 20 year’s time?
What won't be great are sites that do this to enforce ad viewing. But if it becomes common enough, you can expect ad-blockers to act on the frame-buffer of that virtual browser.
Anyway, the most annoying will be the stupid people that do that just because "Even Google does it!" "It's webscale!", or whatever people will be saying 5 years from now.
There's some incentive to use HTML as it's indexable but it doesn't seem to be affecting mobile, although maybe mobile is in large part successful because of the web? Like the fact that you can post a tweet or a facebook post or a youtube video everywhere. Not sure that HTML is required for that and if it's not then it seems at least possible HTML will die.
Fortunately advertisers are renowned for their self-restraint, and can be trusted to not abuse this capability to simply shove in as many ads as they possible can, wherever they can, with masses of unblockable trackers underneath it all.
What, exactly, is "content"? Are binary formats content? (Audio, Video, etc?) Are textual comments and notes on other text content, or is only the work being commented on content? Are languages that rely on unicode encodings content? Must content be static or can it change frequently, even second by second? (Stock quotes, for example). Must things be easily scrapeable to be content?
Furthermore, must we lock down the structure of content from now until the end of time as HTML or ASCII, or should future generations be allowed to define what they mean by content?
There may be merit in a separation of content from browser, but we should not artificially limit ourselves to content that only fits into our legacy notion of what a browser is. If the browser must become a general purpose OS that can host whatever content people can dream up, I'm all for it.
The core dynamic of the web, more than document sharing, has been decentralization and removing lock-in and gatekeepers around content distributed through the Internet. As long as we continue to feel that is true (which becomes less believable as browser diversity declines) I feel we should be excited every time the web expands the scope of what can be done with it. It seems likely that 100 years from now, WASM will still exist, and it will allow people to create and distribute software without gatekeepers. If it never existed, or nothing like it did, it seems like the future would have been markedly worse for creators.
Each of these enabling browser technologies that get into the standards should be heralded as having potentially massive positive counterfactual effects on our ancestors and future selves (WebXR being another notable example, landing soon.)
I’d love to see a XAML implementation for wasm, because it’s cleaner than html/css.
Looking forward to .NET Core running in warm.
I could see hackability actually improving since data and API access could be well-defined.
I could see Publishers adopting wasm so their websites are more under their control.
But most of all, software development getting out of the scripting business, which has such a wide range of misuse that it becomes expensive and unwieldy to maintain.
I think JavaScript and WebAssembly are not so bad programming languages, but I do think that scripts in web pages are overused (regardless what programming language is used, which isn't the issue).
Opaque single page apps are also bad for URL. Also I often use curl when I want to download a file (or in one case, to stream audio), so do not want to have to deal with the web browser to do that.
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
Fast, safe, and portable semantics:
* Fast: executes with near native code performance, taking advantage of capabilities common to all contemporary hardware.
* Safe: code is validated and executes in a memory-safe [2], sandboxed environment preventing data corruption or security breaches.
* Well-defined: fully and precisely defines valid programs and their behavior in a way that is easy to reason about informally and formally.
* Hardware-independent: can be compiled on all modern architectures, desktop or mobile devices and embedded systems alike.
* Language-independent: does not privilege any particular language, programming model, or object model.
* Platform-independent: can be embedded in browsers, run as a stand-alone VM, or integrated in other environments.
* Open: programs can interoperate with their environment in a simple and universal manner.
Efficient and portable representation:
* Compact: has a binary format that is fast to transmit by being smaller than typical text or native code formats.
* Modular: programs can be split up in smaller parts that can be transmitted, cached, and consumed separately.
* Efficient: can be decoded, validated, and compiled in a fast single pass, equally with either just-in-time (JIT) or ahead-of-time (AOT) compilation.
* Streamable: allows decoding, validation, and compilation to begin as soon as possible, before all data has been seen.
* Parallelizable: allows decoding, validation, and compilation to be split into many independent parallel tasks.
* Portable: makes no architectural assumptions that are not broadly supported across modern hardware.
If webassembly is truly able to meet this goals, together with good debugging and tools, it will become the the universal way to represent computation across devices and platforms.
Really cool.
About 5 years ago I tried to use an optimized javascript file to encode some audio in browser before uploading, it was painfully slow and very hardware intensive. But using wasm in the vmsg [1], it distributes the LAME encoder allowing for in-browser MP3 encoding.
And secondly cloudflare allows for their workers to be written in WASM, allowing for more processor intensive apps (like resizing an image) to be completely on the edge.
I see it as eventually fulfilling the portability goals that java applets in the browsers use to have, but instead of one you have many companies agreeing on the implementation.
[1] https://github.com/Kagami/vmsg
[2] https://blog.cloudflare.com/webassembly-on-cloudflare-worker...
For image uploading, resizing is best done in the browser, so you are not sending large files over a limited mobile connection. The code is ugly (it also needs to fix image rotation by reading EXIF information because browsers are broken, and if supporting IE11 then there is some other voodoo).
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 web applications.... and while I read about WebAssembly I wonder about state management and someone tells me "oh you still need to something to do that" and I'm a bit lost on ... how that would work / why I would or wouldn't use one of those frameworks anyway, etc. So many examples I've seen are one off simplified (and for good reason I like those for demos) widgets but ... I'm not sure I've seen them as an application / understand how that would work.
Obviously I'm missing a lot here and feel like on HN I'm often talking to folks who aren't so much front end web devs who are excited about the efficiencies and such but ... not sure how this plays out in a practical sense / relative to the state of web applications as they are now.
https://hacks.mozilla.org/2017/02/a-cartoon-intro-to-webasse...
>> Wait, so what is WebAssembly?
>> WebAssembly is a way of taking code written in programming languages other than JavaScript and running that code in the browser. So when people say that WebAssembly is fast, what they are comparing it to is JavaScript.
A better definition:
> WASM is a binary instruction format for a stack-based virtual machine[1]
This goes into some details that could answer the question raised in this thread:
> WebAssembly modules will be able to call into and out of the JavaScript context and access browser functionality through the same Web APIs accessible from JavaScript.
More useful details:
>> Engineers from the four major browser vendors have risen to the challenge and collaboratively designed a portable low-level bytecode called WebAssembly. It offers compact representation, efficient validation and compilation, and safe low to no-overhead execution. Rather than committing to a specific programming model, WebAssembly is an abstraction over modern hardware, making it language-, hardware-, and platform-independent, with use cases beyond just the Web. WebAssembly has been designed with a formal semantics from the start. [2]
More details from Wikipedia:
>> Wasm does not replace JavaScript; in order to use Wasm in browsers, users may use Emscripten SDK to compile C++ (or any other LLVM-supported language such as D or Rust) source code into a binary file which runs in the same sandbox as regular JavaScript code. ... There is no direct Document Object Model (DOM) access; however, it is possible to create proxy functions for this. [3]
I hope this helps.
WebAssembly In Action (2017) https://www.youtube.com/watch?v=DKHuEkmsx3M
https://codelabs.developers.google.com/codelabs/web-assembly...
So far, most of the good demos of it seem to be for gaming. But I think once b2b type companies figure out what it's capable of, a lot will change.
> not sure how this plays out in a practical sense / relative to the state of web applications as they are now.
How I see it it either there will be one big framework (or language) that will have all the things and compiles to WebAssembly or there will be JavaScript libraries that ship compiled WebAssembly which you can interface with.
We are still a long way from having a React like framework which compiles to WebAssembly let alone a thriving community for it.
WASM requires a lot more knowhow to reverse engineer; I've had to do it a few times for CTFs and some blockchain-related tools that use them, and it's a lot trickier compared to JS.
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.
Sounds very "open" to me.
wasm-bindgen docs have some examples to get you started.
From my (biased) perspective, one of the greatest potentials is for new languages with improved features, syntax, and semantics. These languages can be just as effective as javascript performance-wise to accomplish the same goals, without having to transpile to javascript, which comes with its own real costs. The interest is there, given the 100+ languages that came out as a 'replacement' for JavaScript since its inception. We'll see if language theory can usher in a better language for the web built on WebAssembly.
The other great boon is simply having more performant services or utilities that can be written in any language. If you like C syntax for doing everything non-ui then you can go ahead and write C no problem, and run it on the client's machine. Maybe we'll even get to run fully concurrent client side apps, at which point Java would be a wonderful language to jump into those capabilities, given they have a robust handle on it from a language standpoint.
Wasm proper isn't really a technology for noobs. This is like asking "Does anyone have an introduction to x86_64 machine code, the ELF linker spec and the SysV ABI for noobs?". It's sort of the wrong part of the problem. What you want in that case is "C programming on linux for noobs".
So try googling for "emscripten tutorial" or (if you swing closer to rust) "wasm-bindgen tutorial". There are lots of other languages with wasm targets too, but quality tends to vary a lot.
But really IMHO the reason to use wasm isn't performance. Javascript interpreters are REALLY good these days for routine code. You use wasm when you need to target a big codebase in some other language to a browser, either because it's already written or because the problem area for the code isn't well suited to JS.
Less so an entire overhaul of web applications as it is a powerful tool to be deployed for things we don't do in the browser now because there is no way to / it would be a bear to do in JavaScript due to ... JavaScript being JavaScript ;)
Of course the amount of WASM to traditional JS or anything else could vary from application to application.
Granted we're predicting the future here so obviously it could be off.
This is all still traditional web development. It's just a way to target other runtimes to a sandbox in the same environment.
Incorrect. WASM was designed from the beginning to be run both on and off the web[0], and native clients already exist[1].
[0]https://webassembly.org/docs/non-web/
[1]https://github.com/mbasso/awesome-wasm#non-web-embeddings
Albert Einstein
But in practice, WASM files will be exported from one tool automatically, and imported into another tool automatically. It is similar to SVG or PDF. You know what to do with it, but you don't care what is inside (what each character inside means).
It's the closing keynote talk at this year's PyCon India. From the description:
> In this talk, I live-code a simple stack machine and turn it into an interpreter capable of running WebAssembly. I then use that to play a game written in Rust.
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.
If all websites made their source available as well as distributing the binary, there wouldn't be a problem.
More importantly, however, anything GPL must make source available and reasonably accessible. There is no such guarantee or even expectation for random programs on the web.
As for debugging, this is not a particularly hard or fundamental problem. It’s basically solved already.
https://developers.google.com/web/updates/2019/12/webassembl...
That's not the problem source maps are meant to solve. They exist to debug transpiled code.
> The source for GNU and Linux is viewable by everyone, which negates the inability to view what is happening inside a binary.
That's not true. It is non-trivial to verify that the binary you received was built with the source code that's openly available. The point of FOSS is that you always have the option to build your own binaries so that you can be 100% certain of what is running on your machine. Most people aren't going to do that, so they need to place their trust on a third party (like whoever built their kernel). FOSS just makes that trust optional instead of mandatory (like it is with something like Windows)
It stopped working as enforcement ages ago, though, so ️.
(Disclaimer: I've never looked at Google's analytics .js files and that may not be possible for some technical reason unknown to me)
The main challenge is that variable and function names are not available, but minified js is no better in that regard.
You don’t need javascript for this. People reverse engineer native binaries all the time. Reversing wasm isn’t much more difficult than minified javascript as my sibling commenter states.
This to me makes the browser vastly preferable to native apps. I didn't realize that the desktop app I use to easily translate languages[0] sends every keystroke to Google Analytics until I had to bother installing a proxy. Meanwhile this analysis is just an Opn-Cmd-I away in the browser.
[0]: https://apps.apple.com/us/app/translate-tab/id458887729
The good parts of the web in terms of debugging is the separation of concerns -- having separate interfaces for CSS, HTML, network requests, and the DOM, and having each of those interfaces be relatively inspectable.
I am a little worried about frameworks that target WASM spitting everything onto a Canvas, bypassing HTML and CSS (coughQt*cought). That would be a substantial loss for the Open web. But I don't lose any sleep over the idea of replacing Javascript.
Cross-compilation has been a thing for a while now -- WASM is the followup to ASM.js, which was already being used as a compile target for languages like C.
Now, reverse engineering ASM.js is easier than reverse engineering WASM (although ASM.js is still a giant pain). And reverse engineering minified Javascript is even easier -- most competent JS engineers could debug a React project without source maps, even if it took them longer.
But it's not clear to me that WASM makes the process meaningfully harder. As in, you're still going to want to use source maps like you use today, and it'll still be totally possible to figure out what a program is doing without the original source. It'll just be a pain.
And the benefits to the web as an open, language-agnostic platform that can be used for memory-intensive tasks outweigh the downsides of needing to work harder to reverse engineer software.
Going to need some clarification on how that's the case.
https://medium.com/@pnfsoftware/reverse-engineering-webassem...
That said, I don't know of any webassembly decompilers, although I guess they must exist by this point. But also historically decompilers have been imperfect as some of the structure of the code is lost in the compilation process and has to be inferred, sometimes incorrectly, by the decompiler. Compare to a minifier where all you lose is the variable names, comments, and possibly helpful whitespace. All of the structure of the code is still there and there are no heuristics necessary to recreate something that resembles the original source.
https://github.com/jashkenas/coffeescript/wiki/List-of-langu...
Wasm was effectively an extension of asm.js. It makes the experience of compile-to-web better, but it isn't much more opaque than other projects.
I haven't written any productive WebAssembly but I play Capture The Flag competitions, and it's become frequent for a wasm reverse engineering challenge to be thrown in. The tools are good enough to make that tractable, even for non-experts in wasm like me.
It helps a little that it's a stack-based rather than register-based VM. Usually more of the intent of code is preserved that way. It's like reversing a JVM class, rather than like reversing a native binary.
ex:
end $label121
get_local $var7
get_local $var9
call $func3444
get_local $var7
call $func1500 func1500(func3444(var7, var9), var7)
gw(kl(s,i),s)One practical factor: I often debug wasm files by compiling them to JS first.
At least wasm has structured control flow, which helps a lot. I wish wasm had even more readability features, personally.
I see nothing that states that is the case.
You real sentence should be "RISC-V instruction set is open, therefor I can see whatever a binaries is doing via the instruction it is executing." Doesn't mean its free, doesn't mean its easy to reverse engineer whatever the binary is doing, but you have everything to do it.
No, we can't, it's a valid criticism, it's not going to go away. Minified JS is bad, webassmbly is worse.
We can debate about minified JS if you so desire but its a different debate.
You can convert the binary files to/from the text (lisp like) format with readily available tools.
Also, the binary format is easily parsed -- made a parser with katai(sp?) struct in like an afternoon.
That's not true. There's nothing "free and open" about the tracking code embedded in every modern site, or the javascript blobs you get when you visit Google or Facebook. Minified/obfuscated Javascript is no different from a binary blob, except that it's much less efficient. Your chances of reverse-engineering one of those is about the same as reverse-engineering a wasm blob. Just because one is technically "human-readable" plaintext and the other binary doesn't make a difference, since you can't actually read either of them.
I don't know much about web assembly, but x86, which is much more complicated with thousands of instructions, has been successfully reverse engineered basically since forever. There are decompilers that can automatically reconstruct source code in C or C++ from a binary blob.
Compared to javascript, the best you can hope for is to just format the code so its in a more readable structure, but that isn't going to untangle purposefully obfuscated logic. Add to that the fact that even a regular javascript program is an untyped mess, and it becomes clear that anyone specifically trying to confuse readers will have a very easy time of doing so. There are a lot of messy things you can do in javascript, almost COBOL levels of messy.
Also, I'm curious about this
> but as someone who ran a small business in high school that usually involved reverse engineering obfuscated Javascript,
What type of clients paid you to reverse engineer obfuscated javascript? Malware research? Something else?
At the very least with obfuscated javascript you are going from js => js => js. Rather then from js => WASM => C++.
That's a bit of an overstatement.
Disassembly of native executables is essentially a solved problem, and has been for decades. There is some variation in terms of how you define disassembly and how you deal with code that specifically tries to defeat disassembly, but it's solved enough that objdump -d is a decently effective tool.
Decompilation is more difficult. There were academic-quality decompilers by around the 90s, but these weren't really usable and tended to break on anything more complicated than toy examples. The JVM breathed new life into decompilers, and it's not until this point that you get decompilers that can routinely output code that is recompilable (and only in the Java domain).
In the mid-noughts, decompilation efforts returned to targeting native binaries again. This is helped by the developers of IDA Pro (the main tool used for reverse engineering) building a decompiler view into their application. There's also been more efforts on accurate static binary translation into IRs such as LLVM, which is often close enough to C to be effective, and I'm more familiar with these efforts than I am with full decompilers.
The creation of fully recompilable C source code from binaries is still a challenge, in part because machine semantics are more well-defined than C, and you basically have a tradeoff between readable output and semantically-correct (free of undefined behavior). Control-flow recovery is still challenging; signatures are needed to deal with statically-linked pieces of the standard library; and structure and type recovery is routinely of extremely poor quality.
Just wait 5 more years that 80% of the web switch to React / Vue / TheNewHypeSPAFramework and with or without WASM, you will be unable to browse "js off".
The blame here is not on WASM but on the abuse of client side rendering and "everything as an App" when most page are just barely interactive documents.
The Web succeeded where Flash / ActiveX / JavaApplet / Sliverlight failed because:
- it was open
- it was document oriented.
And that we tend to forget a bit too easily about it.
If you really think this is true, look into Google's recaptcha blob.
"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 in my total control, it would probably not have taken off. You can’t propose that something be a universal space and at the same time keep control of it.”
So, Tim and others advocated to ensure that CERN would agree to make the underlying code available on a royalty-free basis, forever."
Can you see how rude it is to not do the same ?
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.
Just because you _can_ use the compliation step to (go some way to) hide your source doesn't mean you _have_ to. And relying on your secret sauce being private while you publish it in obfuscated form for all the world to decypher feels like a losing strategy.
I don't think there's any particular reason that WASM has to be more obfuscated than JS. You can already throw a WASM file into a bytecode-to-text translator which is about as useful as deobfuscating a minified JS file, and I assume decompiling/debugging tools will only get better in the future.
For a long time now, I've been thinking of a future where your OS properly isolates all the programs that run on it and even gives us the ability to have direct control over how programs interact with the rest of the system. OS's seem too mired in backwards-compatibility requirements to make big changes like that any time soon, but that's basically the way our browsers already work. Download some code, and execute it (relatively) safely because it's sandboxed from the rest of the system. Our browsers are basically the new OS, and this time around we can do it right using what we learned from OS's (and hopefully backport these browser features into the next generation of OS's).
For example, an app asks for a filesystem handle. You can hand it one that refers to a real location on your OS fs, or you can hand it a completely virtual fs that won't affect anything else on the system.
Whenever an app asks for a resource, being able to hand it a virtual or sandboxed one instead is a huge gain for user-control.
Minified Facebook or Google trackers were never libre or meant to be easily reversed. Web apps like Google Drive aren't free either just because you can run it in a browser on Linux. You aren't supposed to (legally?) be able to modify it and nor would you be able to in many cases where they try. It's just as proprietary as Microsoft Office. There are proprietary tools to do even more advanced obfuscation on top of minification (adds red herring code paths that do nothing), which some JavaScript malware vendors use to protect their implementations.
What we really want is libre JavaScript/WASM where vendors include permissive licenses and source maps or links to download the high level source. That's free software. The "free and open" web never really existed de jure; publishers' laziness to obfuscate created a de facto free and open web. Libreness depends on access to high level source, not reverseability, or else Photoshop is free too because you can attach a debugger to it.
WASM just exposes the truth that the web was an app store all along.
React for example shifting towards functional programming makes FE apps simpler and predictable.
If you dislike the HTML/CSS UI layer then WA is indeed an alternative. However you need to reimplement everything, like text selection, right click, focus, accessibility, dropdowns, etc, because all you have is a <canvas> to draw on.
But! WA will eventually have DOM access, that will definitely open up the landscape to create new frontend frameworks.
The two largest are Yew (Rust), Vugu (Vue-esque but with Go instead of JS), and Blazor (C#)
https://github.com/yewstack/yew
https://github.com/aspnet/Blazor
All are perfectly viable for production apps as of today and not much more difficult than writing React, given you have some familiarity with their implementation language.
Technical question: 1.) What is the speed of WebAssembly on iOS WebKit and Android WebView? 2.) Is it feasible to write an entire app UI in something like Qt and target WebAssembly? 3.) Android, iOS, Windows versions of the app are Qt apps natively or possibly through the device's WebKit.
Is this possible today? Is there a better UI library than Qt for this?
I can get lit-element with no build process going to prototype something in a single .html file in probably 30 seconds. I don't think XCode/iOS developers can compete with the simplicity. Define initial state, alter it through events, pull data through fetch(), write HTML. I know for a fact iOS development isn't that simple.
EDIT: Here's an article from yesterday about this: https://developers.google.com/web/updates/2019/12/webassembl...
The "arrival" of WebAsm to w3c only means that w3c had finally woken up from eternal slumber and realized that everyone has already implemented The listed features.
As if that's not already happening today with obfuscated and minified javascript
What's the distinction then? That obfuscated javascript can be looked at by people who don't know how to use a hex editor?
JS can do better, and it will if other languages can do things it does now.
I guess in a sense you already have the JS engine installed with, say, Chrome, which is essentially a runtime.
Why can't other runtimes come prepackaged? What am I missing here?
Getting the JS engine to be fast was a tremendous trouble and you wouldn't want to sink as much engineering power into another runtime that will have a smaller reach than the JS engine.
Rather use that skills to make WASM faster.
Why would it need to be? There's no reason to assume the architectural decisions for javascript have to be repeated for WASM.
The runtimes themselves could be WASM binaries cached like any other resource, or managed like packages. Javascript could be disentangled from the browser by doing the same - just treating it as a resource that ships by default with the browser.
I don't know if that's feasible - maybe not - but I bet there are possibilities other than "ship the entire runtime with each script" that can be considered.
That's likely still not a good idea. A specific runtime is likely to be outdated fast. That's like asking why the JQuery library wasn't shipped with the browsers themselves.
For runtime with a significant size, it's probably going the same way as JQuery. Have a CDN host it so different websites can use it and leverage the browser's cache.
Also, the use cases for javascript and webassembly don't overlap enough for one to replace the other in most cases. Javascript is a text-based scripting language you can write in any editor (the sprawling morass that is the current js development ecosystem notwithstanding,) but WASM requires knowing another language and having a compile step, which adds friction and complexity. You can't really replace a language with a bytecode.
It may mean that other languages can be deployed in the browser as easily as javascript, which may or may not be good depending on your point of view.
I personally look forward to the day when Hacker News embeds the Arc runtime as WASM and replaces all of their javascript with Arc code.
That's exactly what I hope happens. There are so many good languages out there that having to be stuck with javascript for the modern web is a crime.
> WASM requires knowing another language and having a compile step, which adds friction and complexity. You can't really replace a language with a bytecode.
I'm not sure that requiring a build step is a real problem, for web 'applications' at least. Plenty of JavaScript frameworks use a build step anyway.
For example, if Adobe delivers its new mobile Photoshop directly via iPad Safari will Apple have a way of 'nerfing' WebAssembly to stop them?
Companies will ask their developers to deliver WASM resources in the name of performance. As a notable side-effect, it will become harder to review how websites work.
Yes, I'm sure there will be reverse-compilation tools for WASM, but still.
And minified JS isn't particularly more reviewable I think
It is possible to disable half of the paywalls on the web just by looking at the JS code. I can see why certain parties would push really hard to introduce Webassembly. The performance argument is just a pretext because today's jit compilers for Javascript are really good.
Shhh! Don't tell them!
In practice, there's nothing that WebAssembly offers that could hinder analysis even further. If websites want to be transparent they could provide the sources (akin to providing unminified/unobfuscated JavaScript).
webassembly is encouraging websites to dump megabytes of binary code in browsers.
Obfuscated, analysis-resistant code to ensure that people cannot disable ads and tracking.
It's appalling that we are accepting this.
For example, it doesn't support arbitrary computed goto:s. Instead it supports block-based control flow, where the semantics can either create blocks or jump out of them to lower down blocks. This makes it possible to construct a CFG statically, which isn't possible if it did support arbitrary computed goto:s.
Please
Pretty much all relevant browsers support wasm (and I suspect data for the few non-compliant Chinese browsers may be outdated, they’re definitely not last released in 2016 or 2017). Do you have some other idea of wasm-capable?
* Sandbox. WASM is a sandbox. Think of WASM as a language agnostic replacement for Flash. It is an island in a webpage isolated from that page. This is great for security so that the opaque binary running in that WASM island cannot modify the page in such ways as to violate the same origin policy, such as turning a button into a hyperlink with a user's personal details attached as query parameters on a malicious third party URL. It also means code executing in WASM cannot interact with the surrounding page, which means it isn't a JavaScript replacement. The developers of the WASM standard have been very clear that WASM will not ever be a JavaScript replacement.
To be fair there is work being done, several years in the making, to provide web-like technologies to WASM instances, such as a DOM. This enhancement eases some concerns of overhead, see the next bullet point, but they won't break security or escape the sandbox. This enhancement might go so far as allowing the containing page interaction with the WASM instance, but I suspect this would be limited, if at all, and only cross the sandbox barrier in one direction. There is huge interest in WASM and page interaction, but this is all coming from developers who want alternatives to JavaScript. There is no prevailing business interest in advanced WASM interaction.
* Overhead. Since WASM is a self-contained sandbox the incoming binary needs everything an application binary would otherwise need to execute as an application. For example if a WASM instance wants to pretend to be web page instance then it has to include its own DOM library, interaction code, presentation, and absolutely everything else. If accessibility is a concern you would likely have to reinvent how that works in your WASM instance. While this is of great interest for developers who hate JavaScript there isn't a lot of business value in that.
* Performance. So far WASM has not been able to significantly outperform JavaScript. In many cases WASM code performs slower than JavaScript. Without a large performance differentiation there is little business justification to invest in WASM. Flash's claim to fame is that for most of Flash's life it did significantly outperform JavaScript by an order of magnitude. JavaScript never got faster than Flash, but it did almost completely close the performance gap. Once JavaScript got fast Flash started dying.
---
There is potential business value in WASM, but you have to be willing to abandon any consideration that you are executing in a web page. Selling the idea to business owners that you are executing in a web page, but you need to imagine that you aren't is a tough sell. Here are some ideas that might work better in WASM than the typical web environment:
* Document interaction with digital signatures from physical tokens.
* Streaming media players with embedded DRM.
* Certificate negotiation for an end-to-end encrypted messaging tunnel transmitted via web page.
It can do so via JavaScript glue for now, but there was spec proposals to allow direct access to the DOM.
https://github.com/WebAssembly/binaryen/blob/master/src/tool...
There are more features coming to WebAssembly in the browser, including hopefully a way to feature detect in the WebAssembly binary instead of the way it's done now, which is to compile as many binaries as you need for combinations of features, feature test in JS, and then pick which wasm module to load.
I bet in few years we will run wasm natively on processor.
In contrast, WebAssembly would be a terrible project to implement directly in logic; there are no relative offsets so incrementing an instruct pointer register simply doesn't work, which hardware is very good at. fn calls are referred to by name indexed into a table at the bytecode level, so you're inherently dealing with a level of indirection that would require 'flattening' or inlining the table values to work around before being executed, or, alternatively, you'd have to just bite the bullet and put limits on their size, and eat the cost of the indirection. Similarly, CFG blocks in WASM are represented as literal scoped blocks with nested instructions at the syntax level -- not simple jumps/calls. You need to extract the back/forward edges from the CFG to recover that information and translate it to direct jump operations.
At this point, you are just implementing a compiler, and if you choose to do it in hardware, you are willingly trying to shoot yourself in the foot (or the face), and it will end badly. You're far better off calling a spade a spade and compiling, in software, to a representation that actually can be implemented efficiently in hardware. But you could of course hide this compiler in the firmware to make it "seem" like WebAssembly is the native ISA, and the small surface area of the specification can help ensure you do it safely and correctly. This is probably for the best anyway, because it's dramatically harder to design correct hardware vs correct software.
It looks like Gary Bernhardt was pretty spot on in his talk "The Birth and Death of JavaScript": (https://www.destroyallsoftware.com/talks/the-birth-and-death...)
Instruction caches (and JITs to a degree) solve the same problem in much more general ways. That's why Azul went out of their way to create an appliance to run Java code with custom CPUs, and ended up with a pretty standard RISC for the most part.
All of that applies to WASM machines too.
The processes would have to translate the wasm into some form of register-based operations anyway, and a JIT compiler might be able to do this more efficiently since it can see a bigger picture than the processor.
Wasm is in this interesting spot where it's relatively low-level, but high-level enough to allow proper sandboxing. It strikes me that the arrangements to accommodate that, like call indirection via tables, could be optimized on CPU level. Not necessarily in a sense of a CPU that directly runs wasm, but rather a CPU architecture which is optimized to be a target for JIT or AOT compilers from wasm.