HN Theater @HNTheaterMonth

Curious if you're aware that mobile web usage dropped from 14% to 8% from 2014 to 2016[0]? And that according to Alex Russell[1], Google's internal telemetry has it well below 7% now. It seems to me that the opposite is true, that the irrelevance of the web on mobile will keep the web app versus mobile app division around essentially forever (web apps will be popular on desktop, and native apps on mobile). (Unless I was misunderstanding and you were saying, what's the difference? E.g., Facebook is Facebook, whether it's a web app or a native app.)

[0]: https://www.flurry.com/post/157921590345/us-consumers-time-s...

[1]: https://vimeo.com/364402896

⬐ cooljacob204

Well more and more mobile apps are becoming reskinned webapps. So from a technical standpoint it is becoming more meshed.

⬐ konart

That's sort of proves my point. Many apps these days are just a web app with a launcher for your homescreen.

Lets say we have https://dynalist.io/. If you are going to open their web app in Safari and then open their iOS app - you will notice that UI is identical. Because it is the same UI! In one case you have to access it via a browser and the app is just the same frontend delivered to you as an iOS app.

PWA or something similar - is the future. Hence all those APIs in browsers.

We need a faster web framework that generates HTML on mobile phones with no JS on the main thread.

The web is the "single top-priority" software platform, but it's in big, big trouble.

On mobile, users spend less than 7% of their time on the web. https://vimeo.com/364402896 All of the rest of their time is in native apps, where big corporations decide what you are and aren't allowed to do.

As a result, the money is going to native apps. The ad money is going there, the dev time is going there, and the mobile-web developer ecosystem is in peril.

The biggest reason people use native apps instead of mobile web apps is performance. Developers design web apps for fast desktop CPUs on fast WiFi data connections, and test their sites on top-of-the-line smartphones costing 5x-10x as much as the cheap smartphones people actually carry around.

Web developers have to solve this performance problem the way we've always solved our problems: with a new framework. ;-)

But specifically we need a framework designed to generate HTML with no JS at all, and designed to run in a Service Worker, which is a little web server that runs directly on the user's phone.

This style of app is often called a "Progressive Web App," and there are plenty of frameworks that support PWAs, but they generate PWAs on top of a single-page app framework that downloads megabytes of JavaScript running on the main thread. PWA is an afterthought for most frameworks, but we need it to be the centerpiece of the design.

⬐ jasondclinton

You're right to raise apps as a threat to the open web. And about performance being a factor (WASM could help there).

However, the real reason that the ad money (and engineering effort) is going to apps is that app platforms do not protect privacy at the same level that the open web does. There's so much more tracking available on mobile platforms than there is on the open web.

⬐ dfabulich

I don't think I agree. The privacy protections are different between web and native apps. On the web, you can track users passively with cookies and with various fingerprinting techniques, and there are numerous ways for third parties to communicate to share tracking info. In native apps, you can use the "advertising ID" (IDFA for iOS, AdvertisingId for Android) the advertising ID is designed to change from time to time or even restricted by savvy privacy-sensitive users, and communication between third party apps is more restrictive. Privacy is mostly a fiasco in both cases, IMO.

⬐ z3t4

There already exist such a framework. I like to call it "vanilla". eg. no frameworks, and due to the stability and backwards compatibility of the web platform, doing a "vanilla" web app doesn't just give you 10x performance, it will also be much easier to maintain. The trick to doing a vanilla web app is to not write any XML (eg. ban innerHTML and Jquery). And not storing state in the DOM. You can use Websockets for live updates, with event listeners and self mutating components (written as pure JS functions). Data is synced between devices, and the app can be started and used offline.

⬐ richajak

I am curious about your approach as I also write my web app in vanilla JS. Where do you store the state or save the data? For me, I use either localstorage for simple update or network fetch for every thing else. For data format, I use Json all the way, rather than handling others,eg FormData, key/value.

⬐ z3t4

You want to have a source of truth. For simplicity I use a global variable. I however use Object.defineProperty so that it can only be written to via an "API" (methods on a global object), which is also responsible for calling event listeners.

For persistence localStorage works great. But often you want to have the source of truth on the back-end. For example if the user opens the app on two devices A and B, change the background to green on device A, and change the background to red on device B, then open up the app on a third device C, what background should device C get? :)

