>Schema automatically used and checked, RI rules easy to pick up from the backend and applied to client data - all that nice well established Data Dictionary stuff available via xCase and similar tools. Yes you can work on arrays or JSON/object rows with lodash or even AlaSQL or load into SQL.js, but you will either have 2 ways to code same functionality in client and server or load 300+MB of JS for a runtime-functionalty probably most tested/used across all people already included at least in Chrome and Firefox and available as public domain in C if MS does not want to use own code.

Hmmm... Data Dictionaries? I haven't seen that sort of thing in many, many years - anywhere. These days those sort of rules are handled via the business layer and validation rules - or letting the DB handle basic rules. I'm not sure that I want to go back to that kind of control at the DB level...

>I would like to see/benchmark real use cases. WebAssembly is not machine code, but an easier-to-JIT format with the option to define C types/structs. It will help the first-to-interactive times, but will not abolish time needed for JIT. The speed of JITted JS running problems where you would prefer C/C++ over interpreted [Vfp or Python] pseudo-compiled code is often nearer to C than to other untyped/[p-]interpreted languages, so speed benefit might be less marked as expected. The drawback of sources running on the client being even more obfuscated will open the door for many new day niceties like drive-by-crypto mining or attacks that are harder to identify.

Well, I'm not sure there are use cases yet - I just think this is interesting as it might break the stranglehold that JavaScript has for Web development. The insane and fragile toolchains required to build modern JavaScript apps are driving me batty and when I see most of the developers I work with I can see that many would never even be able to play in that space. This stuff has just gotten so incredible out of hand with black box code upon black box code, and the creators walking around proudly about how they've solved a complex problem by making things even more complex...

Having alternatives may finally bring some much needed competition in that space and hopefully force JavaScript to realistically look at making the platform more self contained so all this support cruft isn't required (Who TF wants to deal with multiple module systems, multiple transpilers, and a million little tools to tweak this or that into submission and end up with a 200+meg toolchain for each project)? And then STILL be plagued by versioning issues on top of it.

The fact that WebAssembly can go straight to a byte code executable means that all of that pain can be potentially side stepped as language differences (ie. ES5 vs. ES6 vs Typescript) become a non-issue. How cool would it be if Typescript for example could compile straight down to Web Assembly? Or C# or Java or Python or even FoxPro if somebody knew how to build that?

We'll see if that actually pans out... but for now I'm cautiously optimistic that this has potential going forward.

Performance - I have no idea where that will pan out. I suppose Web Assembly should be faster because it doesn't need parsing - at the end of the day both interpreted and compiled code ends up as byte code that the browser eventually runs. I don't think perf is that huge of an issue these days. Browsers have become incredibly fast at executing JavaScript (or whatever the interpreters produce which is close to what Web Assembly produces).


>Ecmascript had too much syntactic sugar added lately for my taste - it would have been better to steer part of that energy into DOM or CSS

Given that the JavaScript was incredibly sparse I don't think that's a bad thing. String and Array functions that take most of the features that you needed loDash for are certainly welcome. Async await also is very nice. But yeah - there are a lot of funky cryptic functional features that are getting to many languages (including C#) that to me just feel incredibly unintuitive...

But maybe I'm just an old codger at this point, bitching and moaning about how life was easier twenty years ago. I guess it's a sign of the times... everything these days seems to be about more complexity and convolutions. Why should software be any different?

+++ Rick ---