181–190 of 248 posts
Earlier quoted context omitted.
What would you prefer then, Lua, with its 1-based arrays? Python is a mature, universal, versatile, insanely popular dynamic language with a nice syntax. It fits the bill perfectly.
Something with a static/strong type system.
Earlier quoted context omitted.
WASM is angling to break out of the web and become a cross-platform runtime. Its main competition for this space is Java.
Without defining a standard set of abstractions around operating system resources it is pretty far from competitive with Java and more closely related to something like LLVM bitcode.
That part is called WASI.
Earlier quoted context omitted.
No, you don't. If you export functions to WebAssembly, any language that can run in WebAssembly can call those functions. And if you define WebAssembly Interface Types for your exported functions (note: still in development), any language that handles interface types can automatically handle things like "how does this language represent a string safely". Either way, you don't need to define a new API for every langua…
What you are describing is more like __asm__("") in C, not an interface for application developers. Those are still required for every single target language because of the mismatch between the levels of abstractions between those languages, webassembly and actual logic exported.
Interface Types are the mechanism for handling the different abstractions in different languages without having to write language-specific interfaces.
WebAssembly prior to Interface Types is more akin to an exported C function than to inline assembly. That already gives you enough for many kinds of interfaces, most notably the common pattern of obtaining an opaque handle and calling functions on that handle.
WebAssembly with Inteface Types gives you everything needed for high-level interfaces in any language. That lets you define strings, buffers, handles, arbitrary structured types, and pretty much anything you'd expect of a high-level interface.
Earlier quoted context omitted.
Honest question, in what sense is python a so much better choice for web development? syntax? subjective, and it would also mean all C-likes belong in the dustbin. performance? Why would python, as a language, be significantly more performant? It's just as dynamic. ecosystem? JS community is huge, JS package managers are huge (even though not flawless, but nothing their python counterparts do better) I mean I can sur…
Was going to ask in the main thread but perhaps here is a better place. For someone just starting with programming, but targetting WASM, which would be a good first programming language? Java? In my particular case, I've been learning Python for Data Analysis for about one year, and a few months of Haskell (love Haskell so far, but my interest/job is related to data analysis and web dev). I've heard bad things about…
Personally I'd also avoid anything with a fatter runtime than maybe Go or C#. If it doesn't already, I'd expect C# and .net generally to have really good WASM support, actually. And even those, unless it becomes standard to ship their runtimes with a browser, you're talking about a pretty fat package to ship before the program can even start running.
Most interpreted languages (like Python) running on WASM will probably be notably slower than Javascript running outside WASM, for the reason that they'll have similar limitations on optimizability, will have had fewer person-years put into optimization than Javascript (which has seen tons of investment from e.g. Google), and will be running on an interpreter in the WASM VM rather than a C++ (or whatever) native interpreter. And they'll have the problem of needing to ship an interpreter, similar to the runtime problems for the languages above.
For the best experience you want something fast-loading and well-performing. That means small package size and not too deeply nested in terms of abstraction on top of WASM. If you want a better experience on both fronts than JS, which has the benefit of already having its interpreter bundled with the browser and running on a native, highly optimized interpreter—IOW if you want running on WASM to actually be a win in any meaningful UX way—you'll need to look at fairly low-level languages, I think. C++ is a good bet—people are quick to shit on it, but it remains hugely important in GUI application development—or, if you're wanting something hipper, Rust, perhaps. Go or .net-family languages might be OK, future-proof-ish choices if you don't mind sacrificing load time a bit. Toss Swift in that bucket too, I guess.
Earlier quoted context omitted.
> You could argue for an alternative to html/DOM - some kind of rendering format that is meant specifically for full-featured applications. Well, there are three ways to do that. You can use a 2D canvas, you can use a WebGL canvas, or you can use a bitmap canvas. This is roughly equivalent to what you get when you’re programming a desktop application anyway. This is a cornucopia of alternatives here! I’m having a har…
What is missing is a way for one's wasm code to make WebGL or 2D canvas calls (or even write directly into a bitmap canvas), without writing a bunch of Javascript trampoline / thunk / whatever code. If I'm mistaken, a pointer to some C / C++ / Rust code that compiles down to wasm that actually touches a canvas that's being displayed in the browser would be most appreciated.
Earlier quoted context omitted.
> because the DOM and JS (meaning the GC) are very coupled. This wasn't the intention when the script tag was introduced. It's interesting that the web standardized on one programming language.
It's interesting that the web standardized on one programming language. In hindsight I feel like this isn't surprising. How many platforms (that aren't themselves operating systems) support scripting in more than one language? Vim/Neovim is the only one I can think of off the top of my head.
Earlier quoted context omitted.
This is a generic argument that can be used against any sort of proposed improvement. “If you don’t like the status quo, use something else”. It also comes off as defensive; I’m not sure if that’s what you intended or not.
I don't think WASM is proposed as an improvement over either HTML or JS. It's proposed as an addition that fills out certain shortcomings for particular niches. WASM is not (currently) envisioned as the "new" way to write for the web, but as a handy capability to reach for if you need it.
Earlier quoted context omitted.
The GC spec has been stalled for a while with no clear path forward in sight (because the goals for WASM GC are incredibly hard to meet). DOM access will be possible through the interface-types extension [0], but no host supports it yet AFAIK. Also still a very tricky problem. [0] https://github.com/webassembly/interface-types
I’m not sure I understand the advantage of having a GC in WASM. I wouldn’t expect any languages to use it (because GCs tend to be tightly coupled to a particular language—for example, go’s GC requires careful coordination between the GC and the scheduler—and any sufficiently general GC would presumably give up too much performance). LLVM has an interface for GCs such that the host language can provide LLVM with infor…
Earlier quoted context omitted.
> because the DOM and JS (meaning the GC) are very coupled. This wasn't the intention when the script tag was introduced. It's interesting that the web standardized on one programming language.
What other languages do modern browsers support in the script tag?
But now, it's pretty much just JS.
Earlier quoted context omitted.
I don't think WASM is proposed as an improvement over either HTML or JS. It's proposed as an addition that fills out certain shortcomings for particular niches. WASM is not (currently) envisioned as the "new" way to write for the web, but as a handy capability to reach for if you need it.
I don't think anyone is suggesting that WASM is the new way to write for the web, but I think it's certainly an aspiration that WASM will allow more languages to be used for everyday web development in addition to solving other more niche problems.