asm.js != webassembly You could already translate C to js anyway.
Name:
Anonymous2017-05-06 14:06
webassembly will be used to enforce DRM and binary blobs
Name:
Anonymous2017-05-06 14:15
The future of web browser scripting is, hopefully, a tombstone.
Name:
Anonymous2017-05-06 16:39
What if there was some kind of portable bytecode that managed memory for you? Maybe it would have statically typed opcodes for speed. It would be like a machine code, but not for physical hardware. Like a ``virtual'' thing. It could have a language that looks similar to JavaScript, but not for scripting. What could we call this thing? Java...something. Hmm...
Name:
Anonymous2017-05-07 5:14
>>5 They tried something like that, years ago, but the people in charge of it were idiots, so when they found out it had security vulnerabilities, rather than fix it they just made it impossible to run.
First of all, web assembly is a new binary format. Emscripten is the tool that transforms C to asm.js.
Secondly, no. Web assembly is useful for making webgames and "single-page applications," which is to say, trial-versions of your software that run in a web browser that can later be downloaded and run natively. Web-page scripting will still be done in Javascript.
Name:
Anonymous2017-05-22 13:32
What if our scripts were binary blobs and had buffer overflows and a binary blob array of bytes you have to allocate manually?
Wouldn't that make code fast? The compiler can throw away all of that bloated type and aliasing information to speed up the download. I think each script should bundle its own C and C++ libraries too. You might want to use different kinds of malloc for different scripts. Bundling every script with its own binary version of Boost would also be a great idea.
Name:
Anonymous2017-05-22 17:53
>>9 The hell do you even get from being able to read a minified Javashit ``source'' anyway? You fags sure love demonizing blobs like they're fucking ransomware.
Name:
Anonymous2017-05-22 19:53
>>10 Minified JS is trivial to de-minify. Whether WebAssembly is useful for obfuscating code depends on how abstract it is - if it's anything like real machine code, then making sense of it will be a real challenge, while if it's similar to CIL then getting the source back will be easy.
Name:
Anonymous2017-05-23 9:41
>>11 Making sense of copious amounts of obfuscated Javashit isn't very easy either.
Please give us a detailed walkthrough of the Google Analytics JS.
Name:
Anonymous2017-05-23 17:47
>>12-13 Given enough time, anyone can understand what it does by using formatting tools and then replacing back the function/variable names with something more descriptive.
It is obfuscated for sure, but deobfuscating javashit is very possible and easily done for most cases.
Name:
Anonymous2017-05-23 18:17
>>13 It's difficult to understand, but that isn't because of being minified. Minification is basically about eliminating whitespace, and its main purpose is to reduce code size, rather than obfuscation. It's still easier to RE than your typical non-obfuscated binary C function.
Name:
Anonymous2017-05-23 20:54
>>15 Must be a pain browsing the web if all you ever do is gauging the intent of the Javascript code you're about to run.
Name:
not >>152017-05-23 20:56
>>16 This may surprise you, but you aren't forced to enable Javashit.
Name:
Anonymous2017-05-23 21:20
>>17 Then why complain about something you don't use?
>>18 Because once compiling for browsers graduates from being a shitty hackjob to an officially supported and intended thing, I won't have the choice to not use it for however long it will take the mental midgets in web development to notice that making your entire site a webassembly program is retarded for the same reason making your entire site a Flash application was retarded a decade ago. Judging from how long it took them to notice the latter, this will be a really fucking long time. It would be even longer this time because webassembly is not associated with a company whose fuckups could kill it; also all security flaws in it would be blamed on the browser vendors rather than the retards who pushed this braindead idea of a standard.
Name:
Anonymous2017-05-24 0:42
Also "not using JS" isn't even really an option now, since many sites simply require it.
Name:
Anonymous2017-05-24 4:41
>>21 No only that. The site itself is a result of "web framework" constructing it from "virtual DOM" and "Dynamic CSS"
Not a chance. Its a web standard not proprietary plugin-> mandatory vendor support. Also it removes the burden of transcompiling to JavaScript, instead you just generate WebAssembly. Basically its a lower-level JS replacement.
Name:
Anonymous2017-05-24 11:39
>>23 I think you misread my post, I said it will take a long time to get rid of it, not to introduce it. Unless you meant that because it's mandatory we won't ever get rid of it.
Name:
Anonymous2017-05-24 13:22
>>24 >we won't ever get rid of it. Thats what i mean. Its a new JavaScript, except lower-level.
>>20 Would you rather prefer we stay with Javashit for the rest of our lives? At least WebAssembly would make web development somewhat sane.
Name:
Anonymous2017-05-25 19:12
>>27 Lay down the Hackerjews, it's rotting your brain. Browser scripting (i.e. executing random programs from the internet) isn't a law of nature, nobody forces you to do it. You aren't forced to choose between retarded shit in JS and retarded shit in WA. Just don't choose retarded shit.
Name:
Anonymous2017-05-25 20:54
>>27 There isn't any reason to think WebAssembly will make web development any more sane. It's main advantage is being more compact than JS, thus making it easier to download and faster to run. Since actually writing in WebAssembly is unimaginably horrible by modern standards, it will encourage compiling from HLLs, but that isn't really an ``advantage", we can already compile C++ to Javascript, and if Javascript was as bad a development language as the memers say it is, everyone would be doing that already. Furthermore, given how many Javascript programmers there are (see: node.js), it's quite likely that we'll end up just compiling JavaScript to WebAssembly. It's also going to be a long time before it becomes widespread, so targeting WebAssembly for a tiny performance advantage is silly, when you're going to need to provide a JS fallback anyways if you want your code to be portable. It ultimately won't do anything that Java applets couldn't, except maybe have a security policy that doesn't push the boundaries of retardation.
arithmetic in Javascript without overflowing at 20 + 20. It's also going to be as fast as native and it's not going to rape your Core i7 at all.
Javascript was as bad a development language as the memers say it is, everyone would be doing that already.
By your logic, no one would ever program in bad programming languages like PHP, Lua or JS. The web is a special case where everyone is forced to program in JS because there's literally no other choice. Even cross-compiling won't save you from all-floats or no lexical scope without incurring in additional overhead.
You're right about the rest, though that's due to the web being a great idea of having easily accessible ultra portable applications executed in the worst way possible.
Name:
Anonymous2017-05-27 17:33
>>30 What are you even trying to say here? >>29-san isn't wrong just because you randomly introduced new requirements. The fuck kind of requirements are these anyway? For small scripting Javashit is fast enough, compilation target or not; do you like the whole webapp garbage? By the way, while floating-point for everything is the dumbest design decision of all time, doubles can do integer arithmetic without problems up to 253. Not long long range, but floating-point numbers aren't the magic datatype from hell that corrupts random computations.
Name:
Anonymous2017-05-27 18:24
>>27-31 Just pretend JavaScript's numbers are FLONUMs[0] from Lisp with a ``numerical tower'' containing FIXNUM.
Just the same way Lua is ``fine'' for ``small scripts''.
This ``good enough'' shit is why PHP, Lua and Javashit exist. The web is a fully-fledged application platform now and we're stuck with the steaming piles of shit called scripting languages because someone thought it would be very ebin to use them for desktop-like applications.
do you like the whole webapp garbage?
I like the model of network-accessible applications and documents without previous installation, yes. I don't like the platform it's all being built on though. I still strongly prefer desktop applications over webapp garbage, though I wish I could use the web to make silly stuff like a snake AI contest without having to deal with the mess that's Javashit.
The web is a fully-fledged application platform now and we're stuck with the steaming piles of shit called scripting languages because someone thought it would be very ebin to use them for desktop-like applications.
We're stuck with them because Lispers taught (in universities, books, and now blogs) that dynamic typing was acceptable. Dynamic typing used to be shunned by programmers and serious computer science was about static typing.
Ruby and JavaScript were explicitly inspired by Lisp. Ruby used to be called MatzLisp before JavaScript ``carried the torch'' for the Lisp philosophy. They are Lisp and Scheme in disguise.
Name:
Anonymous2017-05-28 22:20
>>35 Dynamic typing is okay. Dynamic weak typing is not.
Name:
Anonymous2017-05-28 23:31
>>36 Ruby, JavaScript, Lua, and PHP are not weakly typed. Retards make up their own definitions of words, then they say ``strong and weak typing don't mean anything''.
Weak typing means the bits or ``value'' of an object can be interpreted in different ways (as different ``types'') by the programmer. None of these scripting languages allow this. They all use memory tags to prevent this from happening. FORTH might be weak dynamically typed. C is weak statically typed.