Hacker News Reader

Comment by FpUser | Hacker News Reader

Ok. At some point in the future the browser/wasm will have won. So instead of Linux/Windows/OSX we will have Firefox/Safari/Chrome/Whatever all with their own implementation gotchas, missing features and performance loss. All for the sake of browser vendors trying to displace the existing native deployment platforms. They sure have nice financial incentive. Why do we - developers fall into this trap? We've been there quite a few times already, with cross platform standards. No matter what vendors will fsck'em up with proprietary things.

View on HN

But it's the other way around. Can you distribute a native application on macOS without Apple's blessing? No, you can't (not when Catalina will be out anyway). And Windows is closing the "gap" really fast too. Try distributing a native installer without the browser or SmartScreen bringing up a scare-dialog-box.

Until OS vendors are willing to provide a safe sandbox to run untrusted code in, and untangled from a non-technical curating mechanism which has all sorts of conflicts-of-interests of what's morally acceptable and what's not, WASM is the next best thing to an open, yet secure, platform.

Desktop Linux aside, the web is currently the only open platform for distributing software outside of the interests of a single "platform owner". Google may close this "loop hole" soon, so I'm not too optimistic for the future, but today, that's what it is.

I recently switched to desktop GNU/Linux full time outside of work, and I have to say it's really damn good now.

Mind you, I'm using a Lenovo laptop, so it's among the best supported hardware you can buy for the purpose. But the fact that there aren't more boutique computer makers selling GNU/Linux systems installed by default is an interesting statement on the industry.

I'm sure ultimately it comes down to the availability of software like Microsoft Word, but ironically having so much stuff move to the cloud is a boon in this case. With so many web-based apps available, nontechnical people can switch from Windows to a well-configured GNU/Linux system and not notice much of a difference.

With that problem out of the way, a hypothetical hardware vendor can focus on building sane defaults, a good user experience, and good documentation (good for users, not developers). Then if and when it works out and marketshare ends up in double digits, more non-web software will start to become available anyway, and/or a lot more corporate money could start flowing into established projects like LibreOffice.

Obviously the Chromebook was a thing, and you can buy System76 machines today, but the former was too extreme and the latter is probably too expensive for grandma just checking her email.

I assume the reason it doesn't exist it is because the logistics and economics of the hardware don't work out. But I wonder if it will become feasible some time in the near future.

Beyond that, with flatpak and wasm application sandboxes, it will only get better. Wasm, provided some UI primitives and OS-like primitives get baked in, will give a common runtime for UI apps everywhere without a full browser. WASM+Canvas or WASM+WebGL can/will go a LONG way.

I would say, that enough OS primitives should be present so that as an example SQLite3 can compile and run, and you can get a compatible file out the other end.

> Can you distribute a native application on macOS without Apple's blessing? No, you can't

Yes, you can. You have always been able to.

> (not when Catalina will be out anyway).

Yes, you will be able to.

I just downloaded a music tracker/MOD player from the Mesozoic (well, not quite) and it runs fine on Catalina Developer Preview 4.

I can understand the confusion – I had the same concerns while watching this year's WWDC's Platforms State of the Union – but please do not spread FUD, or accept it as true without credible sources.

Apple does require developers to update their old apps now and then, and that may not be convenient for some devs, but I feel it's overall good for users, and they don't force anyone to distribute via the App Store only or give Apple a % of their sales.

In fact, a few companies have withdrawn their products from the Mac App Store, like Sketch and Coda and others.

Running an unsigned app is a bit of a pain... though, imho probably worth it for the modest improvement in security.

> Can you distribute a native application on macOS without Apple's blessing? No, you can't.

I've been running the Catalina betas, and running non-notarized apps only requires right clicking instead of double clicking. If that's too much of an obstacle for you, you probably shouldn't run the app.

Gatekeeper on macOS is a technology designed to protect careless users. It makes it slightly harder to shoot yourself in the foot. It doesn't prevent you from doing it, though.

But it's the other way around. Can you distribute a native application on macOS without Apple's blessing? No, you can't (not when Catalina will be out anyway).

Yes you can:

https://forums.macrumors.com/threads/unsigned-apps-catalyst-...

WASM is the next best thing to an open, yet secure, platform.

So, instead of walled gardens with signed and checked applications (bad). We have to run untrusted and unchecked code of vendors who run code to track your movements around the web and in their applications? (Even worse)

Desktop Linux aside

