When publicly distributed, the open-source code is hidden behind layers of indirection bypassing any packaging/integration effort, relying instead on virtualisation and downloading dependencies on the fly. Thanks to those strategies, corporations could benefit from open source code without any consequence. The open source code is, anyway, mostly hosted and developed on proprietary platforms.

Because flatpaks are distro agnostic, while you may prefer to have the distro's native package format you have to understand maintaining a a deb, rpm, etc simultaneously can be a real pain in the ass that you either deal with or you simply choose not to support certain formats and thus certain distros. With Flatpak is one package for all distros, or at least that's the idea.

This doesn't solve the problem of supporting where the users are; not everyone wants to use a rolling release, not everyone has the same kernel version, and so on. Not all distros support deb packages.If everyone was on Arch, then AUR would solve everyone's problem. If everyone was on Fedora, then RPM would solve everyone's problem but we don't have that universal packaging system.Freedom to pick and choose what you want to use on Linux is what makes it fun but for people that are trying to develop software and share it with their customers on linux, it's super complicated; they don't have a way to ship software to everyone in one simple package.Software devs can't just ship a deb package. That eliminates the large number of RPM based users such as Fedora, RedHat Fedora Enterprise, CentOS Stream or other distros. Then you have the Arch users, etc.That's what Flatpack/snap/appimage can help with.

packaging is difficult to maintain on linux with so many different distros that software companies to support.Flatpak, snap, and appimage makes it easier to ship once for a lot of distros that support them.

Flatpak as a truly cross-distro application solution that works equally well and non-problematic for all

If upstream code presumes things will work that dont in snap (e.g. accesses /tmp or /etc) the snap maintainer has to rewrite that code and maintain a fork. Pointless work. Packaging for .deb is a no-brainer.

>Linux needs an app delivery format Yeah, it's incredible that it has managed to survive for so long without one.

It's Snap that drove me to Arch, so it did me a huge favour. Seeing things like GNOME as a snap and other 'core' products wasn't something I was comfortable with. Personally, I prefer flatpaks as a packaging format when compared to snap and appimage. I agree that Linux needs an app delivery format, but snap's current implementation isn't it.

All right, whoever, who wanted to get the latest Chromium work without worrying about snaps, get it from here 15, unzip it and make a executable link to executive file “chrome” in it. It opens instantaneously (in a snap). This Chromium web browser is NOT installed, but lives in a folder called chrome-linux.

Look at it from another distro point of view, like Fedora or Arch. On the whole packages for popular software are not made for those distros - by the manufacturers of the software. As a result many flatpaks and some AUR packages are built by ripping apart debs and re-packing them as other package formats. This benefits Arch and Fedora (and other distros) because they now have access to software they might not have.

Most users frankly don’t care how software is packaged. They don’t understand the difference between deb / rpm / flatpak / snap. They just want a button that installs Spotify so they can listen to their music.

Frankly, if the Ubuntu Desktop team “switch” from making a deb of Chromium to making a snap, I doubt they’d switch back. It’s a tremendous amount of work for developer(s) to maintain numerous debs across all supported releases. Maintaining a single snap is just practically and financially more sensible.

Neutrino only babel-compiles first party source (the JSX -> JS transformation is handled by a babel plugin). It does this because even when using the module entry in package.json, it's expected that the provided file (and it's imports) still be JS and not in some other format - ie: the only difference from the content in main should be that it can use modules syntax (that is import and export rather than require etc).

One thing that matters is if code uses browser-specific (example: Dom) or server-specific (example: filesystem) features.

Input: JavaScript with stage 4 features or older, in ES modules. Output: whatever JavaScript runs best on the target platforms.

The use of a bundler to create a file(s) suitable for running on a client.

It allows the module code (and subsequently dependants on the module) to not use preprocessor hacks, source code changes, or runtime detection hacks to identify which code is appropriate when creating a client bound package.

The browser field is where the module author can hint to the bundler which elements (other modules or source files) need to be replaced when packaging.

When a javascript module is prepared for use on a client there are two major concerns: certain features are already provided by the client, and certain features are not available. Features provided by a client can include http requests, websockets, dom manipulation. Features not available would include tcp sockets, system disk IO.

You can simply prevent a module or file from being loaded into a bundle by specifying a value of false for any of the keys. This is useful if you know certain codepaths will not be executed client side but find it awkward to split up or change the code structure.

As retailers buckle down and prepare for potentially challenging times ahead, supply chain improvements can be a significant growth driver. But rather than just investing in trends like automation smart packaging in reaction to competitors, retailers should think about accumulating long-term competitive advantages through wider supply chain strategies.

Three things are required to fully guarantee a repeatable installation using requirements files.