I love how WASM is the thing that finally blurred the line between Web and Native programming, formely two realms isolated from each other for a long time. This both develops better awareness of how the code is executed by the hardware, which JavaScript devs often lack, and also brings skilled folks from the Native platforms who seem to be not so against WASM as they were against JavaScript (and all other parts of the Web, really). Maybe this will bear fruit in that people will make more Native user interfaces again.
I wanted to love it. As someone who hasn't done any web stuff since I was a child, I thought it'd amazing for it to be "just another platform".
I'm a bit disappointed though:
* There's still no way to do DOM manipulation. So then it's tempting to just grab a canvas and draw everything yourself, which of course wreaks on things like accessibility. I'm no fan of the web, but at least it comes with a somewhat agreed-upon way to display graphical stuff – it's a bit of a shame if we're all gonna just treat it like a surface for pixels.
* WASI still leaves something to be desired. Why can't I have raw sockets and file access and stuff, in a POSIX-like way? I understand that sandboxing is important, so this can all be on a per-request-basis, but still. This "just another platform" is still too far from just that.
* The amount of JS glue needed to actually load WASM stuff in the browser is annoying. The idea of needing a bunch of magic "bundlers" is sad.
Using WASM to make cross-platform code run in browsers isn't any more weird/esoteric than targeting Android via the Android NDK. The least painful way is to do some things in the 'native' platform language (e.g. Javascript or Java/Kotlin). Emscripten's FFI features for calling out into Javascript code snippets (even JS snippets that are directly embedded in C/C++ source files) is actually really nice, much better than any other FFI solution I've seen so far (and light years ahead of anything offered by the Android NDK).
In the end the web is just another platform, but a platform that is quite a bit different from the UNIX/Windows duopoly we're used to.
You can call JS in which you can manipulate the DOM.
Of course architecturally (also regarding your file access) it's better to use the wasm for logic as much as possible where the web (HTML/JS) provides the UI and IO, data flows into wasm for work and results flow back to the web.
This also has the benefit that you can keep your original C/C++ source code much more platform agnostic which helps reusability and testing.
> You can call JS in which you can manipulate the DOM.
Well sure. But for me, the promise of WASM was to make the browser "just another platform". Now it's "this special platform where you have to access some of the most important functionality through FFI interop with a very high-level, very opinionated language".
> Of course architecturally (also regarding your file access) it's better to use the wasm for logic as much as possible where the web (HTML/JS) provides the UI and IO, data flows into wasm for work and results flow back to the web.
OK, but like, I wanted the browser to be "just another platform". I don't want to use JS, and I consider HTML orthogonal to my logic. I realize that's not where we're at, but that's what I dreamt of. Hence my disappointment. Which is OK, I don't matter :)
> This also has the benefit that you can keep your original C/C++ source code much more platform agnostic which helps reusability and testing.
Hmm well I guess I don't quite get what counts as "just another platform." Surely every platform is going to have the native APIs that you need to abstract over. Why is WASM different?
Is it just a matter of WASM being too new to have full featured wrappers and APIs for your language of choice?
Yeah it's like how if you want a cross-platform UI in C, you kinda need to use something like SDL that abstracts away the platform specifics. Even then might be hard for everything to work.
Web is "just another platform" with its own specifics, and the advantage is multiple OSes can run that platform pretty much the same way.
JS in the web context is what C or assembly is in the native context: something you have to use, because it's the foundation the platform is built on, and every language needs a way to interact with it, and good languages support it inline when you need it.
If enough people adopt identical or similar js glue then they can use that for a new standard. If people dont care about a standard interface then why both creaing a new standard? Look what happened with jquery selectors and ajax. People loved it and it became the new standard built into browsers.
FWIW, the various Rust react-like libraries (Yew, Dioxus, Leptos) are all reasonably fast for many/most applications. Even if the DOM goes through a JS interpreted layer.
Something akin to raw sockets over a host interface (or WSS bridge) could be cool... similar for sandboxed FS access, which browsers are starting to improve upon.
Yes, fully WASI/WASM would be nicer than some of the JS glue... but it's still useful all the same.
> WASI still leaves something to be desired. Why can't I have raw sockets and file access and stuff, in a POSIX-like way?
FWIW, that's exactly what they shipped first, with WASI preview 1 (wasip1). You can still use this today, and all runtimes with any level of WASI support will be able to run it.
Wasip1 did not specify sockets. Some implementations have made non-standard additions to add them, but sockets were not added to the standard until wasip2.
There's no way to draw on a canvas in WASM either. You just decided to write JS wrapper functions for that. But you didn't write wrapper functions for DOM manipulation.
Besides ActiveX, old (<9) Internet Explorer supported VML (Vector Markup Language), which was neither supported by anything else, nor widespread. It could be made dynamic with the help of JavaScript, and the only dynamic example I could remember was an analog clock.
Saying ActiveX here shows a fundamental misunderstanding of what both WASM and ActiveX are.
Is ActiveX platform independent? No. it's exclusive to windows. Is it sandboxed? Nope, digital signing and prayer, does it implement a virtual machine? Nope. Compromises out the wazoo? efficiency, data orientation, or predictable performance? You betcha. ActiveX is closer to a DOM sandbox escape exploit than a real piece of engineering. Why do we need WASM when we've have GET since 1990?
Don't confuse the map for the territory, implementation details matter, just labeling something "Mars Colonial Transporter" doesn't mean it actually flew to mars.
Wasm still doesn't let you make native user interfaces, the UI is in the web browser. You can put native UI components into a React Native or Electron app though.
> Wasm still doesn't let you make native user interfaces
That's currently only not possible because nobody wants to do the work to create something like wasi-gfx (https://wasi-gfx.dev/), but for native UI frameworks instead of 3D APIs.
The inconvenient truth is that even "native" cross-platform applications hardly ever go through the trouble to target the platform-native UI framework (and instead they go through non-native frameworks like Qt or a webview wrapper).
For that matter, there's so much diversity in actual rendering anymore, very few apps on any platform are really native feeling. Especially with a few electron apps in the mix.
Would be cool to get some standardization on at least a few APIs for default fonts, light/dark mode, background and accent colors, etc... so that apps are a little less alien in practice. I'm really not even the idea of Tauri or similar to use a native browser engine, but better skinning APIs so you can get something like Material, but tuned to better match the desktop you're on.
For that matter, a wasi component package would be nice as well. Harder for accessibility though.
I meant, in-browser wasm can't do native things like creating a blank non-browser window on my Mac like a Swift app could, no matter what libraries it uses.
I can't help but notice that this, in effect, establishes collaboration between EU and Russian devs over a common open-source office suite, because both projects can easily copy future changes from each other. The irony is staggering, given the war and the public rhetoric.
Yes, but they can't do anything about it anyway. The FSF resolution on this matter, though, essentially means that they might just as well pull Euro-Office patches into OnlyOffice. So in the end, the product will be formed by combined effort.
The codebase will diverge quickly; the Russian one is heavily obfuscated with s ton of Russian in it and obscure commit messages. A large portion of prep work by Nextcloud was cleaning and translating. OnlyOffice was also known for refusing PRs, too.
> Pursuant to Section 7 of AGPLv3, the copyright holder is expressly entitled to impose additional conditions. In the case of ONLYOFFICE, such conditions include, in particular:
>the obligation to retain the original product logo (Section 7(b));
>the denial of any rights to use the copyright holder’s trademarks (Section 7(e)).
In other words you must use our logo and you must not use our logo. Good luck enforcing that.
War is between governments. A bad actor might as well lie that they're not Russian. If anything this is a good thing. Lets not make war define who we work with
Hard disagree. The war has been at least tacitly supported by the majority of the Russian public (via enlistment, taxation or just acquiescence) and it's very explicitly being waged against the Ukrainian public (via killing, occupation, expropriation etc).
"Define who we work with" is basically the point of sanctions. Unless you think they're too robust too, and we should limit ourselves to strongly worded postcards?
Wait how does it establish collaboration? Because its opensource so anyone can copy the source code? If so, thats a pretty weak, and disengenuous argument. Is the US collaborating with russia because russians can use the internet and darpa funded its initial RnD?
Euro-Office codebase will, obviously, not diverge significantly from the original product. If they planned fundamental changes, they would have started from scratch because taking over a huge project and rewriting its basis is an ever more daunting undertaking.
As such, any future patches to both codebases should be trivial to copy from one another, which essentially makes it collaboration.
It's quite frightening to see how an enormous 120KLOC pull request gets merged at once with very little public discussion or coverage by the devs after just 3 months (which IMO is very little time in relation to the amount of code). There used to be extensive RFCs and series of conference talks long preceding changes this big, e.g. React Fiber.
I support wholeheartedly the move to AOT-compiled languages but it looks like paying off the cognitive debt is going to be brutal on whichever team gets to maintain it in the long run.
Seems like all the "best practices" that were preached from these engineers for years are just disregarded and thrown out of the window with this reckless use of LLMs on high profile project.
Just creating permanent cognitive debt for everyone else with no-one else understanding what the code is doing.
The cognitive debt is by design. Now everyone must use an LLM to maintain the codebase, because it's beyond any single human's capacity for understanding.
Part of the problem is that of human alienation. By excluding humans in the construction process, it has taken away any skin-in-the-game for humans. So, there could be a point where some bugs become unresolvable because LLMs dont have an adequate causal model and fixes by trial-and-error wont work in cases where root-causes are not properly addressed - and the project gets abandoned as a result. Witness the C compiler in rust [1], what happened to that after the initial press releases ?
This has been the case with IDEs as well. The most productive programmers have always delivered despite the tools they are forced to use not because of them. The less productive programs fail to learn because they are handheld by tooling.
Nevertheless, it's also React team that came up with prefixes like __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED in their codebase because people couldn't stop messing with the internals. So any documentation about the new compiler would be anything but rejected by the community.
> Coding language is just an implementation detail
Sure, but what machine model do the public contract docs and RFCs target ? While the specific coding language is a detail, programming languages target a precise machine model. There is no machine model for english prompts and spec docs. So expect fuzziness - he-said-she-said bugs in your code - things that the LLM made up because the RFCs were not precise. And by the time you add precision to the specs, it has morphed into a new programming language with a machine model. In this usecase, since it is a port, the impact is mitigated because it is a clone of some existing functionality.
i feel like ppl have magical beliefs about type systems. just because it's _probably_ (did it use unsafe?) memory-safe doesn't mean it does what you want it to do
That's obviously true. On the other hand its also true this is more likely to work because it is rust compared to python or js for example. And that's not only because of memory safety. It's because static typing gives an automatic proof of a certain level of correctness of the code. That correctness is correlated with correct business logic bugs. So it is valid argument to make.
Of course that doesn't mean that there are no businesses logic bugs.
char* is an exception to strict aliasing rules of C++ precisely to facilitate the author's use case. You would still need a reinterpret_cast to make it work, but it's actually good because it makes the intent clearer, and the cast would have still happened either way to read the raw bytes.
... then it would be a different matter since maybe you want to allow src and dst to alias. Although, even then, they're still allowed to alias so long as the function accesses them both through char*, so the function signature can still use void*.
(Going deeper, non-strict aliasing applies to any pointers of the same type passed to a function. So if src and dst were both cast to float* inside the function, and if they really are both of that type (technically "an object of type float exists at the pointed-to location) then they can still alias. The char* exception is the only case that you can access a memory location through two different types of pointer and they can still alias.)
It's interesting the author mentions uint8_t. It's certainly more explicit than char, but it doesn't have the same aliasing guarantee (very strictly speaking - in practice it's almost always an alias for unsigned char or char, which does).
This is actually pretty annoying in embedded programming in C, because you'd often really prefer to use a uint8_t buffer[] for serialization functions (e.g. to write arbitrary data on some bus etc.) over char*, but you'd actually lose the aliasing permissiveness that you need (if you are strictly sticking to the standard-- this is often ignored in practice).
There is also an independent open-source interpreter for 1C language (which is to this day reported to be extensively used in Russian enterprise) implemented in C#. I haven't tried it myself, but just though that it's also worth mentioning here as the project seems to be actively worked on:
https://github.com/evilbeaver/onescript
> std::string_view or std::span should be used instead
That is for when the owner is a std::string or an owning range respectively. But a raw pointer does still make sense as a non-owning view over a single element, doesn't it? I'm new to C++ so I might be wrong.
Why does any mention of C++ nowadays turn into a Rust debate? These can coexist even in a single project via C ABI. Also, despite the vast syntax and semantic differences, an experienced dev will be able to apply most of their knowledge from one to the other.
It's because crowing about Rust is like sending dick pics. I suspect it's the same part of the brain responsible with the same neural pathways stimulated.
First - the tool in question had not been replaced. Second -discussion based on merits is one thing. Holy war is something totally different.
Personally I do not consider Rust to be a better tool but it does not matter. Each one is free to drink their own poison. I do not get obsessed about screwdrivers and I have used many.
You have written a glib and low effort reply to anything that disagrees with your Rust-maximal worldview. The sheer immaturity of Rust devs is enough to put me off the language.
That's actually a common pattern and to me that's a bit off-putting as well.
I have seen examples where some opinion gets momentum and it's repeated over and over again on the Internet even though the merit is very questionable.
Haven't looked enough into Rust to form an opinion though.
Since you are already making use of LLMs, you could also ask questions about the code that it produces. I've been asking Google's AI overview and Deepseek while doing my first ever C++26 project, usually not to produce any code but to give advice or list possible approaches to implementing a feature. It's a very slow path, to the point that my project has currently more git commits than lines of code, but I'm convinced that it will pay off in the long run.
reply