251–260 of 346 posts
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.
Yes but the point is JavaScript as the "one true way to do client side scripting" can be replaced by webassembly in that capacity.
Earlier quoted context omitted.
Specifically for GC, all that page does is to refer to a GitHub issue that is invisible to anyone but WASM contributors :-(
Invisible? You mean locked? https://github.com/WebAssembly/design/issues/1079 I'm not a collaborator on the WebAssembly Org, but I can still see that issue just fine.
Earlier quoted context omitted.
Invisible? You mean locked? https://github.com/WebAssembly/design/issues/1079 I'm not a collaborator on the WebAssembly Org, but I can still see that issue just fine.
Yes, I see that there is an issue there, but the discussion is invisible. Hidden. Locked.
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.
Earlier quoted context omitted.
There's another reason why I want JavaScript in the browser to die: 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 Web…
How about Servo?
Edit: Looking at the project it seems like it uses SpiderMonkey, but is otherwise new code
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…
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.
Earlier quoted context omitted.
Multi threading brings in all kinds of security issues
What kinds of security issues? I really can't think of any besides some issues with too many threads spawned (that can be trivially blocked).
I'm not as excited for this as I used to be. In most user applications JavaScript is good enough or better. If it wasn't then we wouldn't be taking the browser to make desktop applications. Recently I decided to make a desktop app and asked around about the different UI libraries. The answer I keep getting is "just use electron and JavaScript". Why? Because love it or hate it the Dom is fantastic and simple for makin…
> will it even by worth it beyond a few specific applications? 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…
I wouldn't be so sure of that.
Can't wait for DOM interop and get away from JS on frontend. Seriously JS should not be the lingua franca of the web :)
When DOM access comes, all my js will hit the round file.
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.
Earlier quoted context omitted.
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…
> It seems like you're claiming, in a really roundabout way, that WASM will never have DOM access 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…
Can't wait for DOM interop and get away from JS on frontend. Seriously JS should not be the lingua franca of the web :)
Currently DOM interop is a distant wishlist, so I wouldn't hold my breath. JavaScript isn't a perfect language, but it does have native lexical scope, which makes it a good fit for the architecture of web technologies. > 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…