Perhaps this is a knee-jerk reaction on my part, but I'm against initiatives that resist technological progress, including those that rail against modern web applications.

Not only do these initiatives seem doomed to lose against the nearly unstoppable forward march of technology, but they are coming at the problem from the wrong direction. If it's too hard for independent efforts to succeed, we should not be fighting in vain to hold back progress. Instead we should be working on efforts to increase the abilities of independent contributors. We should be making it easier for anyone to build a modern browser. That's something that more technologists could actually get behind.

Further, while there's nothing wrong with a little nostalgia, let's not forget how far things have come. Many instances of modern web applications are certainly flawed, broken, misguided, overkill. But the web as a platform today is unfathomably better today than it was in the 90s. The applications built on top of it have massively empowered individuals and augmented our productivity. And I'm happy that I can build for the web instead of for Windows.

The fact that some websites do a poor job using the new tools available is a small price to pay.

I dispute the notion that the evolution of the web is at all progress. It has nice things, but so far the main effects are ever increasing bloat and centralisation. There are simpler ways to do this stuff, we're just too caught up in path dependence to see or invent possible alternatives.

> we should be working on efforts to increase the abilities of independent contributors

Unless you mean to make them less independent (say by providing common libraries and rendering engines), then the only way forward is to increase everyone's abilities. This is already an ongoing effort, just see how many programming languages and methodologies are popping up every year.

> the web as a platform today is unfathomably better today than it was in the 90s

The web wasn't even a platform the 90's, of course it's a better platform now. However, it only became a platform by accident. This reminds me of C++'s accidentally Turing complete templates, which later spawned template meta-programming madness.

If a platform was design from the ground up as a platform, it would all be much simpler, perhaps even more capable. But no, we had to piggy back on whatever the market favoured at the time.

---

Here's what I think: a web-ish platform written today wouln't need more than 0.1% of Firefox's 35 million lines of code, or about 30 thousand lines. Or maybe 10 times that amount, to account for optimisation and long tail functionalities —that's still under 1%.

This even has been done. The STEPS projects at http://vpri.org is only 20K lines, including the compiler collection and editing tools. It even runs at acceptable speeds on a laptop.

That would be progress. That would spur the independence of contributors. Too bad the market just isn't ready for this. It probably never will be.

Then let's examine why stuff is so bloated now: is it because we have more features? For the most part we don't. It's just abstractions piled on top of each other, images, and ads.

I'm not even sure the costs are even related to the benefits.

And this is just learning to code.

Which of those costs actually enabled the benefits? Very few, I'd wager. Much of those were avoidable. Or would have been if the market wasn't so short sighted.

> GitHub, JavaScript 30, Khan Academy, RunKit, Flexbox Defense, Codecademy

I reckon some of this does require a scripting engine somewhere. But not all of it. I still believe your examples are possible without JavaScript (even without CSS). A REPL wouldn't need it, if you have the server do the computation (within limits to prevents DOS attacks). It just wouldn't be as pretty.

But that would be unwise. Many of those really are applications, and they deserve a proper application platform. Which the web isn't, despite herculean efforts to the contrary.

A proper application platform needs to give access to simple, relatively low level constructs. Something like web assembly, a raster viewport, input, and sound. Meaning, a virtual machine. Browsers are becoming such anyway. Also, no text handling, no style sheet, no programming language. Let the users implement a web browser on top of the application platform if they really want to.

Actually, I do hope we eventually turn this madness on its head, and implement browsers on top of web assembly engines. This would drastically reduce the effective attack surface (good for security), and do wonders for portability. Wouldn't solve the independence problem, though.

Yeah, it's enough to be infuriating. I've recently been thinking about what it would take to implement a lynx-like browser that had a better understanding of layout and could deal with the modern web.

