Is WebAssembly to compile C++ script directly into browser

Hi guys,

According to this article: http://techcrunch.com/2015/06/17/go...-webassembly-a-new-binary-format-for-the-web/

If I'm not mistaken it seems that WebAssembly is going to compile other languages like C++ into browser directly.

As most of my projects rely heavily on execution speed, do you think I should learn C++.

Back in the days, there are debate all over the web which is better languages between Java and C++. It seems Java prevails most of the debates. I choose Java then and then choose to ignored C as necessary language.

The applicable languages in the article aren't include Java. I begin to regret my decision now.

Fortunately, later in the days I found that JavaScript can do almost anything that Java can. So I ditch Java and devoted myself to JavaScript.

This article brings me both sad and exciting at the same time. It's glad to see that the web app is going to be much faster. Then there's the disappointment part: it comes with something that I have no skill.

So I'd like your opinion whether should I learn C++ or something or stick with JavaScript.

Any opinions (positive, negative, neutral) are welcomed. I want to gather information as much as possible.

Thanks,

 

1) It's ignorant bullshit that they even CALL it "assembly"; almost as insulting as calling bytecode interpreters "virtual machines". MORE so when the top level language is a C flavor given that despite the DECADES of lies, the last time C was anywhere near how assembly worked was when it was only used on DEC mainframes.

It's almost as stupid as the halfwits who call base64 or XML "native formats"; said people being yet another of those groups I keep saying don't know enough to be flapping their gums on the subject.

2) Laugh is if they integrated it into websites using the PROPER mechanism -- the OBJECT tag -- we could have a native plugin lickety split. Naturally that's probably NOT in the gameplan since they're either going to use the redundant SCRIPT tag, or create all new tags like the dumbass redundant VIDEO and AUDIO. Naturally this would also leave implementation almost entirely in the hands of browser makers leading to the same cross-browser headaches we've spent decades struggling against. Joe forbid we ACTUALLY fight vendor lock-in or use the part of the specification MEANT for adding extensions to browsers any more than expecting that part of the specification to be improved.

3) OF course if you could just make it a plugin, we wouldn't need a polyfill; and I'm HIGHLY skeptical that any polyfill is going to be anything more than a fat bloated slow train-wreck.

You mention the cross language woes -- honestly I don't know if I've been at it to long, but to me Java, JavaScript, PHP -- they're all just C in a frilly dress. They're all C syntax languages so most of the good practices should remain the same. Moving to a true C or C++ will have the hurdle of getting used to typed variables -- that's NOT necessarily a bad thing... you also have the concept of pointers and I can see a LOT of web developers having difficulty jumping that hurdle.

But really it's all just window dressing since it's all C derivative. It's the same dance, just a different tune. If you already know Java or JS, C shouldn't be a great big wall; you already have ~80% the skills and almost all of the syntax down!

What I'd love to see? A Modula or Pascal compiler that could target said bytecode. As it is FPC can now target JVM, wouldn't be surprised if in a few years they added this to it's list of possible output formats.

A bytecode standard to which multiple languages could target client side (or even server side) is certainly a step forward for web technologies -- honestly it's something JS should have been from day one. I take more issue with the naming conventions and how they plan on implementing it than I do the actual concept.

 

Thanks for helping me better understand the topic.

1. So, according to you the fastest computer language out there is assembly. And those people gonna run assembly in the browsers?

2. You mean that thing which they called "WebAssembly" will be come in as plugin or something. This reminds of flash and hello the dead master "Java Applet".

I read this post of Brendan Eich the JavaScript inventor: https://brendaneich.com/2015/06/from-asm-js-to-webassembly/
I'm not sure what is he taking about because I'm not fully understand but it looks like WebAssembly is something going to live in the browser. I'm not sure if I'm right.

I'll follow this "WebAssembly" thing to the edge to the universe because it's seemed to be the only thing that will help me get things I struggle to achieve.