Maybe we should make Linux an acceptable platform for more people rather than optimizing for proprietary web applications that you don't even own a copy of anymore.

> Maybe we should make Linux an acceptable platform for more people rather than optimizing for proprietary web applications that you don't even own a copy of anymore.

Won't ever happen for two reasons: 1) The Linux Desktop community would have to admit that there are better ways to do things, and 2) They'd have to agree on what those things are. 20 years of Linux Desktop history show these things to be impossible.

Theoretically, a new community could spring up and put a new userland on top of the Linux kernel, like Android did, but it would seem like the people who have the interest in doing such a thing (like myself) lack enough time, talent, and/or ability to organize sufficiently to pull it off. Not to mention that we'd all have to agree too.

I lack the talent, but I'm definitely interested.

Have you taken a look around Casey Muratori's handmade.network? Or interacted much with the guys who watch Jonathan Blow's livestreams? They make much the same point you do about taking the linux kernel and creating a new userland around it.

Anyone who's interested in working on something like this, email walkinginalinuxuserland@lj3.me. The least we could all do is keep in touch, right?

Yes, I've hung out on Johns and Casey's streams. I don't bother much with handmade.network because very little there interests me. Essence is kinda neat, but it is a long way from practicality and I'm not sure how much my ideals and Nakst's align.

I also think a forum or IRC channel would be more appropriate, but email is a start and I appreciate you taking the initiative.

See also Probono's Hello[0], but I'm not sure he hasn't decided that Haiku already fits for him.

[0] https://github.com/probonopd/hello

> We have to run untrusted and unchecked code of vendors who run code to track your movements around the web and in their applications? (Even worse)

I don't think that is the case. Simply because a WASM application will have to request the permissions it needs up front (assuming a sane runtime) and you don't have to give anything run in background permissions... also, it won't have access to other apps, so it can't really track you.

The bigger issue with Desktop linux is very few people run it, and targeting a specific subset for linux as separate from other platforms is difficult and costly, to say the least.

This is it. Let's be honest - the things that make linux difficult are wireless and graphics drivers because the kernel api's keep changing (to prevent vendors from making non-open-source drivers). Why can't we write a unix compatible desktop os whose only difference is running the drivers in userspace?

Something like Redox(1). It's even MIT licensed, so you could include it in a commercial distribution with your own changes if you so chose when you made your gui.

1. https://www.redox-os.org

> So, instead of walled gardens with signed and checked applications (bad). We have to run untrusted and unchecked code

and sandboxed. yes, this is way forward.

"yes, this is way forward." - I don't think so

Well the alternative is exchanging data, not code. Actually this was the initial idea on the web, hyperlinked data. Look where that brought us. Maybe we could devise a better model with a client (code) that is simple enough and universal enough, and the server providing/receiving only data and not code? That is, instead of me running the publisher's code on my terminal, i run my code on the publisher's data, exchanging data with them. I am not aware of anything to that effect that is universal enough to replace the web. Thus, sandoxing untrusted code as being the way forward.

I think the way forward is to stop worry too much. Like you really gonna be worrying running "flight simulator". I think it is a FUD designed mostly to support big and cloudy providers. Those are the real entities one should worry about. They spy 24x7 .

I am partially an ISV and we provide pure native application for Windows at the moment. No UWP/.NET/APP_STORE/WHATEVER . It is digitally signed and distributed by downloading from our web site. So far no problem. Since we've been in business a number of years there are no any browser/OS/Antivirus level warning boxed during downloading and installation.

> Until OS vendors are willing to provide a safe sandbox to run untrusted code in

Thing is, "safe" OS-sandboxes are not safe; "local" privilege escalation vulnerabilities are still pervasive. Until OS's are safe enough that I can run `sudo -u nobody untrusted_binary` and not even think about the possibility of it taking over my system, something like the WASM sandbox (perhaps extended with WASI and other optional mechanisms) will always be needed.

The the browser sandbox is just another sandbox, as we have seen with targeted attacks on Firefox two weeks back.

Why is everybody so insistent on running untrusted code?

Because the Web won't work without running untrusted code.

The Web of hyperlinked documents would still work. But webapps would not be able to run arbitrary code the moment they were navigated to. Perhaps there should be a clear user-visible distinction between an HTML document with some styling and a full-blown application (that happens to use DOM for layout).

Who gets to decide which code is trusted?

> Why do we - developers fall into this trap?

Regardless of is this a trap or not, it's obvious to me that developers want simplicity and consistency. WA provides both so don't wonder why it's taking off.

