It amuses me we're circle backing to have applets all over again.
This time we did it better, cheers.
That remains to be determined.
W3C recommends WebAssembly
171–180 of 350 posts
Re: W3C recommends WebAssembly
#172Earlier quoted context omitted.
Even if we don't lose the HTML-centered model, we are probably going to lose control of our browsers. Eventually somebody is going to ship a product that's nothing more than a browser implemented in WASM that runs inside your browser. The "inner browser" won't have content filtering, privacy controls, DOM inspector, or a Javascript debugger (for the Javascript engine running on the "inner browser") that you can inter…
This already happens. See Figma: https://www.figma.com/blog/webassembly-cut-figmas-load-time-... To be honest, it's a unique property of the web for you to be able to easily read the source; however, users of other platforms such as Qt are not expected to read the source. The web is simply moving in the direction of all other UI platforms, so I don't quite understand the outrage. Yes, it sucks, but it'll make apps fa…
[deleted]
Re: W3C recommends WebAssembly
#173Whatever you think about javascript, I love the historic separation between content and interactivity. I dislike that so many static pages won't load without JS and that we're moving further in that direction. I hope the evolution towards "browser as OS" doesn't hurt the content vs interactivity separation. Could we ever lose the HTML centered model? That could mean we lose hackability and the ability to write extens…
> Could we ever lose the HTML centered model? This is what people should be worried about, not replacing JS. It became a kind of popular hot-take for a while to say that separation of concerns was a mistake, and that's not how apps get built in the real world, and what we really need is a way to encapsulate all of our DOM and CSS in JS. We need to start pushing back against that idea and keep emphasizing that separat…
Frontend Engineer here. That “popular hot-take” is my career, and I happily combine HTML and CSS into my JS every day.
React.js has been the most significant JavaScript library in the past decade. Over 50% of JS developers on the web are writing HTML inside JavaScript. In recent years, CSS-in-JS libraries like Styled-components are becoming standard.
We’re killing HTML templates and writing JSX. We’re killing CSS classes and building styled-components. It’s all compiling to HTML, CSS and JS in the end. We just get to do our jobs faster. Why people have a problem with that is beyond me.
Re: W3C recommends WebAssembly
#174Earlier quoted context omitted.
But if the WASM was compiled from javascript or some other language that isn't very C-like then the de-compiled C or C++ code is going to be very difficult to follow. At the very least with obfuscated javascript you are going from js => js => js. Rather then from js => WASM => C++.
But going to c instead of js is an implentation technicality. If WASM becomes commonplace I'd be shocked if some group of kind souls doesn't open source a decompiler to minified js .
There already is a compiler from wasm to asm.js, so I assume it wouldn't be too difficult to go from wasm to more typical js.
Re: W3C recommends WebAssembly
#175Earlier quoted context omitted.
It’s a bad render target, and it’s only half the story. It’s html + css that’s the render target. Separation of concerns happens because the render target is a over complicated mess. So separate the good parts out of the mess as much as possible but the mess is still there.
95% of the time, if you can't represent your app state as pure text, you're overcomplicating your design and haven't thought enough about your UX. Of course HTML for interfaces is more complicated than something like canvas, because it forces you to think about your UX on a deeper level than "this component should be on the left". The point of HTML is that it forces you to build a universal interface that works for e…
>95% of the time, if you can't represent your app state as pure text, you're overcomplicating your design and haven't thought enough about your UX.
This is a design opinion. I disagree with it. Minimalism is simply a design philosophy just like brutalism or complexity. The underlying mechanisms should be design agnostic.
>HTML on its own is a render target. CSS is a completely optional secondary display modifier that you put on top of that render target.
Sort of like turing completeness, HTML on its own is not "render" complete. There are many objectives that cannot be achieved with HTML alone. You must consider aspects within and outside of your "design philosophy" as the modern browser is intended to be a universal platform for multimedia applications. This is why HTML alone cannot be the render target.
Render targets are usually more fundamental with libraries built on top for more specific use cases. It would be better if the web browser world had pixel level render targets with HTML built on top as a library. This is how most graphical APIs work. Rather then what is now, HTML as the render target, and canvas as a child object of HTML.
This maintains "render completeness" and gives users the ability to use higher level DSLs like HTML + CSS or to (switch to)/write another library.
>This is why adblockers work, it's why stuff like Reader View works in Firefox. Because it turns out that forcing interfaces to be pure-text has substantial benefits for end-users. Try building something like a UI-level adblocker for a native app. You can't do it -- it's impossible.
while this is true I wouldn't center the design of a platform on whether or not ad blockers work for it. It is not central to the problem which is the creation of a universal platform that is versatile. Rather it is the implementer of the adblocker who must conform to the platform.
Re: W3C recommends WebAssembly
#176Hopefully this also means that Javascript is going away for good
It's not the end of JavaScript. It's the end of every language that "compiles to" JavaScript.
Re: W3C recommends WebAssembly
#177Earlier quoted context omitted.
But going to c instead of js is an implentation technicality. If WASM becomes commonplace I'd be shocked if some group of kind souls doesn't open source a decompiler to minified js .
There already is a compiler from wasm to asm.js, so I assume it wouldn't be too difficult to go from wasm to more typical js.
Good to know!
Re: W3C recommends WebAssembly
#178Whatever you think about javascript, I love the historic separation between content and interactivity. I dislike that so many static pages won't load without JS and that we're moving further in that direction. I hope the evolution towards "browser as OS" doesn't hurt the content vs interactivity separation. Could we ever lose the HTML centered model? That could mean we lose hackability and the ability to write extens…
Even if we don't lose the HTML-centered model, we are probably going to lose control of our browsers. Eventually somebody is going to ship a product that's nothing more than a browser implemented in WASM that runs inside your browser. The "inner browser" won't have content filtering, privacy controls, DOM inspector, or a Javascript debugger (for the Javascript engine running on the "inner browser") that you can inter…
It makes no sense to me. You are saying, that instead a 5 kB webpage, you would load 50 MB code, which emulates a browser, just to show you the same webpage?
Every webpage pays for the traffic in some way, and everybody tries to save web traffic as much as possible (optimizing images, videos, minifying JS, CSS ...). It makes no sense to expect, that websites would turn the opposite way just for fun.
I would be very glad, if you can emulate a computer in a browser, so you can e.g. use VirtualBox or VMWare comfortably in your browser. Still, it will be sandboxed (it can not turn off your computer, or clear your hard drive, etc.).
I think the web is the most open, independent, secure and versatile platform today. And I hope it will become even better and more powerful in the future.
Re: W3C recommends WebAssembly
#179Does anyone have any good intro resources for WebAssembly for noobs? I've read articles here and there seen some in person demos, and honestly struggle to understand what it is / how it would / works relative to the current state of JavaScript frameworks. Often I'm approaching it from a JavaScript framework (React/Vue/Angular) approach as I'm a bit of a noob to the industry and that's generally my day job working on…
Just take a look at Blazor for education-by-example. It's a framework like React&friends, but in C#, running in the browser via wasm. Build a SPA in C# - as practical as you can get.
If I'm already proficient with React+JS, what's the benefit of this besides using other languages?
Re: W3C recommends WebAssembly
#180Whatever you think about javascript, I love the historic separation between content and interactivity. I dislike that so many static pages won't load without JS and that we're moving further in that direction. I hope the evolution towards "browser as OS" doesn't hurt the content vs interactivity separation. Could we ever lose the HTML centered model? That could mean we lose hackability and the ability to write extens…
Yes, I'm not sure what the future holds for HTML but I'm confident the ultimate goal of webassembly is to make the browser a secure place to run full native like apps. That suggests some apps will not use HTML and just render everything themselves There's some incentive to use HTML as it's indexable but it doesn't seem to be affecting mobile, although maybe mobile is in large part successful because of the web? Like…
>Yes, I'm not sure what the future holds for HTML but I'm confident the ultimate goal of webassembly is to make the browser a secure place to run full native like apps. That suggests some apps will not use HTML and just render everything themselves
Fortunately advertisers are renowned for their self-restraint, and can be trusted to not abuse this capability to simply shove in as many ads as they possible can, wherever they can, with masses of unblockable trackers underneath it all.