WebAssembly support now shipping in all major browsers(blog.mozilla.org) |
WebAssembly support now shipping in all major browsers(blog.mozilla.org) |
> Seriously JS should not be the lingua franca of the web
What would you recommend for a replacement? When I typically see this it is from people can't figure out JavaScript as opposed to any rational technological reasoning. I cringe at the idea that people would offer forth really bad things that don't fit well merely to satisfy their own insecurities.
If you look at all the large Javascript frameworks, the increase in hardcore software engineering approaches taken to the front-end are an interesting signal. We have MVC in the front-end, we have MVC in the backend. Why have two MVCs if you can write an isomorphic application and have one?
I'm thinking, for example, something like this... write C#, use a framework (fictional "Isomorph#") that can determine whether code should run on the client or server, and if you have interfaces to UI, you have the full solution. C# (client/server) + WASM/JS + remoting/web services + HTML/CSS/SVG/etc UI = real "apps".
And that could just as easily have been Python (client/server) + WASM/JS and the rest of the stack, or Go + WASM/JS.. etc. etc. I was shocked when I learned of Skulpt.org, which is a python interpreter running in the browser - so we can't be far off from the same thing running on WebAssembly.
The world goes around in circles.
The "wasm is just the JVM all over again" meme needs to die.
Yes, it's just about time for another generation to be old enough to think that we need to rewrite everything in a new language.
I'm not thrilled with that because I really like the old-school lightly-styled-HTML web, but I have to admit it's really really bad at "app" style layouts and interactivity, so if we must do that with the web (and apparently we must) it's gotta go, or it's gonna continue to suck.
But neither should this. Really, keep your code off my computer as much as possible.
I can't imagine there are many people in this world who have a computer with more than even 1% their own code running on it.
If you're not one of these guys that refuse to execute any binary code that you have not compiled yourself, you should welcome the possibility of running binary code from a sandboxed web environment.
I, for one, wish I could run all my proprietary software on the web, and restrict all my native applications to FOSS. That's a prospect WASM enables.
See this issue, for example: https://github.com/rust-webplatform/rust-webplatform/issues/...
People don't learn. The web dev community have just managed to force browsermakers to unify web development on browser side JS, and throw Java applets, activex, and action script to the bucket, just to have a kind of JVM being made a part of the web standard, and forced upon us yet again.
The core problem with Java applets was that they were Java applets
An option to keep the source of the web app closed will fragment the web dev community yet again.
Do you? The comparison with Java has been made before, including on HN.
"While Java and Flash [2] came early to the Web and offered managed runtime plugins, neither supported highperformance low-level code, and today usage is declining due to security and performance issues. We discuss the differences between the JVM and WebAssembly in Section 8. "
https://github.com/WebAssembly/spec/blob/master/papers/pldi2...
That is not necessarily a language oriented concept. JavaScript can run on the front-end and back-end having an MVC architecture at both points. A better question is why a developer should wish to impose MVC at all at either point?
These concepts become easier to reason about when the software runs at a single location using an HTTP service (on localhost) to talk amongst its clusters. It is just a multiprocess application with the bits running asynchronously from each other.
When one (or more) ends of the environment are distant factors change drastically. First, you don't control the remote environment. You are completely at the mercy of what the user is willing to execute and they may modify your application in ways you do not anticipate. Secondly, there is a delay between distant ends.
Regardless of the application or language in question the environmental and security considerations at hand will continue to impose a separated JavaScript-like web application.
Flexbox and grid help a lot with app-style layout.
I should clarify what I meant. I was thinking more the way Cordova works where the JS side handles the DOM but the wasm side handles computations and they talk to each other via a "bridge". So maybe React can offload its heavier computations (diff-ing and what not) to a C lib compiled to wasm and it just returns data back to it.
On x86, the only real "sandbox" you have is what your MMU gives you. For as long as executable has access to browser's address space, it can do anything a browser can, including reading your webcam, mic, sensors, GPS, etc
Thank you. We have a winner here! And the people trying to escape them will have the full capability of native code running on your CPU.
In the mean time, permissions will be granted for ever increasing parts of the system. Users will not be prompted to "allow" for every site they visit because that will be tedious so browsers will start the enable permissions by default. But either way, we now have the browser acting as the keeper of permissions that our OSes are not able to enforce at the granularity we need for such things.
We've been continually migrating the browser to the role of an OS. It's just insane.
And GPU too,
I recently saw that I do get frequent crashes on certain pages, it appears that somebody is putting empty ads that do SHAsum in the background with WebGL using vec4 and shaders!
I'm on a 5Gb data plan for mobile and even on the excellent 4G networks we have here sites are still too slow and unresponsive.
I don't really see what's dark about it.
It's now a default install on every browser of every computer I touch. Even on Firefox on Android, which works really well btw.
With all the bundlers and minifiers manglers etc, delivered js is already as closed as a wasm binary would be.
But this changes nothing. It was always possible to obfuscate JavaScript, just like every other programming language.
To be a strong candidate for a web scripting language you need three things:
* native lexical scope. This is how all web technologies work.
* Minimal reliance on white space as syntax. The language needs to be portable. Overloading white space as syntax makes a language more brittle, particularly in distribution.
* Immediate interpretation without a prior static compile step. This keeps the code open to examination and minimizes compile time delays.
Find another language that doesn't have all the stupid crap that JavaScript has and yet still excels in those three points and I will agree upon a replacement.
How about Lua?
That describes just about every programming language ever.
Hacker News and at least every Wordpress site. So that covers a significant portion of the existing web.
The language specification requires the use of semicolons. If a semicolon is not supplied the interpreter will insert it for you. That magical insertion step is referred to as ASI. I don't remember if ASI is mentioned in the spec (as I don't think it is), but at the very least it is a de facto standard as missing ASI breaks the web.
As stupid as all that sounds... semicolons are actually required to terminate statements in JavaScript.
"A red herring is something that misleads or distracts from a relevant or important issue. It may be either a logical fallacy or a literary device that leads readers or audiences towards a false conclusion."
I don't see how my comment is a red herring. Computers are for running code. That's what they do. You said you don't want other people's code running on your computer. Bad news for you, that's all your computer does.
This may not be what OP meant.. but it's something I can agree with to a degree. I love web apps, don't get me wrong, but I wish we had meaningful fallbacks for those who want content without features.
Both computers and cars exist to perform tasks that enable humans to do other things. It's possible to have a useful car that does not consume fuel and it's possible to have a useful computer that runs no code (hint: hardware's not just for mounting those pretty lights in your computer case).
While there is issue with how ill informed the general public is in general on how web browsers / http / html operate in the first place, there is no disinformation campaign here - users don't think the browser does or doesn't run code because they don't understand how any of the system they are interacting with operates at all. The average extent of knowledge when it comes to computers is that the Chrome has the Facebook and you need the Wifi logo lit up for it to work, and even that last one is often way beyond the knowledge scope of your average Internet user.
Not really, explicit installation are not the real difference: you ask for one package in some package manager and you will commonly implicitly get a bunch of other dependencies installed, you will likely never be able to feasibly personally audit all those implicitly installed packages if we are talking about e.g OS repositories...
The real differences are:
1. Trust of the authority that maintains a collection of repositories.
2. Execution permissions.
i.e The package manager for your OS can install code that can run with root privileges if it wants, but you have trust in the authority that maintains the package lists. With the web there isn't any curation of package lists, but the code is sandboxed.
The last time a web page caused my browser to download and run js that the page owner didn't know about was five minutes ago.
The goal is to deliver content and experiences that people actually want, it has nothing to do with the amount of code at all.
At best, using less code might be a performance optimisation (though not always).
Wrong. 99% of the time the goal is to sell ads. The tricky stuff is to bundle it with something that people actually want (or think they want).
WebAssembly looks like a safe, portable, intermediate bytecode. What's wrong with giving people more options (e.g. running native applications in their browsers)?
You walked yourself into an obvious answer there: yes, to a limited extent you do. That includes understanding a bare minimum about tires, the engine (what noises are normal, what noises aren't normal), oil changing (why, when), windshield washer fluid, basic indications of electric problems, basics about the need to change brakes (indications of brakes going bad, why they need changed), the basics of the parking brake (and not to drive with it engaged and why), the usefulness of different types of tires (for example snow tires), why you shouldn't needlessly over-rev an engine frequently (or do stupid things like over-rev it for an hour while parked), how turn signals work and the need to make sure the lights on your vehicle are functioning, how high beams work (or at least how to use them), how gear shifting works and why it's important not to thrash your transmission (what abnormal shifting sounds like, why that matters), this list keeps going and I've really only covered primitive things that most or all drivers should know within the first year or so of driving.
When you visit a website, and you have given your browser permission to run JS, you're giving your permission to run JS. If you want to block scripts by default, use an extension like uMatrix:
My browser never asked me about JS. Even if it did, browser developers would switch the preference rather than annoy the user with a prompt every time a site wanted to run some JS. The end result is that whatever is common practice, the users will end up accepting by default. In such cases it is the responsibility of the people setting standards to keep the users safety in mind. The responses in this thread really make my point. So many making excuses for running excess code and even advocating more APIs.
Here is how JavaScript does this:
* https://www.ecma-international.org/ecma-262/#sec-source-text
* https://www.ecma-international.org/ecma-262/#sec-line-termin...
ASI is defined in the spec here: https://www.ecma-international.org/ecma-262/#sec-automatic-s...
Or the composition of the road below them in exact ratios of chemical components.
> The goal should be to try harder to use less code
Why is this the goal? At best it's a performance optimisation that some (probably most) sites could use to speed up time to render. But at the same time, there are many other sites where this doesn't make sense or for which the purpose isn't the traditional document based web that is sped up by removing JS. Why should sites that actually benefit from something like WebAssembly be limited just because other sites will use it and (continue to) be slow bug ridden monsters?
Ideally yes, but that horse left the barn years ago. The browser becomes more capable, chalk full of more APIs over time, not less.
This is probably the best bit of programming humor I've read all morning.
Have they personally audited every dependency? Probably not. Is the list of dependencies known? Yes. Is the list fixed? Yes.
On the webpage side:
Does the content provider know what will be served by their ad network? No. Does the ad network provided content change? Yes, constantly. Does the content provider even know who ultimately will be putting crap on their web page via the ads? No.
Whoa! hold on a sec.. code inside a browser != Ad network, when people insert ads into programs outside of web browsers you will have the same issue, only potentially worse because you wont know if they properly sand-boxed them.
You want Gimp for Windows running in Firefox for Linux running in Chrome for Mac? Yeah sure.
[0] https://www.destroyallsoftware.com/talks/the-birth-and-death...
Too bad makers of the original Minesweeper did not think to build touch input support.
I actually do. I want all code ever written and every environment it was ever written for to have a URL that will let me run it in the browser. Everyone else seems to want the web to go back to being whitepapers but I want actual cyberspace already!
We haven't had a new browser engine written from scratch since KHTML. Firefox is a descendant of Netscape, Chrome (and Safari) is a descendant of WebKit which is itself a descendant of KHTML, Edge is closed source, but I'm almost sure there's some old IE code in there.
Why?
It's simply too expensive to create a fast (and compatible) JS engine.
If WebAssembly takes off, I hope that one we'll have more than three browser engines around.
Check out the size of the latest edition of the book "CSS: The Definitive Guide":
https://twitter.com/meyerweb/status/929097712754098181
Until CSS is replaced by a sane layout system, there's not going to be another web browser engine created by an independent party.
At least some of the JS engines are used in non-browser projects (V8 and Microsofts), which at least superficially would suggest you could write a new browser engine and tie it to one of those existing JS interpreters. WebAssembly will gain interfaces to the DOM as well, so the complexity of that interaction will remain.
EdgeHTML is a fork of Trident, so yes. That said, I'm led to believe there's about as much commonality there as there is between KHTML and Blink: they've moved quite a long way away from where they were.
> It's simply too expensive to create a fast (and compatible) JS engine.
I don't think that's so clear cut: Carakan, albeit now years out of date, was ultimately done by a relatively small team (~6 people) in 18 months. Writing a new JS VM from scratch is doable, and I don't think that the bar has gone up that significantly in the past seven years.
It's the rest of the browser that's the hard part. We can point at Servo and say it's possible for a comparatively small team (v. other browser projects) to write most of this stuff (and break a lot of new ground doing so), but they still aren't there with feature-parity to major browsers.
That said, browsers have rewritten major components multiple times: Netscape/Mozilla most obviously with NGLayout; Blink having their layout rewrite underway, (confusingly, accidentally) called LayoutNG; IE having had major layout rewrites in multiple releases (IE8, IE9, the original Edge release, IIRC).
Notably, though, nobody's tried to rewrite their DOM implementation wholesale, partly because the pay off is much smaller and partly because there's a lot of fairly boring uninteresting code there.
In my opinion, the issue is the DOM. It's API is massive, there is decades of cruft and backwards compatibility to worry about, and it's codebase is significantly larger in all major open source browsers out there.
WebAssembly is a replacement for Flash, Silverlight, and Java Applets.
And while yes, Mozilla's Spidermonkey comes from the Netscape days, and Chakra in Edge descends from JScript in IE, plus aforementioned JavaScriptCore, each of those engines still evolved massively: most went from interpreted to LLVM-backed JITs over the years. I suspect that no more than interface bindings remain unchanged from their origins, if even. ;-)
(1) I can't currently find the primary sources from when Chrome released on my phone, but here's a contemporary secondary one: https://www.ft.com/content/03775904-177c-11de-8c9d-0000779fd...)
[1] Such as V8, Chakra, JavaScriptCore, SpiderMonkey, Rhino, Nashorn, there is a variety to choose from, also experimental models such as Tamarin, they are almost certainly not the critical blocker for developing a browser.
Netscape navigator on DOS in Firefox via WebAssembly.
I think it's a great idea, though many disagree. It's basically ChromeOS but to the next level.
We've been working on porting over our fairly large barcode scanner library to WebAssembly. While the performance is close to what we have on other platforms ( http://websdk.scandit.com ), the major bottleneck for now is not being able to use optimized code relying on SIMD (and not having an existing C fallback as all other platforms we target have SIMD support)
HN discussion: https://news.ycombinator.com/item?id=14495893
The awesome-wasm list is also a good start: https://github.com/mbasso/awesome-wasm
I'm not a collaborator on the WebAssembly Org, but I can still see that issue just fine.
I almost wish I was a student again so I could relearn math for the first time with all of these great tools...
The only benefit I can think of that benefits is specialized software like games or scientific analysis/simulation. But for what most users want, JavaScript is fast enough. The example I keep hearing is "imagine gimp in the browser" but it's already possible to make a gimp like application in the browser using things like canvas and the file api.
So by the time webassembly is ready for the prime and has needed features like memory management and Dom access, will it even by worth it beyond a few specific applications?
Does WebAssembly actually open up any new API hooks? I get that its a clever way of transpiling existing programs to JavasScript, but surely we could do that already?
Whats new avenues of development is WebAssembly expected to open up? Is the whole point just to enable an easy way to compile games made on other platforms (Unity) to the web?
Unfortunately, integrating a new runtime like <script type="text/lua" src="main.lua" module="lua.wasm"/> will probably never happen. A link tag, to me, specifies a static resource rather than executable code (although since CSS supports animations now that's probably a distinction without a difference.) <object> might be a good candidate but I don't know if it's still supported.
But, we can't get rid of JS altogether. Browsers will have to support javascript indefinitely, otherwise most of the web becomes unreadable. That being the case, using JS to load WebAssembly seems like the most reasonable backwards-compatible compromise available.
What? The original WebAssembly announcement[1], which can be viewed as the manifesto for how WASM was envisioned, it clearly says "once browsers support the WebAssembly syntax natively, JS and wasm can diverge". Eich's goal with WebAssembly is not replacing JS, it's providing a better compilation target for other languages. WebAssembly is a replacement for asm.js, not JavaScript. No one is selling a lie here.
[1]: https://brendaneich.com/2015/06/from-asm-js-to-webassembly/
For completely unrelated reasons, I was already thinking of adapting (my fork of) the LZ-string library[0] to directly compress/decompress typed arrays to "websafe" UTF16 strings, similar to the already existing `compressToUTF16` functionality in LZ-string. Essentially, the strings would represent LZ-compressed bitstreams, using 15 bits per string character.
Could this be useful for reducing the size of WASM binary when encoded in plain JavaScript? (the minified library would probably be around 1kb after gzip)
[0] https://github.com/JobLeonard/lz-string/tree/array-lookup
[1] http://pieroxy.net/blog/pages/lz-string/index.html#inline_me...
> an explicit Uint8Array should only only necessary if you want to inline the wasm directly with the JS that instantiates it.
Are there any realistic scenarios where this is the more sensible option?
Anyway, I should have searched MDN first, the relevant bit of documentation is pretty clear:
fetch('simple.wasm').then(response =>
response.arrayBuffer()
).then(bytes =>
WebAssembly.instantiate(bytes, importObject)
).then(results => {
results.instance.exports.exported_func();
});
You just compile, upload and share the URL. Like in the old days ;)
That's the plan. That "interfaces actual HTML" thing isn't available yet, but you can already hack around it.
For example imagine being able to run a full self hosted C++ compiler itself from a browser on any device with a browser.
https://webkit.org/blog/7956/new-webkit-features-in-safari-1...
https://developer.apple.com/library/content/releasenotes/Gen...
I recently discovered that while Safari supports WebRTC, a "WebView" or a safari view that is added to the home screen does not.
For C and C++, you have emscripten. For Rust, we have an emscripten-based toolchain that works today, but have a PR open for using LLVM's built-in wasm backend.
For emscripten: https://kripken.github.io/emscripten-site/docs/#
For Rust: https://hackernoon.com/compiling-rust-to-webassembly-guide-4... (slightly older but still should work afaik) And the new backend https://github.com/rust-lang/rust/pull/45905
As far as I am concerned, all the languages I care about already have compilers that target JS.
The idea of being to write in one language for embedded software, system software, cli tools, web applications, distributed applications, and now the web client?
That's a very enticing idea. It might finally be the realization of what Java failed to accomplish (technically it did, but never gained a lot of traction on the client b/c it was too slow at the time).
WASM is much lower level, and should allow compilers and VMs to use best-fitting data structures and layout.
Is Internet Explorer not a major browser anymore? I’m talking relevant as in your webpage needs to work fine in Internet Explorer.
For example, my company still has Internet Explorer configured as default browser as Edge is not compatible with some internal pages.
Look at your Google Analytics, it's really not that important anymore.
Chrome 56.69%
IE 12.69%
Firefox 11.14%
Safari 9.84%
Edge 7.86%
I anticipate that IE will never gain support for WebAssembly, and your company will eventually change its default.
Most development I see nowadays supports only IE11 and is about to drop that one too in favor of Edge. IE is on its way to deprecation right now.
But in the mean time, it's very helpful to encourage companies to base their browsers on standards, and move away from outdated software -- at least a s security precaution.
"GC support" means being able to integrate with JS's GC, basically, so that your language's wasm runtime could use it instead of your own, saving bytes.
Because webmasters will keep loading ready-made plugins from CDNs, exactly like they are doing now, except that the new generation of web software will carry their own interpreter or runtime with them, because the developer wanted to use Python or whatever.
The web is getting better by the day.
wow, this is really cool! thx for sharing :]
Is SIMD portable though? Will it run good on mobile devices? And what about other non-Intel architectures in general?
I'm excited for WebAssembly.
OTOH having SIMD would speed it up significantly and probably get them all up to speed.
And then there's the fact that WebGL is so much behind the state of the art that it's not even funny. Sticking to an old version of GL/GLSL severely limits what you can do with it.
But neither of those necessitate JavaScript; JS is just a language that happens to run in the browser and has DOM API bindings (and the other browser APIs too). There's no reason those identical bindings couldn't be provided in any other language.
I'm sure if you sampled all developers the number that would say Javascript is their favorite programming language would be in a substantial minority. So if it makes it easier for developers to write client side code in their preferred language its worth it.
That being said, I'm worried a bit. Javascript being awful has traditionally kept developers doing as much runtime work as possible server side. In the last 5 years the rapid growth of JS libraries, client side frameworks, and recently ES6 have all reduced the pain points and correlated to a dramatic rise in client side code being loaded on users computers with corresponding huge page size bloat.
I wouldn't be so sure of that.
https://insights.stackoverflow.com/survey/2017#technology-mo...
Exactly. Only javascript can access attributes and call functions so good on exported document and window objects.
WASM is an intermediate representation which is output by your compiler (of your favorite language) and consumed by the browser's compiler to emit native code.
WASM is a bit similar to LLVM IR, but it's architecture independent.
Compare this to, say, LLVM and Clang. Clang (the C compiler front end) will read C code and emit LLVM IR. LLVM (the compiler backend) will read LLVM IR and emit assembly code for your CPU. With WASM, the developer will run the "front end" and distribute the WASM code over HTTP and the web browser will run the backend and turn WASM into native assembly code.
> I get that its a clever way of transpiling existing programs to JavasScript, but surely we could do that already?
No, WASM code is not JavaScript at any point. ASM.js is a predecessor to WASM that was a compiler-friendly variant of JavaScript that can be compiled to native code.
This means that WebAssembly is actually broader than just the web; for example the Etherium folks have been discussing using wasm as their language to script their blockchain.
It doesn't currently open up any real new API hooks; it's mostly about being an efficient language for computation. You get near-native performance in the browser. In the future, it may or may not grow more hooks directly into the web platform, rather than needing to call into JS to do so.
WebAssembly and asm.js are both intended to be compile targets - you don't write them by hand, but instead write your code in another language (c, Rust, etc.) and then complie to them.
The main benefits are 1) JavaScript is no longer the only language of the web, and 2) it's possible to get better performance than JS ever allowed for.
There is a lot of c code out there that probably isn't worth rewriting fron scratch in JS, but may well be worth recompiling to run as a web app.
Also, in the future, WebAssembly should get DOM access, optional garbage collection and other features that will allow it to be a compile targets for other languages such as Python and Ruby. So then you can use a single language for all of your development without that language being JavaScript.
The really exciting thing people should be talking about is not WebAssembly but the general availability of SharedArrayBuffer[0] which finally makes it possible to run "foreign" multi-threaded code efficiently.
[0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
That certainly is a shame, but it's not like we have to accept that as the future. HTML is a document markup language, but we've hijacked it to build interactive UIs. It might be that WASM is just a native-ish FFI system for javascript today, but tomorrow it could be something completely different.
WASM can be great if they allow it to.
But DOM interop is needed. Can't wait to get my fingers on the DOM via native C code :)
[0]: https://github.com/WebAssembly/design/issues/1079
edit: Scratch all of that above. I stand corrected. Here's the DOM proposal: https://github.com/WebAssembly/host-bindings/
You could simply compile (relevant parts of) Firefox or Chromium to WASM :)
Web 4.0 pages are obfuscated WebAssembly payloads, that draw their contents via WebGL. This way, adblocking becomes impossible, as the actual content and ads are within the same opaque WebGL framebuffer. Stealing copyrighted text is also made significantly harder, beause the Web 4.0 platform leaves it up to the publisher to enable glyph selection and copying. You have concerns about accessibility? Web 4.0 is 100% accessible thanks WebAudio based realtime speech synthesis!
No, it'd just take a sufficiently smart AI.
I do agree that runtime-less languages have an advantage here though.
That said, it's not the technology's fault that people abuse or otherwise make poor use of it. I see no point in limiting it on that basis.
I felt like I should respond to this, too.
It's not, but it is not unreasonable to object to implementing new ways for browsers to hog resources pretty much at the hosts' discretion. In this case it can be argued that it's poor use of technology to implement it in the browser.
On a similar basis, one might argue that it's poor use of technology to kill people with dynamite, but it is also reasonable to take a step back and argue that it is poor use of technology already at the point at which you gave a toddler the detonator. Regardless, dynamite is an excellent and useful technology.
I'm not sure what you mean by that. Is there some limitation inherent to WebAssembly that makes implementing garbage collection particularly difficult?
For what it's worth, here's Lua (which implements a garbage collector in its runtime) in WebAssembly: https://github.com/vvanders/wasm_lua
Servo is not meant to be a real browser. That's not a bad thing, but I don't think you can use it as an example of a browser built quickly by a small team.
Edit: Looking at the project it seems like it uses SpiderMonkey, but is otherwise new code
From the developer's point of view that doesn't matter. You're delivering WASM and not C or JS code over to the clients.
That said, some of us have legitimate uses for said dynamite, pyromaniac infants be damned.
That being said it did take quite a lot of time to get to that point (tuning scan frequency, resolution, and a bunch of other things), and we looked into scandit recently (our company does use scandit in other products) and even though your library can detect and scan barcodes in worse conditions, it didn't really improve scan times or fix our biggest issues on web, which by the looks of it are the same issues you are running into. (iOS 11 being a pain in WebViews and sites added to the homescreen, and lack of the focus management APIs meaning you are at the mercy of the autofocus), plus the requirement for a license check at runtime is shooting our big use case in the foot (some of our users run the webapp offline for days at a time!)
But we have looked into some webassembly for some of this code, and I'm glad to hear it holds up about as well as expected on lower spec devices. I was worried about lower spec devices not being able to handle the larger "binaries" that WASM tends to produce.
And this is really off topic, but I'd love to pick your brain on how you "solved" the constraints issues on some devices with the getUserMedia stuff (flipping the aspect ratio requested, some devices rejecting all constraints except 2 or 3 "blessed" resolutions, problems with orientation affecting the returned resolution regardless of what was asked, etc...). I understand if you can't talk about it due to company secrets, but I figured I'd give it a shot! If you are open to it, my email is on my user page.
> plus the requirement for a license check at runtime is shooting our big use case in the foot
That should only be a problem with test licenses, ping us at support@scandit.com and we can help.
Hashsum bruteforcing? It already appears to be picking up, I'm having quite frequent browser crashes these days because of shoddily written JS miners trying to do stuff on GPU
Blame the OS, graphics card drivers, or the browser, but not JS!
Depending on your definition of "wholesale", the Edge team claims it took them 3 years to do exactly that:
https://blogs.windows.com/msedgedev/2017/04/19/modernizing-d...
In the browser it can run offline and does not need the server at all. Wheter a c++ compiler really makes sense, I doubt, but it will definitely come ..
It died pretty unceremoniously though.
The GHC runtime (that is huge) isn't much larger than a web font. It is not much out the range of the JS libraries out there.
What kind of issues are you thinking about? Multithreading is not easy but your typical race conditions and multi threaded problems aren't really opening doors to any new security exploits.
Browsers and WASM have quite decent sandboxing to mitigate security issues. There's WebWorkers already which brings a limited form of threads to the browser.
I'm not seeing a problem with multiple threads in a browser.
The VM should be sandboxing the pages from each other, so those are potential security threats against targets on the same pages only. Not something to be too concerned about.
You might try to use them to accelerate the same specific task but they have very different capabilities and performance limitations/advantages. Also one is fairly generalised and one is intended to be very domain specific, so don't share all the same types of potential application.
It's not. It's just that there are no other posts on that issue. GitHub does not have a way to make an issue visible to the public but hide all discussion on it.
> Locked
That's not the same thing. Locked just means you can't add your own comments, not that you can't see comments from other users.
They are adding native DOM access, which changes things.
It seems like you're claiming, in a really roundabout way, that WASM will never have DOM access, even though it's planned[1]. There are even VDOMs[2] for WASM already. Future WASM implementations that include DOM access can absolutely, and for many folks will, replace Javascript.
[1]: https://github.com/WebAssembly/design/blob/master/FAQ.md
That's an arbitrary distinction that's driven by developer group politics, not a meaningful technical distinction. (Much like the old Rubyist, "It's an interpreter, not a VM.")
Machine languages were originally intended to be used by human beings, as were punch cards and assembly language. There's no reason why a person couldn't program in bytecode. In fact, to implement certain kinds of language runtime, you basically have to do something close to this. Also, writing Forth is kinda close to directly writing in Smalltalk bytecode. History also shows us that what the language was intended for is also pretty meaningless. x86, like a lot of CISC ISAs, was originally designed to be used by human beings. SGML/XML was intended to be human readable, and many would debate that it succeeded.
Does it even matter when most people are using it as a compiler target (even just from newer versions of the language)?
HTML is far larger than the DOM. Like comparing an ant to Jupiter.
Asking WebASM to be everything, including a rendering engine, is asking for problems at such an atrocious level.
There's a lot of "legacy" there, a lot of stuff that probably should be removed, or at least relegated to a "deprecated" status.
If an API makes it easy to make mistakes it's a bad API. Blaming "people" is a cop-out.
If people are misusing the DOM API at a fundamental level(to do non-DOM related things), that's not a fault of the API. It's as if everyone has forgotten that DOM means Document Object Model. The vast majority of websites and web apps are not very complicated on the client-side, so I'd say that the DOM API generally does its job well. Trying to do anything that's not about constructing a document or is doing heavy amounts of animation or node replacement using a document-building API is asking for a bad time. It's quite implicitly attempting to break fundamentals of computer science.
Making the API one uses to render pages in a browser a free-for-all doesn't solve the problem, and you end up losing many of the advantages of having actual standards. What would be better is for the browser to provide another set of APIs for things beyond the "expertise" of the DOM. This kind of the case right now in some regards, but there's a reason why React and Glimmer use things like virtual DOMs and compiled VMs. I'd argue that a standardization of such approaches could be a different API that probably shouldn't even be referred to as a DOM because they are meant to take a lot of shortcuts that aren't required when you are simply building a document. In a sense, WASM is intended to fulfill this purpose without replacing the DOM or JavaScript.
Object-oriented programming is quite often misued/misunderstood. Does that mean it's a "bad" concept? I wouldn't say so. Education tends to suck, and people are generally lazy and thus demand too much from the tools they use.
I'm not copping-out because I'm not putting the DOM on a pedestal. Calling it a bad API because it doesn't work well for a small minority of cases is a total mischaracterization. If it was an objectively bad API, it wouldn't have seen the astounding success it has.
EDIT: I'm not saying that programmers are stupid... but that their expectations are sometimes not congruent with reality.
Video playback can be done via WebGL shaders, just like rendering video on the good old days with SIMD.
And most important, why not?
Someone will eventually do it, there are already JVM and CLR ongoing ports.
That, as far as I'm aware, is why Shumway died.
Same with games, for which there isn't even an alternative format to save them in.
Code:
print(_VERSION)
local a = setmetatable({}, {__mode = 'v'})
local b = setmetatable({}, {__gc = function(x) print("Deleting: " .. tostring(x)) end})
a[1] = b
a[2] = 2
print(table.unpack(a))
print(collectgarbage'count')
b = nil
collectgarbage()
print(table.unpack(a))
Lua 5.3
table: 0x50a748 2
21.4033203125
Deleting: table: 0x50a748
nil 2
Perhaps http://www.lua.org/demo.html could be replaced with that for users who have JS enabled.
Again - just wow, that's really nice, Lua in a browser.
Yes, in that you'd have to implement the GC inside the wasm module itself (as in your example). In contrast to other languages, Lua is very lightweight. Many GCs are non-trivial.
Moreover, proper GC support is a piece of the puzzle for the wasm/JS/DOM interop story to get better.
That is essentially the same problem people implementing garbage collectors on real machines are facing. You have some memory and you have to implement the algorithms and data structures necessary to allocate and free it as necessary.
> Lua is very lightweight. Many GCs are non-trivial.
Yes, but don't confuse the problem of implementing a garbage collector with the problem of implementing a system that can support a garbage collector. The former may be non-trivial, while the latter only supposes an architecture where you can arbitrarily manage memory "manually". From what I understand, you just hand WASM an array of memory and it can do whatever it wants with it, since it's a linear bounded automaton.
> Moreover, proper GC support is a piece of the puzzle for the wasm/JS/DOM interop story to get better.
The link seems to be addressing the use of VM-managed GC objects within WASM programs. That would certainly a nice feature, especially when it comes to interoperability with JS, but the lack of it is not a showstopper for implementing your own garbage collector as it has always been done.
In most cases it isn't non-trivial, and that's further compounded by the fact that the GC currently has to be part of the module payload at the moment.
If we're talking strictly implementation difficulty, then interop with VM-managed GC objects may in fact be more difficult; I'm certainly not an expert so I couldn't tell you.
>... but the lack of it is not a showstopper for implementing your own garbage collector as it has always been done.
Per the very first sentence of mine you quoted, I never said it was. It certainly is likely to be far from practical, however.
Also I suggest reading the sibling comment that Steve Klabnik replied with prior. The wasm host bindings proposal is now separate from the GC proposal.
I commented with a link elsewhere, but it seems that people have found a way around that!
https://news.ycombinator.com/item?id=15694292
https://news.ycombinator.com/item?id=15694289
I didn't see those, thanks. That's good news. Hopefully host bindings land sooner now than they otherwise would have if tied to the GC proposal.
The wasm32-unknown-unknown LLVM backend target for Rust is also quite exciting. I say this after having just spent a minor eternity compiling the Emscripten toolchain. :)
Implementing an open standard shouldn't be like this. Even proprietary formats like PDF are much simpler to implement than CSS.
You could probably say the same thing about any complex open standard, like FTP etc.
'Open standard' has nothing about something being simple and straight forward. What CSS is trying to do is complicated because of a whole bunch of pragmatic reasons.
Last time a browser tried to 'move things forward', ngate aptly summed it up as
Google breaks shit instead of doing anything right, as usual.
Hackernews is instantly pissed off that it is even possible to
question their heroes, and calls for the public execution of
anyone who second-guesses the Chrome teamHe didn't say anything about 'only server side stuff'. There is plenty that has already been demonstrated with webasm - video editing and filtering, audio editing and filtering, advanced computer graphics, direct porting of games, etc.
Even for that it doesn't work without some js. The promise was that you can use your favorite language for web development and that's not the case. WASM is now more about the integration with JS.
> The promise was that you can use your favorite language for web development
I can see where you are confused. The promise was never about using your favorite language for web development. It was about being able to compile languages to a synthetic ISA that will run at near native speeds.
> WASM is now more about the integration with JS.
It was never about getting away from javascript, it was always about being able to run software at near native CPU speeds in the browser.
Not at all. JavaScript is a textual language defined by a specification. Modern JavaScript does have a bytecode, but it is completely proprietary to the respective JIT compiler interpreting the code and utterly unrelated to the language's specification.
> There's no reason why a person couldn't program in bytecode.
True, but that isn't this discussion.
That is this discussion, because the fact that people program directly in JavaScript does not prevent it from being in the same class of things as a bytecode.
I am not going to say never. It does not now and will not for the foreseeable future though. I know DOM interop is a popular request, but nobody has started working on it and it isn't a priority.
Part of the problem in implementing DOM access to a unrestricted bytecode format is security. Nobody wants to relax security so that people who are JavaScript challenged can feel less insecure.
How would a browser know to restrict a web server compiled into bytecode specifically to violate same origin? The browser only knowns to restrict this from JavaScript because such capabilities are allowed only from APIs the browser provides to JavaScript.
I linked to the latest proposal downthread; people are absolutely working on this.
There's an expressiveness gap between languages with and without proper tail calls. (Unless you're willing to accept the unsafe-for-space solution.)
How far I would get before losing interest or facing those issues, I don't know.
For others who are curious about it, here it is: https://github.com/WebAssembly/tail-call/blob/master/proposa...
My point here is that it is beside the point whether it's trivial or non-trivial to implement a garbage collector. With regards to it having to be part of the module payload, that's how garbage collectors are typically implemented today, meaning it's very practical in the sense that you can just re-target that portion of your language runtime implementation like any other part without making the web a special case. Just target the new instruction set architecture and you have your garbage collector exactly as intended, tuned for the use case you designed it for.
> If we're talking strictly implementation difficulty, then interop with VM-managed GC objects may in fact be more difficult; I'm certainly not an expert so I couldn't tell you.
It may be more difficult, but in the end also an entirely different problem. If you have implemented a garbage collecting language runtime for your language, you've already solved the problem of garbage collection.
> Per the very first sentence of mine you quoted, I never said it was. It certainly is likely to be far from practical, however.
My question from the start was about how exactly it is impractical. Your reply focusing on the hardships of implementing a garbage collector and using the VM GC is an interesting side note, and I appreciate the response and discussion, but it ultimately doesn't answer the question. The evidence to my point is a fully functioning garbage collected language runtime compiled seemingly without modification (it's written in ANSI C, after all) for the WebAssembly platform. You can do that now, without additional hurdles and without considering the garbage collection semantics of the browser runtime. That seems very practical to me.
It is also very practical to be able to use objects allocated and managed by the browser instead of a contiguous array of memory, but that doesn't somehow make the obvious approach less practical.
>My question from the start was about how exactly it is impractical. Your reply focusing on the hardships of implementing a garbage collector and using the VM GC is an interesting side note, and I appreciate the response and discussion, but it ultimately doesn't answer the question.
The hardships of the implementation are central to why it's impractical. That said, I think we may be using different definitions of the word impractical here.[0] I'm talking strictly in a general sense, that packaging an entire language's runtime with code is—for most uses right now—not sensible.
You are correct in that it's entirely possible to use GCed languages inside wasm, and indeed it has been done—I'm not disputing that.
I also understand your point about the multi-platform advantages of keeping the GC portion of the runtime inside of wasm. Funny enough that may turn on its head in the distant future once GC support lands, assuming wasm ends up being a popular compilation target outside of the web. In that case you'd have wasm-managed GC objects on desktop and mobile.
>The evidence to my point is a fully functioning garbage collected language runtime compiled seemingly without modification (it's written in ANSI C, after all) for the WebAssembly platform. You can do that now, without additional hurdles and without considering the garbage collection semantics of the browser runtime. That seems very practical to me.
Lua is very lightweight. The story changes if you try to compile the .NET, JVM, Go or even V8 runtimes into wasm. All possible, but a hell of a lot more difficult.
One case study is Blazor.[1] The FAQ in its own readme states that it's not practical currently due to binary sizes, albeit not for GC-related reasons. But it will be practical. That was the gist of what I was trying to say, that GCed languages (i.e. ones that include their own runtime) are currently not terribly practical relative to the compiled alternatives, most of which are production-ready now.
Of course, having seriously evaluated Unreal Engine 4 for web use with its 50MB runtime, I view even Blazor's current 4MB binary size as quite practical, but it depends on the use case. For general web use, 4MB isn't practical.
In support of your point, I concede that whether the GC resides in the module or VM is largely immaterial to practicability as a whole. My point was that packaging the runtime with the payload is usually not sensible relative to the alternatives. I regret that I incorrectly generalized my original statement in terms of garbage collection rather than runtime overhead.
[0] https://en.oxforddictionaries.com/definition/impractical
That's a very general statement. There are many hurdles that will make porting some things to WebAssembly a pain, but I don't think GC in particular is one of them.
> That said, I think we may be using different definitions of the word impractical here.[0] I'm talking strictly in a general sense, that packaging an entire language's runtime with code is—for most uses right now—not sensible.
I don't we have a different idea of what impractical means. I am not talking so much about porting an entire language run-time for a language with a very system dependent run-time, and I am not talking about useful libraries of these languages, I am talking about garbage collection.
> I also understand your point about the multi-platform advantages of keeping the GC portion of the runtime inside of wasm. Funny enough that may turn on its head in the distant future once GC support lands, assuming wasm ends up being a popular compilation target outside of the web. In that case you'd have wasm-managed GC objects on desktop and mobile.
I doubt that using a single opaque garbage collector is a good option for many languages. It's interesting and would certainly make the implementation of new languages easier, but a garbage collector that performs well will probably always be quite language dependent. I also don't see the advantage of WebAssembly as a compiler target in general. We already have LLVM IR and the tooling that makes it a (relative) breeze to work with independent of the target.
> Lua is very lightweight. The story changes if you try to compile the .NET, JVM, Go or even V8 runtimes into wasm. All possible, but a hell of a lot more difficult.
Don't ignore that it's a very broadly applicable and quite popular language. There are plenty of languages not particularly dependent on large runtimes that use garbage collectors. It is not fair to conclude that a language with a garbage collector necessarily has a very complex runtime when implementations of the concept have existed since the late 50s. CLR (I assume that's what you mean by .NET), JVM and V8 are all JIT compilers. Porting that likely dwarfs the complexity of porting their garbage collectors. As for Go, I'm not sure why porting its run-time would be that much of a hassle. For JVM, there are already plenty of relatively tiny implementations.
> One case study is Blazor.[1] The FAQ in its own readme states that it's not practical currently due to binary sizes, albeit not for GC-related reasons. But it will be practical. That was the gist of what I was trying to say, that GCed languages (i.e. ones that include their own runtime) are currently not terribly practical relative to the compiled alternatives, most of which are production-ready now.
So it's impractical in some cases because of large binaries, not for any of the reasons you've pointed out so far. Giving WebAssembly programs a way to integrate with the VM GC will change this how, exactly? In Blazor's case the large file size can likely be attributed to things not strictly related to the run-time, like the core libraries.
> Of course, having seriously evaluated Unreal Engine 4 for web use with its 50MB runtime, I view even Blazor's current 4MB binary size as quite practical, but it depends on the use case. For general web use, 4MB isn't practical.
What is general web use, and how does it relate to WebAssembly? By jamming this technology into a browser in the first place, we've already conceded that the web is a generic application platform for which using plain documents or simple JavaScript is sometimes unsuitable. I don't necessarily agree that it should be, but here we are, and there are plenty of uses, given those terms, where large binary sizes may be justifiable. A large download may be worthwhile if it ends up in my browser cache and I am likely to use the application often. That doesn't mean it's suitable for serving ads in novel ways or implementing trivial web applications that you can easily implement in JS.
> In support of your point, I concede that whether the GC resides in the module or VM is largely immaterial to practicability as a whole. My point was that packaging the runtime with the payload is usually not sensible relative to the alternatives.
What are the alternatives? As far as I am concerned, it's either using regular non-web applications or using plain JS. If that's what you mean, I agree that those alternatives are better in a large majority of cases. The best case scenario is that WebAssembly will end up being "here's something closely resembling the CPU, here's some memory, here's some way to access and manage VM objects, and here's a way for JS to call your code". That's not going to make it much easier to port a language run-time or its libraries than it is for any other platform. It will make it easier to write code that interacts with the existing browser environment.
I'm talking about the former as pretty much the entirety of my previous comment tried to convey.
>I also don't see the advantage of WebAssembly as a compiler target in general.
The advantage is it would be a single target.
>So it's impractical in some cases because of large binaries, not for any of the reasons you've pointed out so far. Giving WebAssembly programs a way to integrate with the VM GC will change this how, exactly?
It's impractical primarily because it's not production-ready. In the interests of pedantry however, reliance on a VM GC would likely result in a somewhat smaller binary size.
>In Blazor's case the large file size can likely be attributed to things not strictly related to the run-time, like the core libraries.
Per its readme: "This is because Mono on WASM doesn't yet have any IL stripping or minification, and bundles a large runtime that includes many desktop-related features that are irrelevant on the web."
>What is general web use, and how does it relate to WebAssembly?
Most people use the internet to visit websites. Most major websites optimize their page loads as much as possible to fit as many ads in as they can without completely tanking the user experience. Using the previous example, a 4MB binary doesn't fit that use case. It would be more the realm of specialized applications.
>What are the alternatives?
Javascript ecosystem or production-ready compiled languages that target wasm.
http://webassembly.org/docs/faq/#why-not-just-use-llvm-bitco...