> So instead of Linux/Windows/OSX we will have Firefox/Safari/Chrome/Whatever all with their own implementation gotchas

I let the compilers worry about this :)

Yes, declaring the hard parts to be someone else's problem always works out in the end, doesn't it?

Hopefully in 20 years, when people are talking about MetaWebAssembly to abstract away the platforms that run on WASM, you'll have a different perspective on what you've said here.

Oh come on. If you are doing any kind of development, you too, are relying on abstractions and someone elses machinery. That doesn't make you lazy or amoral or something.

Yes, but I'm not under the delusion that adding more abstractions will solve the problem. And actually, I really wish there were fewer abstractions because they often just get in the way.

Adding more abstractions solve existing problems while creating new ones.

But then, this is what humans have been doing since we figured out stone flints.

Yeah, right. Compilers do not deal with the difference in presence / absence and different implementations of various features on different platforms, be it native OS or Browser OS.

Is that so? Worst case I can imagine is to have the same compiler emit app-firefox.wasm and app-chrome.wasm binaries from the same codebase, but I think this is highly unlikely.

But there probably always will be a safe flag that generates everywhere running binaries.

And by then you will have discovered that your software can not do this and that after being relegated to a lowest common denominator state.

Because this time around we will have instant (no install) apps that are inherently sandboxed? Seems like a pretty big win to me.

Webassembly is not magic. You still have to download and possibly cache code and assests. Call it install or not.

I think win is having free software or at least opensource apps that are trusted by distributors and easy to analyze/modify, and actually own (meaning have on your harddrive and fully control). And we already have that win.

[Former developer on the Windows Component and Applications team, renamed Developer Experience team]

There's a big difference between an imperative (e.g. arbitrary code) and declarative installation process. Imperative installation is most common on Windows due to the initial decisions made by the registry designers + the Windows Installer originating from Office and starting with imperative. Declarative installs are common on the Mac where "installation" usually means dragging a binary from the DMG to your Applications folder. OS X then manages OS integrations declared in an app manifiest.

Declarative installations delegate to a system which has a broader view and standard mechanisms to handle state transitions required for installs, upgrades, and uninstalls. Imperative installations frequently leave residue and are hard for even Windows to fix. I spent years of research and have several patents on trying to figure out how to distinguish between "extension points" of the OS and private state to create a sandbox with the necessary pinholes. Even with those tools handy, many software shops see no reason to upgrade because the Windows end user accepts a life of installers.

I see logic in starting from scratch. This time we can create an end user expectation of declarative and (laterally + vertically) sandboxed apps. Hell, that's what we tried to do with Windows 8, but it was unfortunately restricted to the "modern" (aka full screen) apps that never caught on.

In practice, installation in web browser would use a service worker and some hand written caching logic. Neither is declarative. In fact, declarative (https://en.wikipedia.org/wiki/Cache_manifest_in_HTML5) variant of this functionality was deprecated because devs wanted more programatic way to "install" offline web apps.

It's still sandboxed, and limited, so what's cached this way is perhaps easy to totally remove by the browser. But that's not because of the declarativeness, but because of sandboxing.

Makes sense, but if there’s any OS integration (e.g. file type registration, desktop links, etc) then the app isn’t truly sandboxed by these means alone.

Why? I've had that clean painless install on Windows like forever. My installs are always a single executable that copies itself to a proper place, gets any data if needed from company website and when uninstalled leaves no trace on a system. Never touched registry. There is nothing here that calls for "starting from scratch"

WebAssembly doesn’t support all the things that require installation. There is no integration, the apps can’t register for extensions, they can’t hook other programs. Most of this integration is only marginally useful anyway but people did need iOS, a popular OS that just does not support that kind of thing, to see it.

but download and run is the point. with webassembly in the browser i don't have to worry that the installation tool will mess up something on my system. if i want to get rid of the application, i only need to clear the cache.

sure, linux is doing that much better, but until we get linux (homebrew for windows?) installers for windows, i'll prefer webassembly, at least for casual use.

There is no free lunch in this universe. For big applications like CAD there will be nothing "instant" for in case of deployment as web apps. Downloading native packed archive and running install may actually be faster.

Sure, there are exceptions. Cinemas also still receive movies as physical harddrives for a number of reasons, but for most people and situations, streaming is fine.

I am not sure about "most people" but I use fair number of applications (not including software development tools here as they do not pass"most people" criteria ) and none of those are streamed. Every time I try anything web based, online Tetris excepted ;) it sucks one or the other way