Hurdle number one is that there's no "Web standard", but rather a great many interrelated standards. At a bare minimum, you need HTTP K₁, SSL/TLS K₂, HTML K₃, XHTML, DOM N, CSS K₄, and ECMAScript K₅. Several of those standards are actually multiple standards, so you'll have to do some digging. That's the easiest hurdle to overcome. Number two is that a few of the standards (including some really fundamental ones like the DOM) are maintained as "living documents", making them moving targets; even the—uh—"dead" documents are subject to speedy revisions (for example, there have been 3 new ECMAScript revisions in the last 3 years). Number three is all the up-and-coming experimental stuff that isn't standardized yet, but if at least one browser supports something, some website somewhere is already using it. Between two and three, you'll need to keep a finger on the rapid pulse of the Web. And on top of all that, you have to support legacy bullshit, deal with malformed documents, and be ever hyper-aware of security threats.

Allowing for off-the-shelf components like libcurl and duktape, I'm sure it's still doable by a single person, but it's a lot of work (much of it frustrating).

If you really need an unchanging version, download some version and use that.

If you do, it's a living standard.

If you don't, then people have to cobble together the latest version from various sources.

The choices aren't "commit everything to master" or "commit everything into various versions".

A strict release cycle also prevents having some hype extension which only a few people actually use since it takes more effort and dedication to get stuff into the standards.

Native Apps provided better UX, easier access on the Home Screen, and is generally 10x faster. What the web responded, or in your words a reaction to people using Native Apps, were to put more Ads, Creepy Ads, more JS tacking, more JS that many had no idea what they were doing, web notification pops up every time you visit a page, mandatory cookies notification, and all sort of other things that makes people no longer wants to consume anything on the Web anymore.

I will have to admit, even without those problem it will be a hard battle against Native Apps, but not only are they not improving the web, they are making it worst.

A Steve Jobs phase constantly pops up in my head when i see this, "The only problem with Microsoft is they just have no taste." It is true for the majority of the web as well.

-Apple limits what your app can do, e.g. apps can't spawn processes (FU Apple, this is bad for security/pricacy), can't do JIT compilation, can't download code, etc...

-Apple rejects apps that compete with their own.

-Apple removes apps that some governments want to have removed.

These are all things an open web avoids.

Now the fun thing is that nothing prevents Apple from turning the web into a walled garden since they don't allow any other rendering engine other than their own. The iOS ecosystem is really a beauty.

> -Apple limits what your app can do, e.g. apps can't spawn processes (FU Apple, this is bad for security/pricacy),

What's the issue with that? Why would I want some random no-name devleoper randomly spawning processes on my device killing my battery life? How is it exclusively better for privacy? What prevents them from executing privacy-invading code as the separate process?

> can't do JIT compilation,

What's the advantage when all the devices, your apps are supposed to be running on, share the same OS, platform, ABI etc? What's the point when the hardware is already limited in scope compared to alternative platforms

>can't download code, etc...

Again, why would you want some random developer be able to download extra code? What prevents them from not misusing it for nefarious purposes? Even assuming that the developer is not malevolent, what prevents a third-party from compromising the developer's "update" servers and pushing malicious code?

>Apple rejects apps that compete with their own.

