|
sorry, it’s really not clear to me what message we’re supposed to be getting from your article you say WebAssembly is “kicking the can down the road” and it’s not an all-singing, all-dancing VM which maybe some people are promoting it as but all I really see in support of that is that host bindings are slow and involve reflection (why? how can this be addressed?) and that GC isn’t great WebAssembly is just another attempt to make it easier to write “real code” that runs in the browser, not fundamentally different than JavaScript, Java, ActiveX, Flash, etc., and in fact piggybacking (though it apparently doesn’t have to) on existing JavaScript infrastructure the ultimate problem here is actually that people are writing code to run in the browser when they should be writing native apps, and the fact that web-centric developers keep trying to shove ways to deliver ever more complex code via the browser is symptomatic of the fact that, at some level, they know this
|
#
?
Dec 31, 2017 03:50
|
|
|
|
| # ? May 22, 2024 18:55 |
|
|
it is very obvious from your article that the goals of the wasm project just don't match your personal desired goals and that you are Real Internet Mad about it. somehow that fact manages to shine right on through despite the fact that, frankly, i am not entirely sure what the goals of the wasm project are, or what you think they are, or even what you think they ought to be; but it is quite clear even from your muddled musings that the differences in design are due not to accident or oversight, but to a difference in goals maybe you should go think about it more and then write a much better article in which you lay out the problems that wasm is purporting to solve and why they are variously either not important or could be better solved by an alternative approach
|
|
#
?
Dec 31, 2017 05:58
|
|
|
hence why it isn't published. it needs a ton of editing still to make clearer what i want to say. i don't think there's a large disconnect between the goals of what i want it to be and what the project is accomplishing. i think i understand both pretty well and i'm not angry about it. the disconnect here i want to focus on and am writing about is between the common understanding of what wasm will enable on the web, and what the goals of the project actually are. the "pop culture" understanding is that "wasm = web page c++ binary fast zoom zoom". i understand that projects are the results of a large set of tradeoffs, and my article's goals isn't to opine on those tradeoffs and say that they are good or bad, but to simply make people aware of them. my personal worst case scenario is one where people think "vm bytecode = fast" and don't understand the subtleties and nuances involved in making a platform but yes right now it comes out like i'm anti-wasm which i'm not.
|
|
#
?
Dec 31, 2017 09:20
|
|
|
Suspicious Dish posted:my personal worst case scenario is one where people think "vm bytecode = fast" and don't understand the subtleties and nuances involved in making a platform but yes right now it comes out like i'm anti-wasm which i'm not. if the point isn’t to provide a fast bytecode-based virtual machine that can be more easily targeted by native-code compilers, then what is the point? anything else seems like even more of a waste of time.
|
|
#
?
Dec 31, 2017 09:42
|
|
|
maybe so you don't have to compile to javascript
|
|
#
?
Dec 31, 2017 09:54
|
|
|
obviously the high-level goal is "a fast bytecode-based virtual machine that can be more easily targeted by native-code compilers" but there's a lot of choices to be made inside that: 1. you *have* to interact with a GC in order to interact with the web platform. that's not a question. where does this GC fit in? how much control does the native language have over its behavior? can the language run GC passes at will? if so, does that mean the GC is now observable? wasm's GC extension has been in development for over a year because these are *hard* problems, and host-bindings was intended to curb that behavior. 2. how does the native code interact with GC handles and objects, when a target language might not have a traditional "object model" at all? Microsoft invented those hat pointers in C++/CLI to answer this issue. the current host-bindings spec simply says "you get a u32 in your code, write your own wrappers", though that might be changing. jvm/cli have a native "object" type that can be placed on the value stack, and provide a "callmethod" operator. 3. is the expected performance profile more aot or more jit? should we design our compile target to have high-performance equivalents of potentially slow operations, or should we expect a sufficiently smart jit to inline and wipe away that cost? this is something the jvm wrestles with as well: java's jvm bytecode is only fast because the jit brings the performance back to what a programmer thinks it should be. the current expectation is that wasm is aot'd and cached, and that jit shouldn't be done to give a more flat performance profile without jit "spikes". and plenty more that are important to explore. there isn't one right answer to these questions, they are tradeoffs that have multiple valid answers but sometimes have far-reaching consequences.
|
|
#
?
Dec 31, 2017 10:01
|
|
|
if i understand correctly, you're trying to get across less-understood points like - wasm can't interact well with browser functionality yet, and there's no clear path to allowing it - wasm isn't a good target for high level languages (basically anything above C++ or Rust), and it would be particularly nonsensical to target it from javascript or typescript - wasm doesn't obviate the utility of JS due to the above flaws, and so parallel improvements like a JS binast are being implemented but i may be reading that stuff into the article since i was already aware of (and concerned by) it. people seem to think that it's only a matter of time until you can, like, write a webpage in Python or C# but that is not necessarily the case
|
|
#
?
Dec 31, 2017 13:14
|
|
|
e: instant regret getting into a js argument
|
|
#
?
Dec 31, 2017 13:39
|
|
|
every time i try to learn about wasm i feel like i end up even less informed than i was before
|
|
#
?
Dec 31, 2017 13:59
|
|
|
who gives a poo poo, stop trying to do heavy math in the browser and just create/delete dom elements and do ajaxy stuff like a decent human being
|
|
#
?
Dec 31, 2017 14:10
|
|
|
this discussion is hilarious in the amount of time it's taken to noodle through what wasm actually is and is not everyone itt probably could just learn how to write javascript well Blinkz0rz fucked around with this message at 14:15 on Dec 31, 2017 |
|
#
?
Dec 31, 2017 14:13
|
|
|
Blinkz0rz posted:write javascript well rofl
|
|
#
?
Dec 31, 2017 15:25
|
|
|
cat > /dev/null binch
|
|
#
?
Dec 31, 2017 15:25
|
|
|
Blinkz0rz posted:this discussion is hilarious write a distributed map/reduce function in erlang
|
|
#
?
Dec 31, 2017 15:33
|
|
|
the only problem people itt seem to be trying to solve with wasm is to not have to write javascript but who loving cares it's just javascript. learn to write it rather than copy-pasting snackoverflow answers and then wondering why it doesn't work
|
|
#
?
Dec 31, 2017 15:36
|
|
|
NihilCredo posted:write a distributed map/reduce function in erlang k give me a few weeks (aka the length of time this thread has been talking about wasm)
|
|
#
?
Dec 31, 2017 15:36
|
|
|
how low have we fallen that people are promoting writing javascript itt
|
|
#
?
Dec 31, 2017 15:41
|
|
|
you're trying to solve a problem where the "solution" is more complicated and difficult than the actual problem itself
|
|
#
?
Dec 31, 2017 15:45
|
|
|
es gibt nur ein endlösung für der internetfrage imo
|
|
#
?
Dec 31, 2017 15:53
|
|
|
rt4 posted:who gives a poo poo, stop trying to do heavy math in the browser and just create/delete dom elements and do ajaxy stuff like a decent human being heres my hot take: the only reason we see web apps as such a shitshow is because of javascript and wasm is a step towards a world where good web apps exist
|
|
#
?
Dec 31, 2017 15:53
|
|
|
there are valid reasons to choose compiling a good language to wasm over writing javascript, and there are valid reasons to choose writing javascript over compiling to wasm i do not know, however, of any valid reason to choose compiling to wasm over compiling to javascript, at least in december 2017 and for serious production systems. js compilers have their warts and abstraction leaks but even the most experimental ones are battle-tested tanks compared to wasm prototypes
|
|
#
?
Dec 31, 2017 15:59
|
|
|
rjmccall posted:i actually call it gdce, iirc tree shaking is just an algorithm. g == global? rjmccall posted:lispers really like conflating concepts with implementations because lispers are the wolframs of plt. idgi 
|
|
#
?
Dec 31, 2017 16:19
|
|
|
NihilCredo posted:i do not know, however, of any valid reason to choose compiling to wasm over compiling to javascript, at least in december 2017 and for serious production systems. js compilers have their warts and abstraction leaks but even the most experimental ones are battle-tested tanks compared to wasm prototypes absolutely true, and it's going to take years to solidify the standards and years after that until enough of the market share supports wasm to make it worth developing for. however, this was also once true of flexbox, canvas, webgl, web audio, video and audio tags, ES5, CSS3, and so on. we'll get there.
|
|
#
?
Dec 31, 2017 16:25
|
|
|
Gul Banana posted:if i understand correctly, you're trying to get across less-understood points like yeah these are the main points CommunistPancake posted:heres my hot take: the only reason we see web apps as such a shitshow is because of javascript and wasm is a step towards a world where good web apps exist i'd honestly blame the dom more than javascript honestly.
|
|
#
?
Dec 31, 2017 17:55
|
|
|
Nah, js isn't the reason people see web apps negatively It's all the stuff around js like the DOM and the restrictions the browser puts on js code
|
|
#
?
Dec 31, 2017 17:57
|
|
|
i'm interested in wasm since i'm interested in compilers, and i'm interested in an aot perf profile target for the web. i know javascript very well thank you very much and am extremely comfortable in it.
|
|
#
?
Dec 31, 2017 18:00
|
|
|
javascript was only ever intended to open popup windows and close popup windows and everything else that's been tacked onto it is a disaster. its a very very bad language and its the only reason the web sucks. its not at all the fault of the dom.
|
|
#
?
Dec 31, 2017 18:06
|
|
|
Suspicious Dish posted:obviously the high-level goal is "a fast bytecode-based virtual machine that can be more easily targeted by native-code compilers" but there's a lot of choices to be made inside that: this post seems like a good structure for your article you start by laying out the background. this gives you ample room to come across as friendly to the wasm project. use the authorial voice to describe the problems that wasm is solving, then say that wasm addresses them well. if you can do this in a fairly brief paragraph, you can lead with it without burying your thesis too much. i think this should be possible because there’s no real need to get into technical detail up front your thesis is complex and deserves its own paragraph. you think that wasm has set out a reasonable start but there’s some major design issues that wasm hasn’t solved yet, and how it finds those solutions will shape a lot about how useful wasm ends up being. this is something you should put a lot of care into drafting you can then have three named sections for each of these bullets where you get into a lot more technical detail, then wrap it up with a conclusion about where wasm is right now
|
|
#
?
Dec 31, 2017 18:11
|
|
|
CommunistPancake posted:absolutely true, and it's going to take years to solidify the standards and years after that until enough of the market share supports wasm to make it worth developing for. however, this was also once true of flexbox, canvas, webgl, web audio, video and audio tags, ES5, CSS3, and so on. we'll get there. yeah but what's the point unless wasm has its own vm? you're still going to have to write the js glue and dom manipulation anyway. the biggest advantage wasm has is how compact the payloads theoretically could be. performance wise, there's still no support for js data structures so unless you're doing computationally expensive operations (and let's be honest, the most computationally expensive js is all dom anyway which precludes wasm) there's really no point.
|
|
#
?
Dec 31, 2017 18:12
|
|
|
js can be bad and still not be the reason people see web apps negatively but anyway wrt to dish's article... i'm not entirely sure that anyone who matters views webass (it's webass damnit, not wasm!) as the savior your article is arguing against. I think the people taking the position you're arguing against are just vanilla web developers who aren't in the position to be contributing to the standards or browsers anyway of course, an article targeting vanilla web devs may be worthwhile, but i think your article doesn't seem like its written in a manner that those people are going to understand well anyway all that being said, i also haven't done an intensive survey of all writing about webass and maybe i'm wrong about the lay of the webass-rhetoric land...it's just not the feeling i get after reading the dozens of webass articles that came across my feeds over the past year. it kind of feels like you read one post somewhere that you disagree with and your article is the response to that
|
|
#
?
Dec 31, 2017 18:14
|
|
|
webass can get performance increases, but whether that's worthwhile depends on what your apps performance bottlenecks are https://hackernoon.com/screamin-speed-with-webassembly-b30fac90cd92 I think thats the article i'm thinking about, but i don't have time to re-read it...
|
|
#
?
Dec 31, 2017 18:16
|
|
|
Shaggar posted:javascript was only ever intended to open popup windows and close popup windows and everything else that's been tacked onto it is a disaster. its a very very bad language and its the only reason the web sucks. its not at all the fault of the dom. i know i'm getting shaggared hard but your shtick is getting old. it's extremely unlikely that anything will replace js at any point in the next 10 years and even so whatever does will have to be backwards compatible to support the legacy web. javascript really isn't that bad a language. it has a whole bunch of warts that can be terrifically frustrating, but the reality is that the majority of complaints you hear are from people who don't learn the language and copy and paste bad code from snackoverflow. yeah no poo poo your js is going to be bad and you'll have a bad time if you can't be bothered to actually understand what's going on.
|
|
#
?
Dec 31, 2017 18:17
|
|
|
javascript apologia has no place within these hallowed halls
|
|
#
?
Dec 31, 2017 18:21
|
|
|
Blinkz0rz posted:javascript really isn't that bad a language. JavaScript (/ˈdʒɑːvəˌskrɪpt/[6]), often abbreviated as JS, is a high-level, dynamic, weakly typed, prototype-based, multi-paradigm, and interpreted programming language.
|
|
#
?
Dec 31, 2017 18:22
|
|
|
comedyblissoption posted:c apologia has no place within these hallowed halls
|
|
#
?
Dec 31, 2017 18:22
|
|
|
c is an equally painful language with way more dangerous warts.
|
|
#
?
Dec 31, 2017 18:23
|
|
|
i'm guess i'm ok with javascript because its what we get for using that monkey's paw to get rid of flash
|
|
#
?
Dec 31, 2017 18:26
|
|
|
NihilCredo posted:JavaScript (/ˈdʒɑːvəˌskrɪpt/[6]), often abbreviated as JS, is a high-level, dynamic, weakly typed, prototype-based, multi-paradigm, and interpreted programming language. it's easy to deploy and run on anything, and the language itself has improved immensely over the past few years.
|
|
#
?
Dec 31, 2017 18:27
|
|
|
Blinkz0rz posted:i know i'm getting shaggared hard but your shtick is getting old. it's extremely unlikely that anything will replace js at any point in the next 10 years and even so whatever does will have to be backwards compatible to support the legacy web. it is a bad language especially when people start abusing it for extreme dom manipulation (aka modern web ui frameworks). you cannot learn to write good javascript because there is no such thing as good javascript. The only thing you can do that approaches good javascript is to use the least javascript possible. wrt javascript being replaced within the next 10 years, it wont disappear for sure because there are tons of web "developers" out there who will cling to it, but the rest of us will be able to eliminate it from our lives via stuff like blazor.
|
|
#
?
Dec 31, 2017 18:33
|
|
|
|
| # ? May 22, 2024 18:55 |
|
|
Shaggar posted:it is a bad language especially when people start abusing it for extreme dom manipulation (aka modern web ui frameworks). you cannot learn to write good javascript because there is no such thing as good javascript. The only thing you can do that approaches good javascript is to use the least javascript possible. all i see is old man shouting at web
|
|
#
?
Dec 31, 2017 18:34
|
|