7 ms·
What I think is the takeaway from this is that there is a real need for a platform-agnostic application layer above the native OS. It's a peculiarity of history
by Nihilartikel 7y ago
What I think is the takeaway from this is that there is a real need for a platform-agnostic application layer above the native OS. It's a peculiarity of history that HTML evolved into it, and not Java, Flash, Silverlight, Adobe Air, etc.. Probably because the timing was right for applications to exist at least partially remotely.
It's fun to dream about a more deliberate replacement, with the same local/remote transparency of a web app, but with well thought out abstractions for local hardware and permissions.. Like, binaries are LLVM IR, Jit'd to the local architecture. Audio is openAL, graphics are Vulkan, local devices are [no-current-equivalent-standard-API], with fine grained security on all features.
It could be run locally, or with resources streamed over network. Opening an application could just be a 'URL'..
A little like a progressive web app, but not a weird outgrowth of an old page layout standard.
- admax88q 7y agoCould also just bring back applets. Its what the web is doing already, slowly reinventing applets but worse.
- shadowgovt 7y agoI don't think I'd call it worse. The original implementation treated the DOM as, at most, an undesired wrapper environment and mandated Java as its implementation architecture. I think wasm's approach improves on both those issues.
- Datenstrom 7y ago> there is a real need for a platform-agnostic application layer above the native OS. It is rather focused on robotics but that is essentially what the Robotic Operating System (ROS)[1] is, although it is less for users and more for autonomous systems. It allows an operating system to be distributed across many machines and multiple entities to collaborate. There are many extensions available but ROS core is just the bare minimum abstractions needed to have a distributed operating system to build applications on. [1]: https://www.ros.org/about-ros/ https://www.ros.org/about-ros/
- dbcurtis 7y agoROS is a publish/subscribe framework for distributed computing. It can’t really solve this problem. Heck, it barely solves the robotics problem.
- ragebol 7y agoI don't see how ROS solves 'a real need for a platform-agnostic application layer above the native OS.' It's not platform agnostic (works best with Ubuntu Linux) and is hardly a layer above the native OS, just applications communicating via standardized means.
- Datenstrom 7y ago> It's not platform agnostic ROS2 supports Windows, OS X, and Linux. I expect the support will only get better as ROS2 matures. > just applications communicating via standardized means I can't imagine any way to make such a system work without some kind of middleware for applications which gladly is DDS now for ROS2.
- zozbot234 7y ago> Like, binaries are LLVM IR, Jit'd to the local architecture. LLVM IR is not platform independent, it's really just a bunch of (closely-related, ofc.) platform-specific IR's. What's wrong with WASM? Everything else seems broadly OK, of course. (Also, WASM directly supports "applets", via Canvas.)
- Nihilartikel 7y agoThen something like WASM, but avoiding the 1.5x or so slowdown over native. Perhaps WASM is the answer, but with improved runtime. What I'm driving at is - if we can dream, why not aim for maximal hardware performance and minimal overhead? Even if it comes down to just pre-compiling native code for common architectures like Android apps do. Right now, the browser is an idiosyncratic HAL burdened by its past... what would a really nice next generation be? Interesting thing to know about the LLVM IR - I'm only casually familiar.
- pfraze 7y agoWasm comes to mind for a new browser arch because in theory it could be a userland replacement for traditional platform features like the UI. You could have a wasm module for HTML, for instance, which could be chosen for legacy sites, but replaced for a different approach (VR UI, cloud service which doesnt need one, etc). This would help minimize the browser core and make the execution environments swappable and reusable across browser cores. That said, I agree that performance may be a dealbreaker on that idea. HTML/DOM is also tightly integrated into a lot of browser behaviors, so I have no idea whether it's feasible to extract it into a swappable module. EDIT: It's still an idea that gets me pretty excited to try.
- jhoechtl 7y ago> Then something like WASM, but avoiding the 1.5x or so slowdown over native. Perhaps WASM is the answer, but with improved runtime. Once we are done with WASM we will look at it, compare it with Java Applets and say: Look, we already had that!
- 7y ago
- coldpie 7y agoI suspect what will doom any such project is that it won't be designed for the primary usecase that made HTML/JS succeed: teenagers with nothing more than Notepad.exe and a search engine. It will be made super elegant and efficient and no one will use it because it will take more than three lines to make text appear, and a typo will result in a bunch of errors. HTML/JS are garbage languages and web standards are cobbled together trash, but their strength is in their utter simplicity and in how forgiving browsers are in interpreting them. If you don't have that, you've already lost.
- duxup 7y agoYeah the barrier to entry with HTML/JS is so low for anyone to make a thing that the whole world can see and frankly ... that's kinda awesome. From there you can just be a simple site or scale up to some really impressive applications with a TON of free resources available on the internet. That's pretty amazing IMO. As a webdev who has been dipping my toes into C#... I fire up a new command line application in VS and the fans on my laptop take off and there's just a lot of boilerplate ... come on man.
- 72deluxe 7y agoBut your C# application is debuggable, unlike those "impressive applications" written in JavaScript with thousands of async callbacks so you have no idea where the originating problematic call came from in your minified JavaScript, and even if you find it you still have to deal with the minified code that is unreadable. What boilerplate are you talking about in C#? If you think that's bad, you should try something like C++ (although it's got far better in recent years), and I say this as a fan of C++. C# is compiled, JavaScript is not. Your C# application will involve high CPU to compile ONCE but forevermore require half the resources of interpreted JavaScript in webpages, which need to be interpreted again and again and again. This is an issue that is worth bearing in mind for energy usage, and has a significant impact on our future if we just defer to "easy to write, expensive to run" web languages. I'd say C# is easier to write than JavaScript and is easier to debug for the most part.
- 7y ago
- dasil003 7y agoThe difference with those other platforms is that they were all still single vendor with no open standard behind them. I’m skeptical of the ability to create a new system because the surface area is so large that you need the massive resourcing of large corporations, but those companies will not willingly create new open standards that would put others on equal footing, at least not in today’s economic culture.
- Nihilartikel 7y agoI don't disagree. It would take a concerted shared will in an industry that still views, perhaps rightly, platform lock-in as a competitive advantage. Open source initiatives are great, but I feel that they're weaker than a bigcorp (benevolent?) dictatorship would be at picking a direction and moving in it. When the headline comes out that DirectX13 will be a layer on top of Vulkan, then maybe it's a sign that the world is ready :)
- LargoLasskhyfv 7y agoResurrect https://en.wikipedia.org/wiki/Architecture_Neutral_Distribution_Format https://en.wikipedia.org/wiki/Architecture_Neutral_Distribut... from 1989.
- dblohm7 7y ago> Like, binaries are LLVM IR, Jit'd to the local architecture. You've basically described WASM, sans the LLVM part.
- devit 7y agoThe web is essentially becoming what you propose, with WebAssembly binaries, WebGPU graphics, WebAudio API. Currently you need an HTML and JavaScript shim to use those, but it's easy to remove it and execute WebAssembly directly.
- kevin_thibedeau 7y agoWe can call it Qt5.