This is from a bygone era. For every native app on my iPhone, I can list an alternative -

  - Apple Photos -> Google Photos/Plex Photos
  - iMessage -> Whatsapp, Telegram
  - Facetime -> Skype, Allo, Duo
  - Mail -> Outlook, Spark, Airmail
  - Apple Music -> Spotify, SoundCloud, Wynk, Gaana
  - iBooks -> Kindle, Blinkist, Kobo
  - Files/iCloud Drive -> Dropbox, Tresorit, Google Drive
  - Apple Maps -> Google Maps, Waze
  - Keychain -> 1password, lastpass, minikeepass
  - Notes -> Evernote, Simplenote, Bear, Ulysses, Notion
  - Calendar -> Fantastical, Vantage
  - Clock/Timer -> Klok, Timeglass
  - Reminders -> Todoist, Due, Things 3
  - Video -> VLC
  - iTunes U -> Coursera, Udacity
  - Camera -> Halide, Camera Plus, Retrica
  - Weather -> Dark Sky, AccuWeather
  - Podcasts -> Overcasts, Pocket Casts
  - iTunes Store -> I'm not sure there's a perfect alternative but I can purchase music and movies from non-apple services as long as they provide it (and give apple their cut)
  - Settings -> Do we even need an alternative?
  - Voice Memos -> Recordium, Just Press Record
  - Pages/Numbers/Keynote -> Word/Excel/Powerpoint, Google Sheets/Slides/Docs
  - Apple Health -> I haven't gone looking for alternative but a lot of apps maintain their own data sources. I'm not sure what really prevents them from sharing data across or maybe they just don't want to? In any case I, sure as hell, trust only Apple with a centralized data source when it comes to my health tracking
  - iMovie -> Videoshop 
  - Stocks -> Stock Tracker

>Apple removes apps that some governments want to have removed.

True. Agreed

> they don't allow any other rendering engine other than their own

I am a developer and as much joy it would be to have Blink/V8 running on iOS, I'm totally fine with the decision apple made. In the absence of strong disincentives, companies and developers would try to get away with as much shenanigans as possible. I would absolutely not be happy if Google pushes a battery-killing update.

Sure Apple has its fair share of problem but out of all the big tech co's they are, by far, the best when it comes to preserving privacy, security and the least likely to pull shenanigans or gotcha's on their users.

Why do you want Apple to be in control of your device though? Wouldn't you rather be able to let an app do something that it needs to, when you need it to? Or, would you honestly prefer Apple to make all of your decisions for you?

If you really want Apple to be in control of your devices and not you, that's fine... but can you understand why other people might not want that?

Are there any Apple decisions that you disagree with?

Also, how about a replacement for the most important apps?

    - Contacts
    - Phone Dialer
    - Messages
    - Safari

I'd like to replace these because Apple only gives you the most bare-bones features for them and they strong-arm you into using Apple Maps and Safari from them. I'm guessing you're fine with that though.

> [Apple is the] least likely to pull shenanigans or gotcha's on their users.

Pffft. Do you know the history of Apple? Their whole business model is a shenanigan on the users. I look forward to when their time is over.

But yeah, I would like to be able to change default apps in iOS. That would be great.

I don't but I'm not hesitant to cede some control of my device to Apple in order to not be a technology janitor. I do not want absolute control of my device which is not even possible with any commercially available device anyway. (And no, Android does not give you absolute control of the device)

>Wouldn't you rather be able to let an app do something that it needs to, when you need it to?

Does Apple's current model really hamper any app to do something that it needs to, when I need it to?

>Or, would you honestly prefer Apple to make all of your decisions for you?

Again, I am happy to meet Apple in a middle ground where it makes some decisions for me and I make some decisions. I am happy to decide which apps gets access to contacts, notifications, location etc etc. What gives the assumption that you are in all control of decisions on an android device? Remove the Google Play Services and 3/4th of the ecosystem falls flats on its face.

>If you really want Apple to be in control of your devices and not you, that's fine... but can you understand why other people might not want that?

I totally get that part. I never denied that.

>Are there any Apple decisions that you disagree with?

Plenty. Touchbar is useless. Removal of headphone jack was rushed. Before iOS 8, I was practically in the android camp because iOS devices were severely limited then compared to now. iOS's notification game is weak. There is no need for iOS to block the whole screen for an incoming cellular call. Devices can get very difficult to repair.

>Also, how about a replacement for the most important apps?

