|
Vanadium posted:if you want a non-js-based bytecode, why arent you just shipping java applets not invented here! 
|
#
?
Dec 23, 2017 10:48
|
|
|
|
| # ? May 20, 2024 12:09 |
|
|
prisoner of waffles posted:If that's the problem, why is this bizarro AST-building exercise the solution? it’s like step 1 of the solution. when you have a lot of existing JavaScript code and you are deploying your code to browser, you have to make use of the js runtime environment step 1 is to reduce the amount of JavaScript source code that you are shipping to the minimum amount possible step 2 is to realize there’s a huge amount of JavaScript ast still being used and working to reduce it. this is straightforward if you’re already using WebAssembly for generating the ast. you are structuring your ast into snippets which are like higher level APIs defined in terms of the js runtime. you are also talking with the browser vendors to make sure these snippets get optimized to match the speed of native function calls in C step 3 is to consolidate the remaining JavaScript source code and infrastructure for generation of the JavaScript ast, and based on these standardize JavaScript Runtimes for the Web. JavaScript itself becomes just another of these runtimes step 4 is web developers of today lamenting how in their youth we used angular libraries to react to functional programming and we drat well liked it. both ways
|
|
#
?
Dec 23, 2017 11:26
|
|
|
Vanadium posted:if you want a non-js-based bytecode, why arent you just shipping java applets because no one wants to click through 10 security and deprecation dialogs just to use your site
|
|
#
?
Dec 23, 2017 15:24
|
|
|
Max Facetime posted:step 2 is to realize there’s a huge amount of JavaScript ast still being used and working to reduce it. this is straightforward if you’re already using WebAssembly for generating the ast. you are structuring your ast into snippets which are like higher level APIs defined in terms of the js runtime. you are also talking with the browser vendors to make sure these snippets get optimized to match the speed of native function calls in C i still think you have no idea what an ast is. Max Facetime posted:step 3 is to consolidate the remaining JavaScript source code and infrastructure for generation of the JavaScript ast, and based on these standardize JavaScript Runtimes for the Web. JavaScript itself becomes just another of these runtimes what on earth are you talking about
|
|
#
?
Dec 23, 2017 17:32
|
|
|
let me make it very clear for you what this proposal is. today's compiler: text javascript -> in-memory ast -> bytecode codegen -> (hot path) jit native optimization -> (hot path) jit optimization path binary ast compiler: serialized binast -> in-memory ast -> bytecode codegen -> (hot path) jit native codegen -> (hot path) jit optimization path you might notice the only thing that changes is the "text javascript -> in-memory ast". parsing is a non-trivial amount of initial execution latency. if we could somehow do codegen directly from "ast snippets" that would be as fast as function calls, we would, but the other passes are there for a reason and post-ast. that's also a rough flow of v8 which i know is missing a ton. other engines may differ.
|
|
#
?
Dec 23, 2017 17:38
|
|
|
eschaton posted:sorry, I don’t pay all that much attention to what new ways web “developers” are coming up with to gently caress users did you type this response in ms word or something because it has that dumb smart quote thing perhaps you would enjoy my article on webassembly which hopefully gives an approachable understanding of WebAssembly and also started the current discussion
|
|
#
?
Dec 23, 2017 17:40
|
|
|
nah, I’m good, I work on real software not web pages
|
|
#
?
Dec 23, 2017 21:56
|
|
|
Suspicious Dish posted:let me make it very clear for you what this proposal is. so bytecode codegen happens on a build server somewhere and the bytecode packages are downloaded to the client system, right? because if so congratulations JavaScript you invented Java applets but even shittier and if not lol that’s even worse just build real native applications using real languages people and let Brendan Eich’s abomination die in peace
|
|
#
?
Dec 23, 2017 22:01
|
|
|
they're not bytecode they're a serialized AST
|
|
#
?
Dec 23, 2017 22:54
|
|
|
im slowly turning javascript over this debate
|
|
#
?
Dec 23, 2017 23:28
|
|
|
eschaton posted:so bytecode codegen happens on a build server somewhere and the bytecode packages are downloaded to the client system, right? there are so many differences between Javascript and Java applets whether it's delivered as minified source or bytecode is one of the least important it only affects loading time, and this is a situation where JavaScript loses
|
|
#
?
Dec 24, 2017 00:11
|
|
|
Suspicious Dish posted:let me make it very clear for you what this proposal is. okay, look, you seem like a reasonably smart person, so let me just float something by you real quick-like, right? okay, so, what if, and please bear with me here but, what if, instead of “serialized binast -> in-memory ast”, you instead did “WebAssembly code+data -> in-memory ast”? I know, I know, that’s completely crazy and something only a very, very stupid person would actually even think about doing, but you could, theoretically, do that, right?
|
|
#
?
Dec 24, 2017 00:45
|
|
|
Max Facetime posted:okay, look, you seem like a reasonably smart person, so let me just float something by you real quick-like, right? okay, so, what if, and please bear with me here but, what if, instead of “serialized binast -> in-memory ast”, you instead did “WebAssembly code+data -> in-memory ast”? I know, I know, that’s completely crazy and something only a very, very stupid person would actually even think about doing, but you could, theoretically, do that, right? what is the advantage that this provides
|
|
#
?
Dec 24, 2017 01:13
|
|
|
idgi just define a vm with memory/register layout, calling convention, etc + a set of function headers for browser/dom hooks then whoever can make an app to compile 10 print "penus"; goto 10 and make it work
|
|
#
?
Dec 24, 2017 02:52
|
|
|
Max Facetime posted:okay, look, you seem like a reasonably smart person, so let me just float something by you real quick-like, right? okay, so, what if, and please bear with me here but, what if, instead of “serialized binast -> in-memory ast”, you instead did “WebAssembly code+data -> in-memory ast”? I know, I know, that’s completely crazy and something only a very, very stupid person would actually even think about doing, but you could, theoretically, do that, right? 1. parsing needs to be secure and you don't want your parsing code to be attacker-provided. like, webassembly doesn't let you poke into browser internals or anything like that. 2. obviously, in-memory ast is going to differ between js engines, meaning you'd have to have some standard which would be parsed into the actual in-memory ast used by the js engine. so it's actually "WebAssembly code+data -> in-memory standardized binast -> in-memory engine-specific ast" and still would have a parsing/validation step. 3. if you have a way of instantiating binast, as the proposal suggests, you can already do "WebAssembly code+data -> serialized binast -> in-memory ast". 4. why would you do this
|
|
#
?
Dec 24, 2017 03:00
|
|
|
then they wouldn’t be able to even pretend it’s JavaScript any more which might make some web “developers” sad despite making the world overall better
|
|
#
?
Dec 24, 2017 03:00
|
|
|
sorry m8 still sounds like a half-baked solution in search of a problemprisoner of waffles posted:PL thread:
|
|
#
?
Dec 24, 2017 05:35
|
|
|
wasm is a really bad control layout
|
|
#
?
Dec 24, 2017 10:20
|
|
|
carry on then posted:because no one wants to click through 10 security and deprecation dialogs just to use your site the original intended role for java applets was what sun demoed in their "hotjava" browser with a single jvm that ran all applets in isolated app domains, applets were low-overhead. you could run 100+ applets on a single page. use applets as a substitute for animated gifs. it all worked smoothly java was embedded into the browser itself, not a plugin. there was no reason hotjava could not have been extended to allow direct java access to the dom, for example. (except the dom didn't exist yet!) we very nearly lived in a world where java was the default language of the web. oops.
|
|
#
?
Dec 25, 2017 00:18
|
|
|
Notorious b.s.d. posted:the original intended role for java applets was what sun demoed in their "hotjava" browser... it all worked smoothly
|
|
#
?
Dec 25, 2017 07:08
|
|
|
Soricidus posted:and then throw it away completely and just use the jvm or .net clr like grownups thats our shaggar! 
|
|
#
?
Dec 26, 2017 01:49
|
|
|
mystes posted:I'm sure the idea was "smooth" but I seem to recall the actual browser crashing constantly. Like worse than early milestone releases of Mozilla. nah it was perfectly stable not the best html renderer, though. it really was only a proof of concept, not a fully fledged replacement for netscape 3.0 (the cutting edge browser of its day)
|
|
#
?
Dec 26, 2017 03:15
|
|
|
I think I actually just tried the alpha version now that I think about it. I didn't realize they kept developing it for so long.
|
|
#
?
Dec 26, 2017 03:34
|
|
|
necrotic posted:WebAssembly is very small subset of javascript, not just "a different format". web assembly isn't, but a javascript binary AST would be. that's why i'm saying WASM doesn't seem relevant
|
|
#
?
Dec 26, 2017 05:00
|
|
|
Gul Banana posted:web assembly isn't, but a javascript binary AST would be. that's why i'm saying WASM doesn't seem relevant
|
|
#
?
Dec 26, 2017 06:35
|
|
|
Suspicious Dish posted:1. parsing needs to be secure and you don't want your parsing code to be attacker-provided. like, webassembly doesn't let you poke into browser internals or anything like that. sure, I haven’t suggested it should Suspicious Dish posted:2. obviously, in-memory ast is going to differ between js engines, meaning you'd have to have some standard which would be parsed into the actual in-memory ast used by the js engine. so it's actually "WebAssembly code+data -> in-memory standardized binast -> in-memory engine-specific ast" and still would have a parsing/validation step. your conclusion doesn’t follow from your premise, not even if you use the word “obviously” what you’re suggesting is the same as saying “we could do less parsing when manipulating the DOM if instead of sending Strings to .innerHtml we could send arrays of bytes to a new .innerBinHTML api” I mean, technically you would, but is that really the best api you can come up with? Suspicious Dish posted:3. if you have a way of instantiating binast, as the proposal suggests, you can already do "WebAssembly code+data -> serialized binast -> in-memory ast". but that’s a garbage api and nobody cares about yet another file format so I guess chrome has already implemented it and there’s gonna be a polyfill for IE6 on MDN next week Suspicious Dish posted:4. why would you do this obviously the cure for too much parsing is more parsing / 
|
|
#
?
Dec 26, 2017 13:17
|
|
|
Max Facetime posted:what you’re suggesting is the same as saying “we could do less parsing when manipulating the DOM if instead of sending Strings to .innerHtml we could send arrays of bytes to a new .innerBinHTML api” this is a reasonable analogy. i want to remind you that engineering is about tradeoffs. what's the advantage of using the DOM API rather than an innerBinHTML? * well, one is that the the DOM is expected to change a lot, it's designed as a living object model. doing a full serialize/unserialize pass might be expensive. a living object model lets us do transformations on that tree a lot better. * DOM nodes can contain any attribute, so a loose k/v dictionary is required in the mapping anyway. * modifications of serialized data is actually destructive. I can't easily replace a DOM node in the middle and have its siblings unchanged. part of this is because the DOM has "hidden state" not serialized: the user's cursor position, selected text, scroll position -- I cannot, currently with innerHTML, assign those fields. the same doesn't apply to JS AST. * JS AST is designed for parse-once, not modification. the most you can possibly come up with is combining snippets of already-constructed ASTS, but we already have a method for composition: the function. * AST nodes themselves have a formalized set of fields, meaning you can have an easier time parsing since you just have an ordered collection of fields. * JS AST doesn't need to be living, in fact, it's more likely it will be thrown away after parse. there's also no analogous model to what happens if I change that AST after the fact, like if I modify DOM in-place. addendum: frameworks like React limit the dynamic nature of the DOM API anyway, preferring a more functional model. that they're implemented on top of DOM API rather than innerHTML is because of limitations in innerHTML, and they might honestly be better served by an API that lets them make atomic modifications to the tree, rather than treating it as a collection of objects. perhaps we will see an innerBinHTML in the future. one downside of the "living objects" model is that it's too easy to accidentally fall off a performance cliff with things like relayouts Max Facetime posted:obviously the cure for too much parsing is more parsing i hope you can agree that parsing JSON is different than parsing C++ is different than parsing fixed-length binary messages. the complexity of parsing differs heavily and in fact we have very formalized theory that gives us an understanding of the complexity to parse something.
|
|
#
?
Dec 26, 2017 19:59
|
|
|
all JavaScript parsing should be done on the developer’s build server to produce a linked binary artifact; what’s sent to the client should be bytecode rather than a “serialized AST” unless you want to stretch the definition of the latter past the breaking point
|
|
#
?
Dec 26, 2017 21:13
|
|
|
what advantages does a bytecode give you?
|
|
#
?
Dec 26, 2017 21:25
|
|
|
it can be designed for direct execution (emulation), code generation (JIT or AOT), or both, more straightforwardly than an AST really I don’t understand why the gently caress anyone would want to send an AST instead of a compiled product why is LLVM bitcode not just an AST? why did Sun create the JVM an MS the .NET runtime instead of just serializing ASTs? why did Smalltalk use a bytecode interpreter? why did Scheme-48 compile to bytecode instead of using an interpreter (since Scheme pretty much is an AST when represented as cons cells)? either there’s some advantage to sending an AST instead of a compiled bytecode that nothing else has seen or maybe it’s actually not that great an idea
|
|
#
?
Dec 26, 2017 21:37
|
|
|
Oh are we already to the point of killing the hackable web so that another inner platform can take hold?
|
|
#
?
Dec 27, 2017 04:37
|
|
|
the real question here is how does wasm make browsers a more compelling and effective platform for the most important class of users by which i obviously mean advertisers
|
|
#
?
Dec 27, 2017 04:49
|
|
|
how does wasm help companies ram ads straight up everyone's orifices every time they visit a web page ever can the new dom apis be designed in such a way that they "accidentally" make content blockers impractical or impossible to implement perhaps
|
|
#
?
Dec 27, 2017 04:54
|
|
|
i propose a native advertisment api, coupled with drm, that's injected straight into the video signal.
|
|
#
?
Dec 27, 2017 08:28
|
|
|
say “mcdonalds” to load next post
|
|
#
?
Dec 27, 2017 08:57
|
|
|
Internet Janitor posted:how does wasm help companies ram ads straight up everyone's orifices every time they visit a web page ever
|
|
#
?
Dec 27, 2017 14:52
|
|
|
you don’t need to run code to format the information presented on a web page, so browsers don’t actually need the ability to download and run code even for input validation you could just provide a predicate/expression language where validation predicates with well defined semantics can be attached to input fields, just like styles can be attached to presentation, and not have to worry about arbitrary code execution
|
|
#
?
Dec 28, 2017 00:29
|
|
|
no you see there are very good reasons why I need to implement my own email address validation instead of just having it built into the browser
|
|
#
?
Dec 28, 2017 00:31
|
|
|
Maybe, maybe not, but the genie's out of the bottle.
|
|
#
?
Dec 28, 2017 00:36
|
|
|
|
| # ? May 20, 2024 12:09 |
|
|
seems bad, op
|
|
#
?
Dec 28, 2017 01:29
|
|