Thanks for giving an idea about C / C++. I'll have C compiler on my machine and start to print out the "Hello World!" message.

On the side note: I'm not that good at PHP, Java. Just an average Joe, but I consider myself (very good at JavaScript) ? sure : not;

And I never learn HTML and CSS, just know them by instinct.

That's all the assets I've got.

 

Not even CLOSE to what I'm saying. They are incorrect in calling it assembly as it's a intermediate bytecode that will be just in time compiled to machine language. BECAUSE it's a bytecode that is NOT processor specific it is NOT assembly language; not even CLOSE. It is simply a compiled language with a just in time compiler, so it will NEVER reach the actual speed of true optimized assembly.

They should just call it a compiled language -- but they're trying to use the marketing technique of "transfer" to dupe people who don't know any better into THINKING it's going to deliver that. It WILL NOT be as fast as real assembly language, EVER -- it has the potential to be as fast as a real C/C++ compiler. Compiled languages ARE turned into machine language, which is what this will do -- the difference between that machine language and the ML created by assemblers is that it's often grossly inefficient and nowhere NEAR the speed of using an ACTUAL assembly language.

Much of that stemming from the fact that no two processor families even use the same opcodes, registers, memory interfaces, so they aren't binary compatible... hence why you need an emulator to run x86 code on power or vice-versa, or an ARM can't run x86 binaries, or i64 can't run x64 or power or arm binaries. Processor families are NOT compatible, do NOT do things in the same way -- which is why high level languages like C were born. (Yes, I'm so old school I call C a high level language). They're an abstraction that can compile to different processor targets, but in doing so are less efficient than code ACTUALLY written to said targets PROPERLY.

What I said is that's how they SHOULD do it. I do NOT believe that's how they are going about it as the existing "asm.js" ignorant halfwit nonsense (not a fan) is a bloated slow script that simply interprets a bytecode into javascript delivered via scripting. It too using the term "ASM" is marketing buzzword BS that has NOTHING to do with how it actually works.

I'd REALLY suggest putting some effort there first. SO much of the stuff people dive for "web languages" like JavaScript, Flash or Java to do HTML and CSS can do WITHOUT the scripttardery. It's why I'+m always ranting and raving about "JavaScript for NOTHING" as, well.... There's a reason I keep saying:

The latter two probably applying to around 80% of what people do in JavaScript WITHOUT frameworks. From the idiotic halfwit BS of the mm_swap script Dreamweaver dupes the nubes into using, to bootcrap's scripttardery to do CSS's job, to people using scripting to force layout behaviors... It's all using JavaScript to do shit that's either HTML+CSS' job or doesn't belong on a website in the first place.

.. and that's my worry with "webAssembly" -- it's just another tool for people who already have no clue what semantics or accessibility are to just piss all over websites with.

That they have the giant set of monkey brass to call it "assembly" is just adding insult to injury; again that's as stupid and ignorant as the dipshits who call base64 efficient or XML a "machine native format".

As someone who started out programming on a Cosmac Elf hand assembling my own machine language to enter it 8 bits at a time on toggle switches, and who is STILL writing 8088 and 6502 assembly language in NASM and CA64 respectively, I know what Assembly and Machine language is. This "webAssembly" crap? Ain't it!

 

Thanks for helping me understand WebAssembly better.

This thing caught my interest ever since I came across it (3 days ago--exactly, that's when it announced). I'll keep an eye on the development of the language and altogether honing my skill towards it. I'm taking note about your worry over "webAssembly" though.

Thanks for the tips on HTML and CSS. I've learnt so much from you and the people over here, not all of my resources

Really appreciated,

On the side note:

You must have been very serious coder, if not crazy, to still writing in assembly language. Wow! That's wow! I admire people like you.

 

Holy Chocolate Coca Banana!

They already have wasm for node.js: https://www.npmjs.com/package/wasm

Now I have the resources to experiment with.