(btw I know WebAssembly isn't, strictly speaking, byte-code. It's a compact binary encoding of an AST. But it has all the characteristics that people really cared about when they asked for byte-code: it's a low-level representation that is a good compilation target for compiled languages)
Issue (1)--the forwards compatibility story--is the tricky one. Was it necessary to have asm.js as a stepping stone, or could we have gone all the way to Web Assembly from the beginning? I don't know, and we might never know, but having asm.js around for browsers that don't support wasm certainly doesn't hurt.
I was talking about about the sentiment that byte-code in general isn't necessary/feasible/desirable for the web.
The wasm guys may be right. Their predictions may have been accurate all along. But it may also be that we didn’t need this five years ago but we really do now.
Example: A Lua lexer, https://github.com/serprex/luwa/blob/f048aa2f67dfae00740d556...
Not to say it's any less exciting in regards to it's potential. But it's important to keep expectations balanced by present outcomes.
Nonetheless, the bloat train will resume at that point. And, the frontend will start having the same amount of fragmentation as the backend.
Good news for us, though, is job security. The resulting complexity helps us, at least in one way.
Web apps will be on equal footing and fragmentation as the old client/server model (vb, powerbuilder, delphi, c/x11/motif, visual c++ / mfc, dart/flutter, etc).
What comes around, goes around. The cyclic nature is pretty funny.
Err, I think that boat has already sailed?...
E.g. Grunt, Gulp, Webpack, make, Parcel, Brunch, Browserify, etc, etc, etc.
Frontend dev won't mean what it means today.
I don't think I despise an incentive as much as this one, even if it is a natural side-effect, not intentional. It's the reason why large and top-heavy bureaucratic organizations end up being a net-negative as a result of their structure. Despite their well intentioned attempts at 'fixing' the bumps in the road that natural free flowing systems generate, with top-down control and extreme risk management.
Instead of fostering common-sense and individual talent, it creates incentives and attracts people who care more about the organization itself, and their position within it, rather than the outcomes and value creation for which the organization was originally created.
edit: is it this? https://github.com/w3c/css-houdini-drafts/wiki
Article talking about why Houdini is different from normal CSS polyfills: https://www.smashingmagazine.com/2016/03/houdini-maybe-the-m...
And the related HN discussion (possibly a bit outdated): https://news.ycombinator.com/item?id=11357794
I've been through many programming languages. C# might be my favourite and F# always seemed like it would be if I took the time to learn it properly but for quite a few years now, JS has simply had such gravitational pull that I felt like I had to go with it. And I have to say, I've learned to not only like but to love it. Save for the mutable data structures that it supplies per default, it offers solid functional programming features and the culture embraces those. Still, there are times where I wish I could use something else.
NPM features quite a few packages written in other languages, with JS "binaries" available which I think is pretty neat. To me, packages seem like a much nicer place to choose language rather than, say, per microservice. A parser might be much cleaner in some pure functional language while some I/O library might work better in something else. But there is still only a subset of languages that compile to JS and the quality varies. But with LLVM supporting WebAssembly, I can see a future where it truly becomes the global binary format. Which would allow you to either write a combination of desktop, mobile and web apps (plus backend) in any language of your choice. Or, easliy write different packages in different languages and combine them into one app.
Just because the binary format can be shared doesn't mean code easily can. There's a tradeoff between requiring lots of glue or sharing a common lib across the langs. Either way, in WASM's current state, only the raw memory is shared and the only types are numeric primitives that can be used to address that memory. How each language lays out, for example, strings may be incompatible and most of the time where I've had to combine WASM libs for things like strings, there is a fallback to C-style (null-term'd or passing the length around).
So, while the common binary format will help open new architectures to existing langs, combining code from different langs still requires manual work and may be underperforming due to requiring they speak to each other in the lowest common denominator of raw byte arrays. Maybe some group will step up and federate a new libc for the WASM generation (even if there's no code and it only defines memory layouts). Even other proposals (GC w/ records/structs, host binding, ref types, etc) that bring higher level features don't necessarily solve interoperability issues.
This doesn't really exist unless you mean they need to not operate on the strings in their own memory and instead make a bunch of JS calls to operate on strings. That has overhead. Otherwise you have to use some approach to get the string to an array buffer (e.g. TextEncoder, charCodeAt, etc) and even though they are probably utf-8 internally, the step still exists to get them to WASM memory. For the GP's post about combining languages, it's no fun to do all of this to use a WASM Rust string in WASM Go (this is what I meant about "lowest common denominator").
The best you could get would be an API for a "string object".
Burroughs, Xerox PARC systems, ETHZ Lilith, Pascal UCSD, IBM TIMI, IBM Language Environment, ...
).then(bytes => WebAssembly.instantiate(bytes))
I came back, after RTFA, to say that I'm pleasantly surprised that it runs completely in the web browser.
It would be quite interesting when Browser Apps could also run as native apps without relying on electron (ie, being able to pull up their own UI when not provided one)
What do you see as the advantage of native at that point - having its own window?
If WASM apps simply use their own rendering, ie the Qt Toolkit they get a much more native feel on top of having a rendering engine that is more optimized for out of browser use (due to not having a DOM, etc.)
It would also slim down the applications a lot, notably when you dynamically link against the toolkit (which also means you share the lib with other apps instead of every app having it's own copy of electron)
Then there is the efficiency. My suspicion is that electron has a completely misconfigured caching system. Usually only one browser is running on a system and therefore many applications share the caching system. This means each electron application has an oversized cache that wastes memory and disk without meaningfully increasing performance.
Also, web now has desktop notifications - right?
That's the big benefit of Electron packing its own browser: you know exactly what engine it's running in and which version of said engine. It's not dependent on what the user wants to use, the last time they updated it, etc.
Are there downsides? Sure, but the upsides vastly outweigh them for most users.
Why do I keep seeing this style of comment on HN lately? Someone expresses an opinion about software architecture and someone begins their response “obviously you have zero experience working in this domain...”
It’s such an insulting way to start a conversation. And quite often a false assertion.
Baseless assertions about someone’s experience are just bullying rhetorical flourishes.
Sure I do, all the way back to when CGIs were still a thing, that is what Web development is all about.
It is no different than using any other programming language, graphical APIs, network API, or OS stacks backed up by standards.
Anything else is just being lazy at user's expenses.
Just imagine game developers shipping a GPU with their game just to be sure it is the same OpenGL version.
Electron apps aren't shipping you hardware. I think the more apt analogy would be installing a specific version of DirectX with your game... which a lot do.
Ultimately, I'd rather a company/developer spend more time actually building a better interface/product rather than perpetually fixing browser compatibility bugs.
> that is what Web development is all about.
While fixing bugs and dealing with compatibility issues are part of building any software, I'd hardly say that's what they are all about. That still holds with web development.
Do you think <successful web company> is successful due to their ability to squash compatibility bugs? Hardly. It's a means to an end.
> It is no different than using any other programming language, graphical APIs, network API, or OS stacks backed up by standards.
I would love for everything to be standardized across browsers, but I don't expect that to ever happen (fully).
That isn't to say Electron is bad, quite the contrary, but it isn't a silver bullet either.
To your "do you think..." question, I think it is an aspect in their success. Gone are the days where someone could say "this site requires IE 6/IE 7/Firefox/Chrome/etc." and be successful. Going onto Facebook, I don't think the site looks great, but it functionally works in any browser I've come across in an expected manner. But if they'd require a native electron or otherwise app? Wouldn't use it (don't have Facebook or Messenger installed on my phone or tablet, I only check messages where allowed which is desktop and tablet web sites, everything else I use it for works fine in mobile/tablet/desktop).
Please be as polite in a forum as you would be during a face to face conversation. You'd never start an office/remote work conversation with that line, would you?
I can see how it can sound harsher than intended in text-only.
I like these new in-browser IDEs.
They often bring a full-fledged build system with them.
Just open the URL, write your code, hit compile and download your build.
There are a number of C/C++ based node libraries... I think sass, sqlite are probably the two most popular. Any dependents of nan, node-gyp and node-pre-gyp are others.
I'd love to see the "Hello World" example template provided for all languages, not just C (or at least, for Rust as well, since the C++ version would be awfully close to the C one already).
EDIT: On a different note, I was confused when I loaded a template, hit "Run", and got nothing. I assumed running would automatically build first. It would be nice to somehow hint to the user if they run something that hasn't been built yet.
The compiler/converters are here: https://github.com/WebAssembly/binaryen
Maybe someone who knows more could help me understand better.
With LLVM-IR/WASM/SPIR-V it's kinda a shame we have all these standards doing very very similar things - but I kinda get the rational there
> So I guess going forwards WASM is the new crossplatform bytecode and not necessarily tied to the web - right?
Yes. Andreas Rossberg and other chief WASM people are touring conferences with talks called more or less "WebAssembly: Neither Web nor Assembly". It's a misnomer.
> I don't really get if WASM has memory-managment / garbage-collection by default
It doesn't. I'm not up to date, but last I heard the best that was offered was "at some point there will be APIs available for calling into the browser's runtime to get GC'd objects" or something like that.
It's simply not possible to compare LLVM-IR to WASM SPIR-V JVM BEAMVM CLR bytecode.
Here is my understanding: The C program assumes the C standard library is present. It is present, somewhere. Where, and in what version, is not clear to me.
Anyway, while the C standard library has an implementation of printf(), that implementation doesn't actually know how to do I/O. It relies on an underlying operating system to do the actual I/O. In particular, the library assumes that it is running on Linux, so once in a while it will emit system call number 146, which is Linux's writev(2) system call (http://man7.org/linux/man-pages/man2/writev.2.html). But there is no implementation of Linux running in the browser! And if there were, its conception of I/O would probably be different from what you expect. That is, you might want "output" to go to one of many different places, and WebAssembly can't guess what you want. That's why the program also implements a writev_c function to simulate this syscall. The corresponding mapping from syscall number 146 to this function is implemented in the accompanying main.js file.
So to program your browser in C-compiled-to-WebAssembly, you must implement your high-level application logic and the relevant low-level system calls, making educated guesses (through testing) about what syscalls the hidden mid-level library layer will emit. I'm a bit underwhelmed by this approach. But I guess over time standard syscall libraries will pop up and included in WebAssembly projects to allow you to go back to worrying only about your actual application.
The number of files is exactly the same as if you weren't using webassembly, other than the one rust/c source file.
It's just a shame that WebAssembly itself is a concept so deeply flawed in conception that it is unsalvagable, and that it'll hurt developers and users alike. Does opening the door to frontend development in C, Rust, Java, and the whole menagerie really seem like such a good idea?