301–310 of 346 posts
Earlier quoted context omitted.
While I don't agree with your second point, which seems to be there purely to exclude Python, I'll run with it so as not to devolve into religious war territory. How about Lua?
A line terminator on *nix isn't a line terminator on Windows, which is a big deal if line termination ends a statement, and that assumes the file isn't modified in transit.
Earlier quoted context omitted.
Implement a WASM JIT in kernelspace & you don't have to have a userspace while still having hot code hopefully optimized to remove bounds checking. Now all your programs are WASM modules & we can replace your CPU with some random architecture that doesn't have to care about supporting more than ring0. Oh why not implement a nearly-WASM CPU? Probably just change branches to GOTO. Now the only program people care about…
There’s prior art for this too, Microsoft started a research project called Singularity that was essentially a kernel that only executed .NET bytecode, and had similar advantages (everything in ring0, no syscall overhead, etc.) It died pretty unceremoniously though.
A good occasion to watch Gary Bernhardt's talk "The Birth & Death of JavaScript" [0] again, where he talks about the precursor of WebAssembly: asm.js and the future implication it "could" have in the future in a really humorous way. A few years old but still relevant. 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…
And for a somewhat more practical but at the same time more exotic example, the Internet Archive has a ton of old minicomputers and arcade games running in MESS/MAME, each compiled to webasm. One click and you can boot anything and play it in your browser. https://archive.org/details/softwarelibrary https://archive.org/donate/
Too bad makers of the original Minesweeper did not think to build touch input support.
Earlier quoted context omitted.
JS is a language and not a bytecode media. Perhaps chocolate will replace cars and airplanes. I love me some chocolate.
I am extremely unclear on whatever point you're trying to make, here, because it really does seem to come from a place of ignorance on WASM and JS. It makes no sense. 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 folk…
Earlier quoted context omitted.
While I don't agree with your second point, which seems to be there purely to exclude Python, I'll run with it so as not to devolve into religious war territory. How about Lua?
A line terminator on *nix isn't a line terminator on Windows, which is a big deal if line termination ends a statement, and that assumes the file isn't modified in transit.
Earlier quoted context omitted.
Most assembly languages have a "jump" instruction, though -- wasm supports only structured control flow.
It has br and loop , good enough.
All the excitement around wasm seems quite puzzling to me. Yes, I understand that you can program in whatever language you love but what new language are you hoping would be supported? C? C++? Fortran? As far as I am concerned, all the languages I care about already have compilers that target JS.
WASM is much lower level, and should allow compilers and VMs to use best-fitting data structures and layout.
Earlier quoted context omitted.
I think Blink's LayoutNG project and Servo both show that you can rewrite your layout implementation (and Servo also having a new style implementation, now in Firefox as Stylo). I think both of those serve as an existence proof that it's doable.
It's doable if you already have a large team of experienced web engine development experts, a multi-million budget and years to spend on just planning. 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.
Earlier quoted context omitted.
There is a lot of processing that doesn't inherently need the DOM, and there's also server-side stuff as well. I think you'd be surprised!
Yeah, but WASM was supposed to democratise the web development not to do just server-side stuff. Without DOM and Web APIs you can't do much Web related.
He 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.
Earlier quoted context omitted.
A line terminator on *nix isn't a line terminator on Windows, which is a big deal if line termination ends a statement, and that assumes the file isn't modified in transit.
And semicolons are optional in JavaScript, makes it whitespace sensitive I suppose.
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.