You moved the goal posts. Original reply was against the assertion that apple does not permit certain apps because of "competition" which is not true. Otherwise Spotify, Evernote, Todoist etc won't exist. Greater than 3/4th of native apps have proper substitutes available in the App Store. You expanded the argument to include apps whose functionality is not replaceable because of ideological grounds or design choices. I never posited that Apple permits all apps. This would be akin to me demanding an alternative for Google Play Services with comparable functionality. Anyways -

  - Contacts -> Full Contacts
  - Phone Dialer -> Simpler Dialer (Not a true replacement though)
  - Message -> True. No Alternative as in you can't access SMS/iMessage
  - Safari -> Chrome/Firefox. Does an ordinary user care if they are running Webkit or Gecko? V8 or Rhino? As long as you are getting the feature of your favourite browser (chrome syncs your data between devices just like safari would between apple devices) why do you care if its Chakra or v8? OTOH, I'm glad that Apple does not let Google roll it's own javascript engine in iOS Chrome. Otherwise surfing youtube on Chrome iOS would like garnish the battery life. This hits Android devices too which do not have a VPx capable hardware decoder.

>I'd like to replace these because Apple only gives you the most bare-bones features for them and they strong-arm you into using Apple Maps and Safari from them. I'm guessing you're fine with that though.

I just sent a link on iMessage from my desktop to iPhone. Clicking on the link opens the location in Google Maps and not Apple Maps. If there's a specific case which forces Apple Maps I'd like to know. Every app I know and use (Outlook, food delivery, taxi services, online stores) force open Google Maps on my device and not Apple Maps. The only time I actually opened Apple Maps since owning an iPhone for 2 years is when I went to see if navigation is being provided in my area or not. Practically it doesn't exist for me. Even Apple's own Workflow app gives me Google Maps directions (I can choose between both when setting up the workflow)

>Pffft. Do you know the history of Apple? Their whole business model is a shenanigan on the users. I look forward to when their time is over.

Please give me concrete examples of "Their whole business model is a shenanigan on the users." There are few ups and downs but overall, interaction with Apple is much more pleasant than dealing with other tech companies. That they are expensive is not a shenanigan. You know what you are in for when you're purchasing an apple device. I've yet to see Apple engage in deceptive practices or misleading claims or gotachas like Sony which claimed all multimedia support on my TV but turns out only mp4 and mkv are supported on only an NTFS formatted partition. And if you are using a hard drive you can only use specific USB ports because not all ports provide maximum current. Half of this info was buried in the manual and half I had to figure out manually by taking a USB Voltmeter to my TV. Or like Canon which claimed "full compatibility across all Operating Systems" but turns out duplex printing is not supported on mac os or linux which was confirmed to me in a forum post. Or like Dell which claimed 2560x1440p @ 60hz on my monitor but conveniently failed to mention, on the box or in the quick start, that it's supported only on DP and if you've got to use HDMI then you have to go out of your way to create custom profiles and what not. This was not even mentioned in the manual and I had to scavenge for it in the dell forums.

The closest I've come to a "gotcha" with Apple is the lack of DP MST support in mac OS some years back and which was not readily confirmed in apple support article. The only other egregious issue I can remember is the refusal to acknowledge and fix the iPhone 6 bending issue. For all other issues, Apple generally came forth with an acceptable solution (like free bumper case for iPhone 4 cellular connectivity problems, free display replacements for the staingate thing, free motherboard replacements for the 2011/2012 Macbook Pro Graphic Card issues, 6s free battery replacement even after 3 years if you have the "defective" first batch phones). Unlike, say LG which threw a tantrum on replacing the motherboard of my mother's nexus 5x, or OnePlus which quoted a repair bill higher than the cost of a new device, or HTC which promised to repair the device in 3 days but delivered only after a fortnight, or Logitech which claimed to process a refund within a week but took 45 day. OTOH, I have had exactly one interaction with Apple support over the past 5 years and they replaced my phone in 24 hours (while claiming 7 days). And this is when Apple does not even sell directly to consumers in my country. I can only image what the support would be like when the middle men are removed. This is compounded by the fact that every other person in my close circle, who has interacted with Apple support, speaks highly of them. So my one single interaction is not an outlier.