For simplicity I prefer to serialize to JSON, either to localStorage, or a .json file on the server, which is only for persistence in case of a sudden power loss, otherwise data lives in a in-memory object.

Clients today is very capable so I like to store as much data on the client as possible for fast reads. Then update that data in the background, which would also fire events (like "newMessage").

For binary blobs however, like images and video, I store them on a server, and let the browser's cache take care of the caching. I sometimes also let the browser cache take care of the caching of .json files if the data is rarely updated. For all static data you can use a high expire date and let the browser handle it. Only use the in app memory for data that is often read/written.

If you like to micro-manage the browser cache, you can use service workers. Service workers let you do complicated things like manually updating the cache, upload files from the client to the cache, wake up on push notification to prime the cache, etc. So even if the user is offline when he/she comes back to the web "app" most data is fresh and accessible.

⬐ andy9775

Svelte comes close, stencil.js looks to have a focus on PWA's. I've played a bit with svelte and want to try stencil

My one issue with PWA's is iOS doesn't support all the features.

⬐ ijpsud

100% agree with this. Another thing that users have to deal with on the web, but not on apps: Endless banners and popups telling you about useless things like cookies, emails subscription, notifications, gimme-your-location, "download our app", etc.

⬐ CamperBob2

Rest assured, app vendors are working diligently to close the asshat gap with their cousins in the Web community. Open an app nowadays, you can expect a flood of popups, unsolicited notifications, and even ads that you thought you paid to remove.

⬐ azemetre

How do you feel about JS frameworks like NextJS [1], Razzle [2], and Gatsby [3]? They try to reduce the bundle and first times to paint and interactions.

[1] https://nextjs.org/

[2] https://github.com/jaredpalmer/razzle

[3] https://www.gatsbyjs.org/

⬐ dfabulich

I'm not very familiar with Razzle, but Next and Gatsby are examples of what I was referring to in the last paragraph, SPA frameworks that have a PWA mode.

https://github.com/zeit/next.js/issues/5054

Gatsby has a no-JS plugin https://www.gatsbyjs.org/packages/gatsby-plugin-no-javascrip... but that also disables the PWA. The Gatsby team doesn't seem to be interested in no-JS mode. https://www.gatsbyjs.org/blog/2020-01-30-why-gatsby-is-bette...

https://twitter.com/kylemathews/status/1225541855925985280

⬐ thrower123

I do miss that brief window when sites would have mobile-friendly views where they would give you a de-shitted basic HTML-only view if they detected you were using a mobile client. Then 4G happened, and certain markets got wireless data that was on par with what most desktops got through their cable internet, and it was over.

⬐ hoten

You should follow Surma. He's doing interesting work in this area (moving stuff off the main thread). https://twitter.com/DasSurma

⬐ nicoburns

JS isn't the bottleneck, the DOM is. A new framework isn't going to solve that.

⬐ ketzo

What kind of alternatives exist to the DOM? Even conceptual ones?

⬐ zelly

Directly drawing on the hardware graphics pipeline with WebAssembly, having identical performance to a native application

⬐ karsonic

PWAs are a neat solution to making webpages look and feel like a native app.

⬐ viklove

> with no JS on the main thread

Why?

⬐ bordercases

Why HTML whatsoever?

⬐ hoten

Because browsers. And because HTML isn't the issue, it's main thread JS.

⬐ zelly

> On mobile, users spend less than 7% of their time on the web. https://vimeo.com/364402896 All of the rest of their time is in native apps, where big corporations decide what you are and aren't allowed to do.

And the web isn't controlled by big corporations? You literally just linked to a website on the web owned by a big publicly-traded corporation.

I am in favor of using the web over apps but mostly because it has less tracking features. A more high-performance, bare metal implementation of the web would most likely give more stuff for websites to fingerprint you with. You want WASM, but WASM makes the web just as bad as apps in that respect. WASM is going to make it impossible to hide ads (because it will be painted without the DOM) or to block tracking or otherwise malicious code (because it will be heavily obfuscated).

⬐ meowface

>A more high-performance, bare metal implementation of the web would most likely give more stuff for websites to fingerprint you with. You want WASM, but WASM makes the web just as bad as apps in that respect. WASM is going to make it impossible to hide ads (because it will be painted without the DOM) or to block tracking or otherwise malicious code (because it will be heavily obfuscated).

