|
Shinku ABOOKEN posted:yes but what mechanisms does it have that javascript lacks? can you do x in wasm but not in javascript? what do you gain from wasm that you can’t gain by transpiling? mystes fucked around with this message at 14:03 on Nov 16, 2017 |
#
?
Nov 16, 2017 14:01
|
|
|
|
| # ? May 18, 2024 02:11 |
|
|
there's a lot of hype around vue.js and not a lot of actual traction as far as i can tell. i've looked at it several times, it's definitely a step backwards from react, not forwards. it's the exact same MVCrap as the literal hundred other templating languages exactly like it, except idk it kind of half-asses react's shadow dom without actually taking any of the other concepts on board. so i guess a prima donna who turns their nose up at jsx would be the sort of person who thinks vue is a good idea. unless there is something really fundamental that i'm missing from the introductory docs.
|
|
#
?
Nov 16, 2017 15:37
|
|
|
static html ftw
|
|
#
?
Nov 16, 2017 15:58
|
|
|
Powaqoatse posted:static html ftw
|
|
#
?
Nov 16, 2017 16:00
|
|
|
Suspicious Dish posted:the execution model and type system is still the same: you get a giant gently caress-off array full of floats and ints, and anything else is bolted on top of that. if it has ints, it's at least an improvement over js. numeric handling in js is my number 1 least favorite thing in the language
|
|
#
?
Nov 16, 2017 16:05
|
|
|
asm.html didn't really catch on
|
|
#
?
Nov 16, 2017 16:05
|
|
|
Vanadium posted:asm.html didn't really catch on
|
|
#
?
Nov 16, 2017 16:25
|
|
|
WebAssembly is allegedly getting thread support, a bit useless otherwise.
|
|
#
?
Nov 16, 2017 16:26
|
|
|
quote:you: please... you can't just make everything a web app
|
|
#
?
Nov 16, 2017 16:27
|
|
|
MrMoo posted:WebAssembly is allegedly getting thread support, a bit useless otherwise. https://bugs.chromium.org/p/chromium/issues/detail?id=766253 But seriously, I'm interested in seeing people try to make photo editing software and stuff like that in webassembly.
|
|
#
?
Nov 16, 2017 17:57
|
|
|
I haven't been following webassembly too much, but I don't think anyone is really supposed to make anything in webassembly, it's just supposed to be a compilation target...right? (maybe thats what you meant and i'm just reading too much into your words)
|
|
#
?
Nov 16, 2017 18:04
|
|
|
this guy is really excited about webassembly but I don't know enough to know how accurate his claims are
|
|
#
?
Nov 16, 2017 18:06
|
|
|
Thermopyle posted:I haven't been following webassembly too much, but I don't think anyone is really supposed to make anything in webassembly, it's just supposed to be a compilation target...right? (maybe thats what you meant and i'm just reading too much into your words) Once you don't need to go through JavaScript to access the dom, I suspect there will be languages that will only compile to webassembly. Honestly, seems it seems like JavaScript had just started to get decent I feel a little bit ambivalent about this, though. mystes fucked around with this message at 18:37 on Nov 16, 2017 |
|
#
?
Nov 16, 2017 18:34
|
|
|
Thermopyle posted:this guy is really excited about webassembly but I don't know enough to know how accurate his claims are quote:Right now, Steve’s proof of concept .NET Runtime is a 4MB download for any .NET app. That’s clearly not going to work. As Steve mentions, there are lots of optimizations to do that’ll bring down the size, but the real optimization win is going to be when the next version of WebAssembly comes out, including two big features: plugging into the browser’s VM and access to the DOM. The WebAssembly working group are already discussing both of these (e.g. here’re the notes from a recent meeting discussing garbage collection). yeah the gc spec is on pause until after host-bindings happens. womp womp. i dont think its going to happen. also "tree shaking" isn't a loving webassembly feature, it's literally dead code elimination and every compiler has had it for years. why do people keep talking about "tree shaking"
|
|
#
?
Nov 16, 2017 19:10
|
|
|
steve sanderson owns.
|
|
#
?
Nov 16, 2017 19:13
|
|
|
Suspicious Dish posted:yeah the gc spec is on pause until after host-bindings happens. womp womp. i dont think its going to happen. also "tree shaking" isn't a loving webassembly feature, it's literally dead code elimination and every compiler has had it for years. why do people keep talking about "tree shaking" I think he brought it up in the context of bringing down the size of distributing the. NET runtime, not that it was some exclusive feature that webass was revealing to the world. (Also, typing. NET correctly is not worth the trouble with SwiftKey)
|
|
#
?
Nov 16, 2017 19:34
|
|
|
sure, and all of the things he mentioned are available with asm.js as well. what did webassembly actually enable?
|
|
#
?
Nov 16, 2017 20:34
|
|
|
better performance and, most importantly, absolutely no javascript.
|
|
#
?
Nov 16, 2017 20:38
|
|
|
Shaggar posted:better performance and, most importantly, absolutely no javascript. neither of those are true
|
|
#
?
Nov 16, 2017 20:40
|
|
|
idk how you're gonna defend javascript performance vs c, but ok i'll let you die on that hill. also web assembly is not javascript at all.
|
|
#
?
Nov 16, 2017 20:58
|
|
|
Javascript, like lead or syphilis, eventually leads to derangement in those exposed to it over long periods of time. Of course someone is going to defend it.
|
|
#
?
Nov 16, 2017 21:29
|
|
|
Shaggar posted:idk how you're gonna defend javascript performance vs c, but ok i'll let you die on that hill. webassembly does not give you the performance of c. you bought snake oil. Shaggar posted:also web assembly is not javascript at all. no but it requires javascript to do anything worthwhile.
|
|
#
?
Nov 16, 2017 21:38
|
|
|
it may not be totally c level, but its orders of magnitude faster than javascript. and the whole point of web assembly is to remove any need for javascript and since all you ever use javascript for is hacking the dom and web assembly allows this, you no longer need javascript for anything.
|
|
#
?
Nov 16, 2017 21:44
|
|
|
Suspicious Dish posted:sure, and all of the things he mentioned are available with asm.js as well. what did webassembly actually enable? i mean, I'm not defending his points about webass because I don't know enough about the subject, I'm just saying I dont understand why you criticized him for bringing up tree-shaking. seems like a valid thing for him to bring up when talking about the fact that, currently, the .NET runtime is too big in webassembly. maybe compiling the .NET runtime to webassembly already tree-shakes out all the dead code, i dunno. if thats the case then yeah gently caress that guy to hell for saying it imagine hes talking about asm.js and he said tree-shaking would bring down the size of the .NET runtime, whats the problem? also, you may be the first person i've seen to say that webassembly doesn't bring higher performance
|
|
#
?
Nov 16, 2017 22:00
|
|
|
Thermopyle posted:i mean, I'm not defending his points about webass because I don't know enough about the subject, I'm just saying I dont understand why you criticized him for bringing up tree-shaking. seems like a valid thing for him to bring up when talking about the fact that, currently, the .NET runtime is too big in webassembly. because "tree shaking" isn't actually a thing that you can do on c++ code. you can do "dead code elimination", "gc-sections", all that other fun jazz. to me it means that guy has no clue what on earth he's talking about and doesn't know what a compiler is or how webassembly works Thermopyle posted:also, you may be the first person i've seen to say that webassembly doesn't bring higher performance right now webassembly is fast because it doesn't do anything and you need a giant pile of js alongside it that actually does the heavy lifting. i'm less optimistic it will be fast once they add gc, host bindings, etc., because the execution model is much, much worse for generating good code.
|
|
#
?
Nov 16, 2017 22:25
|
|
|
Shaggar posted:it may not be totally c level, but its orders of magnitude faster than javascript heavy citation needed. show me webassembly code that's fast and i can show you equivalent javascript that's faster.
|
|
#
?
Nov 16, 2017 22:26
|
|
|
Suspicious Dish posted:"tree shaking" the term originates with lisps, I believe. It's generally distinct from dead code elimination because it's a whole-program analysis that also removes unused symbols (kinda like 'gc-sections' on a statically linked binary). some lisp people imported it to the javascript community to describe what things like the closure compiler would do: normally you can't remove symbols in javascript because you can't track what's used, but these tools enforced certain constraints and managed to do it anyway so a lot of javascripty people have adopted the term because that's how they first learned it I was surprised the first time I heard it too, but I just give up on fighting people's choices of terminology like this transpiler ah well
|
|
#
?
Nov 16, 2017 22:38
|
|
|
i first read about tree-shaking in some paper about how nasa made their common lisp image fit into the memory of their sat eliteShinku ABOOKEN posted:yes but what mechanisms does it have that javascript lacks? can you do x in wasm but not in javascript? what do you gain from wasm that you can’t gain by transpiling? it has 64-bit integers
|
|
#
?
Nov 16, 2017 23:04
|
|
|
maybe dont write code that wont run????
|
|
#
?
Nov 16, 2017 23:08
|
|
|
my code always runs one day i will catch it
|
|
#
?
Nov 16, 2017 23:50
|
|
|
If your code runs and your feet smell, you might be upside-down.
|
|
#
?
Nov 16, 2017 23:56
|
|
|
vue is knockoutjs 2016 w/o old browser support. it doesn't do anything new, but it looks like it does what it does well which isn't saying that what it does is good. vue is all about two-way binding, which is a fundamental mistake at least it provides a first-party flux-/redux-alike state management lib in the form of the awfully-named vuex, which is a step in the right direction at least
|
|
#
?
Nov 17, 2017 04:20
|
|
|
yeah, the addition of int64 is honestly really good. i'm going to spend some time in the wasm group and hopefully push good ideas through because boy howdy does this thing need some destinkifying
|
|
#
?
Nov 17, 2017 04:23
|
|
|
Suspicious Dish posted:yeah, the addition of int64 is honestly really good. i'm going to spend some time in the wasm group and hopefully push good ideas through because boy howdy does this thing need some destinkifying does int64 in webasm mean we can use integers in regular js and get sane results
|
|
#
?
Nov 17, 2017 05:37
|
|
|
no, because it only applies to wasm. any int64 going to javascript goes through as a pair of int32's
|
|
#
?
Nov 17, 2017 05:49
|
|
|
mystes posted:Blah blah blah turing completeness. But in reality it will make it a lot more practical to replace desktop applications for a lot of stuff. no it won’t because a web page isn’t a replacement for a desktop (or mobile) application
|
|
#
?
Nov 17, 2017 08:42
|
|
|
Suspicious Dish posted:yeah the gc spec is on pause until after host-bindings happens. womp womp. i dont think its going to happen. also "tree shaking" isn't a loving webassembly feature, it's literally dead code elimination and every compiler has had it for years. why do people keep talking about "tree shaking" they’re pretending to be Lisp hackers “tree shaking” is what dead code elimination was called in Lisp environments, because you worked in an image based environment that included the development tools; to build a standalone distribution for your application, you had to grab it by the roots and shake all the tools and stuff out of it these days Lisp people still work in image based environments, but they build up applications using system definitions so they can get dependency handling, reproducible builds, and so on and by “these days” I mean “since the introduction of defsystem in the early 1980s”
|
|
#
?
Nov 17, 2017 08:48
|
|
|
if only Brendan Eich had said “only a week? gently caress it, you’re getting Scheme-48 and you’ll like it”
|
|
#
?
Nov 17, 2017 08:58
|
|
|
i mean javascript is not a great language but the biggest problem with javascript is not the actual programming language, it's the dom and everything that goes with it, and lol if you think that would actually have been better with a lisp as the scripting environment
|
|
#
?
Nov 17, 2017 09:04
|
|
|
|
| # ? May 18, 2024 02:11 |
|
|
imagine web programmers if they had defmacro
|
|
#
?
Nov 17, 2017 09:16
|
|