>I look forward to when their time is over. I look forward to that time too but alas, I'm pretty sure that I'd be gone from this earth by then.

Apple has its fair share of issues (tax avoidance, being stingy with new product launches etc; I can jot down a whole list) but hands down the products are a joy to use and the company pleasant to interact with, for an average consumer, compared to any other option available on the market.

Processes (unlike threads) are for memory protection. There's no relation between the number of processes and battery life.

> What's the advantage when all the devices, your apps are supposed to be running on, share the same OS, platform, ABI etc? What's the point when the hardware is already limited in scope compared to alternative platforms

What if you want your users to be allowed to write code?

> Again, why would you want some random developer be able to download extra code?

Again, to allow users to share code (e.g. allow game mods).

> What prevents them from not misusing it for nefarious purposes?

The same thing that prevents them from having native code doing nefarious stuff: nothing.

> what prevents a third-party from compromising the developer's "update" servers and pushing malicious code?

Nothing, just like an native app can be compromised. That's why Native Apps are in a different process, and that's (one of the reasons) why Native Apps should be able to create their own processes (e.g. run a game mod in a separate process from the rest of the game).

> This is from a bygone era.

Okay, but this may happen again.

From a vendor's perspective:

- Web apps often have a reduced support burden relative to equivalent desktop apps because you have easier solutions for complete control over deployments: environments, live versions of software in play (often only one).

- Subscription payment models are convenient for vendors: they can help smooth out revenue but, critically, can also increase lifetime value of customers.

From the customer's perspective:

- One less software system to deploy, manage, and support,

- Managing backups is (should be!) taken care of for you,

- Lower on premise hardware costs,

- Your stuff is available from anywhere you have access to a browser,

- Can enable frictionless collaborative working.

With that said, it's arguable that a purely web-based SaaS model isn't necessarily a good fit:

- The problem of lock in is often worse. Even if you have options to export your data, is it in a format that makes it easy to import into a competing offering?

- Poor (or no) offline support, and unreliable operation with choppy connectivity.

- TCO can be higher, despite reduction in on premise support costs.

- Subscription payments can quickly mount up to death by a thousand cuts with respect to costs.

- Your data is not only offsite, but may not be stored in the same country or even on the same continent: a deal-breaker in some scenarios.

- Susceptibility to attack via DDoS, and other methods: at best service can be degraded or rendered unavailable, at worst your data can be compromised.

SaaS is like anything else: it can work really well (Office 365[1], GitHub, GMail), or it can be decidedly ropey (Google Docs), or anywhere in between.

[1] Within certain constraints - to me Office 365 still feels weak as a collaborative tool.

> Poor (or no) offline support, and unreliable operation with choppy connectivity.

is also being solved - with additional complexity for browsers, of course.

The big advantage of such browsers being the zero-risk of JavaScript doing sneaky things ( like keylogging )

Facebook already has far more cash and profit than they know what to do with. $38 billion currently, rapidly climbing. They'll add ~$20 billion to that in 2018. They could do a new browser just for kicks if they wanted to, and they have the vast global reach to generate some uptake.

Whether either could claw meaningful share away from Chrome is an entirely different question.

Samsung, Tencent and Alibaba all have the resources to launch entirely new browsers if it made sense.

The bottleneck is engineers who have the know how to build it.

Building your own browser could be a shitty business decision if you can't compete with Chrome for ad dollars.

A browser makes sense if you can bundle it with an OS.

Android : chrome, ios: safari and Windows: Edge

Facebook makes a shit ton of money from ads people click on chrome.

