Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hello wasm-pack

hacks.mozilla.org

Post reply on HN
Print view View original

41–50 of 160 posts

Re: Hello wasm-pack

#41

Post by lowtolerance »

Mononokay wrote: post #10
vijaybritto wrote: post #5

Earlier quoted context omitted.

You are living in the past tbh. There are tools which make augment the language and it is literally taking over the world now!

It focuses on the lowest common denominator of programmers, and in general the community around it doesn't really care to optimize it or teach the people they attract towards good programming standards.

This is simply not true. There are plenty of beginner-level JavaScript tutorials and resources out there, but the same could be said of any language. JavaScript libraries du jour like React and Angular are certainly not aimed at beginners, nor are popular tools of the trade such as Webpack and Babel. The focus is on allowing experienced developers to create production-ready web applications, which is exactly where it ought to be.

I’ve been programming in JavaScript for nearly 15 years now, though, and there has been a near-constant push from the community toward better programming practices during that time. Given how far the language has come just in the past 5 years, I’d say they’ve been pretty successful in that regard.

Re: Hello wasm-pack

#42

Post by Mononokay »

dvfjsdhgfv wrote: post #35
Mononokay wrote: post #9

Earlier quoted context omitted.

It's not a bad language in itself, no - it's just a waste of resources for the end-user, and in general it's being marketed to newcomers as the language they should learn by default - leading to a tonne of unoptimized sites and terrible applications using it. Then again, I suppose that's a fault of the type of programmers attracted to it than it is the language itself.

> it's just a waste of resources for the end-user Frankly, it's not a problem of the language, but the browser. As far as I can tell, none of the popular browsers offer a way to limit resource usage, even though users would clearly benefit from it.

That actually would be a productive way of solving the problem, if limitedly. That'd make me fall much more into the neutral camp on it.

Re: Hello wasm-pack

#43

Post by coldtea »

yougane wrote: post #33
wvenable wrote: post #19

Earlier quoted context omitted.

The original Blazer was based on the DotNetAnywhere runtime and the binary size was actually very reasonable. Now that they're using the Mono runtime it's significantly larger and it seems their main task now is finding ways to remove unused code from that runtime to get it back to reasonable.

The original runtime was about 60kb in size, that's still unreasonable to add to a library. Imagine a small library like Redux (2kb, including dependencies) having to ship with a runtime that's 60kb (or more). Now imagine a project that depends on multiple libraries of the same size or larger... This is why a language that has no runtime (such as Rust) makes more sense for developing wasm packages that can be used si…

>The original runtime was about 60kb in size, that's still unreasonable to add to a library.

In which planet? Not only will most frameworks and standard JS libs dwarf this, but the average web page size has upped to ~ 3MB these days...

Re: Hello wasm-pack

#44

Post by jchw »

plurgid wrote: post #34
alex_duf wrote: post #15

I'm dreaming of seeing a wasm DOM api that directly binds to the browser's apis, without passing through javascript. Is this even a possibility?

when we can make web pages, and entire sites without once actually using something a human can disassemble and reverse engineer ... this will be the end of the open web. truly the complete dead end of it. Unless maybe I'm missing something. Is a disassembler for WASM a thing yet?

I've tried to read source code from YouTube and let me tell you:

If that kills it, it was already dead. Obfuscation and minification is already as bad as bytecode. Honestly, wasm might be a little better because there are less insane hacks and more simple, if low level, code.

Also, if people are willing to implement DRM in it just because it's bytecode, I'd rather they did that than implemented rootkits in all of the browsers. Thanks for that one W3C.

Re: Hello wasm-pack

#45

Post by api »

alex_duf wrote: post #15

I'm dreaming of seeing a wasm DOM api that directly binds to the browser's apis, without passing through javascript. Is this even a possibility?

It's proposed but it's also already possible if you use a very thin JS glue layer.

Re: Hello wasm-pack

#46

Post by tzahola »

vijaybritto wrote: post #5
Mononokay wrote: post #3

> As Lin Clark emphasizes in her article about Rust and WebAssembly: the goal of WebAssembly is not to replace JavaScript, but to be an awesome tool to use with JavaScript. Please no. JavaScript's a bit cancerous - we should be erring away from it rather than encouraging it.

You are living in the past tbh. There are tools which make augment the language and it is literally taking over the world now!

Meh. JavaScript is literally the PHP of programming language...

Re: Hello wasm-pack

#47

Post by api »

plurgid wrote: post #34
alex_duf wrote: post #15

I'm dreaming of seeing a wasm DOM api that directly binds to the browser's apis, without passing through javascript. Is this even a possibility?

when we can make web pages, and entire sites without once actually using something a human can disassemble and reverse engineer ... this will be the end of the open web. truly the complete dead end of it. Unless maybe I'm missing something. Is a disassembler for WASM a thing yet?

Webpacked and possibly optimized/minified JavaScript is basically the same thing as compiled code. We are already there.

Re: Hello wasm-pack

#48

Post by api »

themihai wrote: post #11

>> the goal of WebAssembly is not to replace JavaScript, but to be an awesome tool to use with JavaScript. Let's hope exactly the other way around will happen. I would rather like to see better interop between different languages using wasm than wasm + js.

Yes, that was my thought too and I was disappointed to see them defending JS at the top of the article. Getting away from dynamic language mush is one of the biggest attractions I have to WASM.

Re: Hello wasm-pack

#49

Post by Rusky »

jnordwick wrote: post #28

I'm kind of curious how wasm is going to work out. It seems only logical that wasm interpreters will be optimizing JITs. Wasm will essentially be an intermediate language similar to JVM bytecode. At that point why not just use the JVM stripped of the useless stuff as a base and add the remaining small pieces that might be needed. Or Graal. I guess I don't understand what Wasm is doing that is so much different that c…

> It seems only logical that wasm interpreters will be optimizing JITs.

Webassembly was designed not to do this, and I really hope it stays that way forever. Optimizing JITs are useful for highly dynamic languages like Javascript; Webassembly's fast startup times and predictable performance are a much better solution for languages like Rust.

> I guess I don't understand what Wasm is doing that is so much different that couldn't be handled with other more advanced code bases.

On top of "the vast majority of the optimization is done ahead of time so there's no need for a JIT," there's also the memory model. Webassembly exposes memory as a big array of bytes for you to manage yourself, just like hardware. The JVM enforces a particular object model with classes, inheritance, and garbage collection.

So I guess what I'm saying is that "the JVM stripped of all the useless stuff" is what Webassembly is already. And some of the stuff that got stripped is the JIT and object model.

Re: Hello wasm-pack

#50

Post by Touche »

api wrote: post #48
themihai wrote: post #11

>> the goal of WebAssembly is not to replace JavaScript, but to be an awesome tool to use with JavaScript. Let's hope exactly the other way around will happen. I would rather like to see better interop between different languages using wasm than wasm + js.

Yes, that was my thought too and I was disappointed to see them defending JS at the top of the article. Getting away from dynamic language mush is one of the biggest attractions I have to WASM.

You already got that from asm.js though.
Post reply on HN