Should web apps have existed in the first place?

[zzo38]

Even more specifically, if an NES game can be played either in JSNES or by buying a cartridge, would you buy a cartridge?

I would try to figure out how to download the ROM image. (I have done similar thing before actually, with DOS games, and with a GameBoy game.)

At least for me, the objection is web apps is not so much "why do I have to use Google Docs instead of Word" but more "why is it that I can no longer read approximately 1/3 of blogspot journals without running arbitrary (if sandboxed) code? why can I no longer read any microsoft knowledgebase articles without running arbitrary (if sandboxed) code?"

I use neither Google Docs nor Word, because I prefer to use TeX. But many unreadable webpages I have found ways around needing to enable scripts, such as by CSS hacks or GreaseMonkey scripts.

My stance is that they shouldn't be butting into HTML in a way that makes HTML…not HTML. I'm running into increasing numbers of pages that don't even try to have a fallback and just deliver nothing, if the user is unwilling to run their code.

This is what I agree. Sometimes a script might be useful to have but most of these webpages and files ought to work even if scripts are disabled. (If it is a full program, it can make sense to require a script, although for interactive server-side programs you should probably to use telnet or something like that instead.) (Although in many cases I publish files just as plain text and don't even need HTML.)

If not, then what method of deploying one application to users of Windows, Windows Phone, macOS, iOS, X11/Linux, and Android is preferable?

Different devices can have different input method (keyboard, mouse, touch-screen) and different kind of file system and other things of the system, so there can be different problem related to such. I prefer the command-line program anyways. Depending on the program, there are a few different possibilities; which is best can depend on program. Here are a few ways:

• Write a command-line program in C; recompile for different systems. Objective-C is a strict superset of C, and you could even compile C into asm.js JavaScript codes if needed.
• Run stuff on the server, and implement a protocol, possibly with a HTML+JavaScript document used as the default client for that protocol, and/or a telnet server which can also be used. Other clients can then also be written.
• Use some other common protocol, and provide a front-end.
• Use some other VM, and provide the packages for the systems and/or HTML+JavaScript implementation.
• Implement a back-end and front-end both in JavaScript. You can then write different front-ends for use with HTML, Node.js, PhoneGap, etc. (JSZM is implemented in this way, for example.)

[tepples]

Even more specifically, if an NES game can be played either in JSNES or by buying a cartridge, would you buy a cartridge?

I would try to figure out how to download the ROM image. (I have done similar thing before actually, with DOS games, and with a GameBoy game.)

If a publisher wants to price-discriminate between online and offline play, it can make downloading the ROM image for offline use more cumbersome with digital restrictions management:

• Simulate storage access using an obfuscated protocol over the Internet. For example, in a computer emulator, hook the operating system's fopen() call (or close equivalents) to retrieve and decrypt that file. Or in a retro console emulator, hook the bank switch registers and keep only a small number of banks cached on the client at once. Have the game preload each level by switching to those banks that the level uses, so that gameplay isn't interrupted.
• Use legal remedies available under applicable anti-circumvention law against third parties who offer downloaders that emulate your protocol.

Different devices can have different input method (keyboard, mouse, touch-screen) and different kind of file system and other things of the system

The advantage of a browser or other cross-platform UI framework is that it abstracts over some of these differences.

[Sik]

Without ads, sites would probably put up more paywalls.

Or sponsored stuff (i.e. paid ads passing off for articles), though some sites try to find a middle point by having part of their stuff free and part paid-only (instead of an all-or-nothing paywall). This may eventually have to happen anyway as adblockers start becoming more widespread (and because of all the shit practices from the ad industry, don't be surprised if it the blocking ends up in the browsers themselves in the future).

The big money is in tracking anyway, and blocking javascript hampers that severely.

[calima]

don't be surprised if it the blocking ends up in the browsers themselves in the future

Why, one was included in Opera 9, released in 2006. The descendants, Fifth and Otter, include the same.

[tepples]

Without ads, sites would probably put up more paywalls.

Or sponsored stuff (i.e. paid ads passing off for articles), though some sites try to find a middle point by having part of their stuff free and part paid-only (instead of an all-or-nothing paywall).

This is called "native advertising", and national ad practices regulators have been cracking down on it.

The big money is in tracking anyway, and blocking javascript hampers that severely.

Case in point: I don't run an ad blocker. I run the tracking blocker built into Firefox. (Firefox turns it on automatically for Private Browsing sessions. To use it outside Private Browsing, open about:config, then set privacy.trackingprotection.enabled to true.) Yet WIRED can't tell the difference between the two, showing the paywall notice with instructions to disable ad blockers and disable tracking blockers. It's so hypocritically dysfunctional that a review of tracking blocker Disconnect gets covered up by instructions on how to disable Disconnect.

So I guess "run our JavaScript web app or help cover the cost of producing native apps for six platforms" is what will end up happening.

[Sik]

Firefox is also going to block some fingerprinting stuff now, although doesn't seem to be the same thing
http://www.ghacks.net/2016/07/18/firefo ... rprinting/

So I guess "run our JavaScript web app or help cover the cost of producing native apps for six platforms" is what will end up happening.

More like two, because those who care about it that badly will probably just decide to go mobile only and do only iOS and Android (not to mention tracking is much easier on those, sandboxing is pointless when every app requests permissions for just about everything and users have been trained to just click OK to anything they demand). I mean I already keep seeing sites obviously designed to be visited only from a phone (single page with a tiny hamburger button and each section being a screenful without much going on), and some new services outright don't bother with sites anymore and have exclusively apps.

[zzo38]

I find CSS hacks with Stylish will often work, and in cases where that won't work either, GreaseMonkey often helps. So even if they cover by a message or "display: none" or whatever, I can override that stuff.

Even for mobile apps you may find the way to override the permissions and put in your own sandboxing and so on anyways (even giving fake access to stuff if necessary) if you have the proper programs to do so.

If a telnet service (without security) is used, then it will be difficult to track anything other than what terminal emulator is being used (and you may even be able to make that difficult too).

A service could also go exclusively API if you need to. (A small number of services do. My own designs are intended to be API-friendly.)

I would highly intend design a new computer system. With this one, all programs are mandatorily sandboxed by hardware (unless the user reprograms it or makes hardware modifications), and the user may even program the BIOS to lie to the programs that are running (about available RAM, MAC address, DVD read speeds, and other stuff). All protocol and so on are simple to understand and all open source so that anyone can do. Trademark is used so that an implementation of this computer design which fails some of these requirements is a trademark violation if they use the trademark.

As one example of one service, I have a service to comment on my custom Magic: the Gathering cards. These are available as a text file (which does not include user comments), a SQLite database (does include user comments), and a dynamic webpage (does include user comments). The form to send comments is simple so you can easily use curl to send the comments if you wish. The SQLite database can be downloaded to look at comments too (the passwords are not stored in this database; they are stored in a separate .htdigest file which cannot be accessed over the internet). Therefore, it can be in use whether you use the web browser or not.

Computer use should be to be done by people who know how, so you should know a few programming and stuff. Otherwise you should not need a computer. Not everyone should require a computer, and not everyone should require a mobile, and I do not have a mobile and do not intend to have a mobile; it is not a very good computer design in my opinion.

So I guess "run our JavaScript web app or help cover the cost of producing native apps for six platforms" is what will end up happening.

I think that the third way should be needed too: "run our JavaScript web app, or help cover the cost of producing native apps for six platforms, or port it by yourself". Therefore you can convert GUI-based program to command-line-based program or vice-versa too.

The advantage of a browser or other cross-platform UI framework is that it abstracts over some of these differences.

Not always sufficiently or reasonable way. Some VMs and file formats and so on may abstract over it good enough for the purposes they do, but not always sufficiently for anything. For the uses that Gopher protocol can have, the way it works actually is very good to abstract over any kinds of UI (including a large number of things that haven't been done yet), but clearly that is just one specific use. And, also there is such thing as command-line interface, batch interface, graphical interface, etc too, even indepent of the input device and display device; so many things might not abstract well enough to be able to convert a GUI to a CLI for example.

[tepples]

Assuming that the objection to allowing JavaScript to execute is that it's a compromise to computer security, isn't it a bit ironic that each solution grows closer to running the software on bare metal?

In comments to a story on Slashdot about Chrome's introduction of an experimental Web Bluetooth API, I found that more vocal users are jumping on the bandwagon of preferring native applications over web applications, even to the extent of preferring not to have access to an application at all because it is native to the competing operating system than to run a web application.

You mentioned security. Web application opponents claim the following security advantages of native applications:

• As TheGratefulNet pointed out, running only native applications makes it easier to enforce a policy of running only free software. Firefox has the LibreJS extension to run only those scripts that make a machine-readable claim to offer complete corresponding source code under a free software license. Chromium (the free part of Google Chrome) currently has no counterpart to this extension.
• As Anonymous Coward pointed out, sandboxing of native applications can be finer grained, with a separate operating system-level user account for each application. A web browser runs everything as you.
• As DarkOx pointed out, native applications are more likely to be packaged as self-contained units. Web applications are more likely to mix executable code from different origins, especially scripts hosted by ad networks and ad exchanges that have in the past been vectors of infection.

[nitro2k01]

Yet WIRED can't tell the difference between the two, showing the paywall notice with instructions to disable ad blockers and disable tracking blockers. It's so hypocritically dysfunctional that a review of tracking blocker Disconnect gets covered up by instructions on how to disable Disconnect.

In your tweet, you call this hypocrisy. But they also review Adblock in that article. (Full article name: "Plug-ins for Privacy: Disconnect and Adblock") Why is it asking to disable Disconnect, in particular, that makes them hypocrites? Furthermore, the article is 5 years old. Does mentioning something in an article once, give a publication an obligation to support said thing in perpetuity?

[tepples]

Both make them hypocrites. I chose Disconnect in particular because it shows the behavior of WIRED as both hypocritical and incompetent: hypocritical because it both recommends and recommends against a product, and incompetent because it accuses a product that is not an ad blocker of being an ad blocker.

I agree with you that "do as I do, not as I did" is repentance, not hypocrisy. But in that case, WIRED should pull or at least conspicuously disown the old article.

[nitro2k01]

incompetent because it accuses a product that is not an ad blocker of being an ad blocker.

As I understand it, their reason for asking the user to disable Disconnect is that it blocks ads that happen to track the user. The net result for WIRED is the same, that an ad impression and in the extension money is lost, even if the intention of Disconnect technically isn't to block ads. Correct?

[tepples]

The incompetence is the inability of the site's scripts to detect this situation and automatically switch to ads not based on tracking the user.