- uc mobile on Android now uses the blink engine, it used to use Webkit. - uc mini ( I think that's the name) has server renderer but it's "uc engine" is a derivative of gecko (not checked recently)

Quite similar to Chrome, but has support for ad blockers etc.

But yeah, from scratch is hard... Google didn't even do that, they started from webkit.

Also, I would try to make it as modular as possible. E.g. layout engine, css engine, js engine etc. as libraries, use the system codecs instead of bundling own codecs, and so on.

And it would help to have an extensive test suite, which you could take from other browsers.

The only way to ship a browser that doesn't render "web apps" would be to simply not support scripting of any kind. That would permanently break much of the web unless you offered a way to opt in to scripting the way current browser users who run script blockers can. But then you just have a regular browser with script blocking turned on by default.

Having different engines for "static" and "web app" documents, and defining a proprietary standard for the former as a restrictive subset of HTML would be unnecessarily complex and hostile to web developers.

You could autodetect a "lean html" site, or you could use a marker such as "<html lean>" like AMP does.

I don't think this is hostile to developers at all, unless AMP is already hostile. You would have a subset of the web platform, yes, but if you only use that you are likely to have a faster and leaner website - even without a new engine. I would view it as a guideline or a best practice, rather than a restiction.

Side note: I think the co-mingling of documents and apps is the source of a lot of problems today. Why can ads inject arbitrary javascript into my website?! On mobile, I am regularly redirected to annoying ads that proclaim my phone is infected, and make my phone vibrate and make noise. A news article shouldn't be able to do that!

That's a restriction. If site authors have to abide by that or else not have their content render in your browser, you're restricting their freedom to publish the content they want or make their own decisions about what code they choose to write.

But if you still have a "backup engine" that will run it anyway, then what's the point?

>I don't think this is hostile to developers at all, unless AMP is already hostile.

I would think Chrome was hostile if it gave preference to AMP over standard HTML. Those aren't decisions that browsers should make.

>Why can ads inject arbitrary javascript into my website?!

Because that's what the site authors decided to publish. Like it or not, that's the way the web is intended to work - you request a URL, you get back whatever the server decides that URL points to. Changing that dynamic would change the web at a fundamental level.

I further think, if you sell it right, you could get people running sites like blogs, documentation, wikis, to opt in to "strict" or "lite" or "document" mode, but that is an orthogonal issue.

> Because that's what the site authors decided to publish. Like it or not, that's the way the web is intended to work

I'd argue that the web wasn't intended to involve executing code, but rather it was originally envisioned to be a means of viewing documents.

That's fair - but it doesn't imply that it was intended to not execute code, so much as that it wasn't feasible to consider at the time. The web wasn't originally intended to display images either, but it evolved over time. Certainly, in either case, javascript was never intended to carry the burdens it's been made to, but people found it useful to have a Turing capable language as part of the web, and here we are for better or worse.

And the web in the near future when WebAssembly takes off is going to execute binaries compiled from arbitrary languages, of which javascript will be only one option. That's going to be awesome in both senses of the word. Not what the web was originally intended for, and certainly not the best of all possible worlds, but I would argue that it's still better than static documents alone, in terms of the possibilities it provides to publishers and users.

And maybe the pendulum will swing the other way at some point. Maybe people will choose to write lighter pages and not use unnecessary code. But if they don't, that's still their choice to make, not yours or a browsers to make on their behalf. And unlike with C, C++, Java, etc, you can turn javascript off if you want and still use some of the web.

An extremely light and content-focused spec like Gopher would exclude a lot of websites that we would consider light. Terms used to describe light subsets of web capabilities, like “DHTML,” do not appear to be well defined.

My initial attempt would be to exclude XHR/fetch, dynamic URL/history manipulation (window.history), and loading resources from other domains. But the latter would probably exclude things I don’t oppose (like CDNs) and things I don’t necessarily support but which would surely drastically impede adoption (like third party ads/analytics services).

Can you propose a better and more viable spec?

I think the prevailing opinion on Hacker News is exactly that.

If at the same time you could encourage widespread adoption of your HTML subset, then you may be onto something. This is essentially what Google did with AMP, their incentive being their caching network and apparent favoring in search results.