OnShape is pretty darn quick.

We already had "instant (no install) apps that are inherently sandboxed": Java and its net-top boxes. Why didn't it work?

Many things.

I was involved with Java applets when Java was in beta and one of the most annoying things was that JDK 1.0 did not come with serialization.

I would build applets that displayed content generated on the server and serialization-deserialization code could be 2/3 of the program. Most people had a slow net back then, so the download performance was a big deal.

JDK 1.1 put serialization in right away, but Netscape had already introduced it's own incompatible serializer, and there were delays in getting JDK 1.1, plus people didn't like Java serialization -- practically there was a year or two where you couldn't use it.

Applets had enough teething pains that people quickly came to the conclusion that they weren't worth the trouble, then Flash came along which came closer to what people wanted at the time.

I'd really like to see Flash reborn on WASM. WASM is a standard, so there will be no problems known to software produced and distributed by a private business (Macromedia/Adobe), problems like closed format, resources access control etc.

>I'd really like to see Flash reborn on WASM

Especially since so much of the internet was once on Flash and we're looking at the loss of historical archives.

Gnash is still being worked on iirc

WASM + Canvas or WASM + OpenGL should give a significant part of that... but what made flash really special was the tooling around it. I wouldn't be surprised to see Adobe make some strides there, but the output may be less than optimal.

Timing, probably. Java was too slow in downloading and running on the commodity networks and hardware available at the time. Now that both of those are fast enough, we're seeing another implementation of the same idea.

Java applets came about in the days of 486s. They had huge startup time, were usually in a tiny little window, and everyone was starting from scratch with few libraries and drawing primitives. There was no webgl or compiling of existing UI programs into webasm with emscripten.

Why do we - developers fall into this trap?

The models for installation, security, privacy and updates on the desktop platforms have barely improved in twenty years, and they really needed some improvement.

The models for installation, updates, payment, portability and development tools on the mobile native platforms all have major downsides as well.

If you build and distribute your software as a web app, you can still do everything that matters for many purposes, you retain complete control of your own software, infrastructure and business model, and your app can work well with relatively little effort on a much wider variety of target platforms.

I don't see it this way at all. Browser vendors have been very reluctant to accept that they're now supposed to provide a real application development platform.

It's businesses that demand web applications, because native deployment (in-house or for customers) is a tougher sell. A lot of it has to do with the bad security model of desktop operating systems combined with the overhead of administration.

Last but not least, web developers are the biggest pool to hire from. It all adds up to where the benefits outweigh the (significant!) drawbacks.

"...Last but not least, web developers are the biggest pool to hire from..." For boiler plate business web apps sure. And while those are probably being prevalent the world does not stop there.

Companies are running webapps on embedded devices now, but I don't buy the ease of hiring excuse. Web devs demand higher salaries than embedded developers and they have more leverage in terms of where they can work (ie: they're flaky as pie crust). Embedded developers are also more likely to pass the hazing ritual known as the programming interview. Where's the upside to hiring web developers in that context?

I think it's a mixed bag... a lot of developers think they know JavaScript or understand web applications. I've found that about 90% are not very good with it in practice. Often with job titles as Mid or Sr developers.

Actually understanding more about JS and the browser, and actual application development, and how it fits are good places to start. I find that the browser model actually fits a redux-like master state machine better than MV* that a lot of experienced developers, but inexperienced web app developers tend to focus on.

It just depends. I think there's room for most players, and IU do think WASM offers a LOT or will as runtimes and standard libraries shake out. I'm looking forward to seeing things develop more... IMHO there should be a focus to standardize interfaces for Canvas, WebGL, Audio and FS first. When you can run an application against canvas 2d or webgl with audio and sqlite, I think that's a large way there. Better input support (controllers as well as kb/mouse) is also pretty high. I know people are working on these things.

Getting something that runs almost everywhere will be very nice and although there's some overlap with the intent of the JVM, WASM has more primitive options (for the good) and can support a greater range of sources to a single target set of interfaces.

Did you mean to respond to my comment? I don't see the connection between your comment and the comment you responded to.

I may have hit reply in the wrong one, apologies.

No worries! I was more confused than anything. :)

"Companies are running webapps on embedded devices now" - sure my router and some of my own private hardware have web interfaces. It is however just a tiny bit of their functionality. The rest leaves happily as native code.

Reply on news.ycombinator.com