This is true, but what's the alternative? That just seems like a necessary trade-off. Native code will always be easier to obfuscate. It seems backwards to think that we should keep things far more inefficient and consume more cycles and electricity and place things behind more layers of indirection and make web use slower for users just so that it's harder to hide malware. This reminds me of the argument that we shouldn't make cryptography too strong because then it could be used by criminals in a way that even intelligence and law enforcement agencies can't pierce.

There's already a ton of tracking going on, and typically already with heavy obfuscation. The obfuscation doesn't seem to make a difference in terms of practical solutions either way, since the detection and blocking is generally based on origins and IP addresses rather than static (or even dynamic) analysis. And a lot of ad blocking does the same, and should still work for WASM.

For cases where the ads are served directly by the origin and are painted without a DOM, more clever mitigations will be needed, but I don't doubt that people will come up with solutions.

So, yes, the cat-and-mouse game is going to become easier for ad/tracking companies and harder for anti-ad/tracking developers, but it's going to be a big challenge for both parties, just like it is now, and the anti-ad/tracking side is still going to have a lot of success.

I know that AMP is an intensely controversial topic, but I have to provide a counterpoint here because I don't think the web developer community fully appreciates the real state of the web on mobile:

> How many of you think that the amount of time spent on the mobile web as a fraction of total time on device has increased in the last five years? ... it's well below 7% and in a lot of markets it's falling. We have pretty good telemetry inside of Google and what it tells us is that the web is not essential to the future of computing on mobile.

The Mobile Web: MIA, Alex Russell, https://vimeo.com/364402896#t=13m00s

The gist of his argument is that history suggests that when computing platforms drop below 13% of usage (or perhaps it was 10%, I don't remember the specific number), the platform is in a death spiral.

In my 5 years in Web DevRel at Google, I've never heard "it makes the web easier to index" as the main motivation for AMP, I've actually never heard it as a motivation at all. Maybe it is a motivator. The argument definitely makes sense. But I've not heard indexing as a motivator, not even in passing.

As a Googler involved in the web I know that I'm inherently biased and everything I say is likely to be written off, but I'm being 100% transparent with you here. There's a lot of people that care about the open web within Google and see it as the best platform for a lot of the same ideological reasons that you all probably love the web. The open web enthusiasts consider the real competition to be: the web versus whatever other platforms are dominant on the computing devices of the future (right now, that's iOS and Android on mobile devices). AMP is a strategy to incentivize websites to provide user experiences on par with whatever else is out there.

Disclosures: Googler in the "Web DevRel" team. FWIW we don't report to AMP. So my understanding of AMP may not actually align with the AMP team's. Note that I'm not even saying here whether I think AMP is the right approach to tackle the web's big problem, but I do understand why some people felt AMP is necessary right now. This post is definitely my own personal opinion and doesn't even represent Web DevRel's opinion. I may in fact get in trouble for speaking out about this ;)

> the time to first meaningful render in svelte is substantially, substantially lower than it is in React, and you face none of the drawbacks of using the React starter stuff (ie ejecting isn't a thing). This may seem like a weird metric, but I think it's pretty vital.

I think this is the most important metric of any JS project.

We rarely need to update thousands of dom elements per second, but all JS projects need to download and start running ASAP. Specially on mobile.

This talk was pretty enlightening: https://vimeo.com/364402896

⬐ hamilton

Thanks for the link. Incidentally I have that same talk bookmarked. Though for the record, I have needed to render thousands of dom elements per second :)

⬐ Lx1oG-AWb6h_ZG0

I found this recent talk by Chrome's Standards Tech Lead very eye-opening. He talks about some shocking trends in the ecosystem that’s causing the web to essentially disappear from the vast majority of mobile devices being sold across the world. His main points are:

1. Most of the new devices coming online are using cheap low-powered chips that are not very well suited for running single-core JavaScript

2. The web ecosystem is not helping things by bundling megabytes of code on each page

3. Network speeds are not helping either: the average LTE speed is decreasing because the bandwidth is now being shared across more people.

4. Apple is deliberately restricting the mobile web by (a) not investing in safari and keep it lagging behind other engines, and (b) not allowing other browsers to compete.

5. Usage of web (as opposed to native apps) in mobile devices has fallen below 7%, and unless things change soon, nobody will have any incentive to target the web and it will go the way of COBOL and mainframes.