6 ms·

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

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 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.

ijpsud 7y ago
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 7y ago
  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.
bordercases 7y ago
Why HTML whatsoever?
- hoten 7y ago
  Because browsers. And because HTML isn't the issue, it's main thread JS.
azemetre 7y ago
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/ https://nextjs.org/ [2] https://github.com/jaredpalmer/razzle https://github.com/jaredpalmer/razzle [3] https://www.gatsbyjs.org/ https://www.gatsbyjs.org/
- dfabulich 7y ago
  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 https://github.com/zeit/next.js/issues/5054 Gatsby has a no-JS plugin https://www.gatsbyjs.org/packages/gatsby-plugin-no-javascript/ 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-better-with-javascript/ https://www.gatsbyjs.org/blog/2020-01-30-why-gatsby-is-bette... https://twitter.com/kylemathews/status/1225541855925985280 https://twitter.com/kylemathews/status/1225541855925985280
thrower123 7y ago
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.
z3t4 7y ago
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 7y ago
  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 7y ago
    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.
jasondclinton 7y ago
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 7y ago
  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.
nicoburns 7y ago
JS isn't the bottleneck, the DOM is. A new framework isn't going to solve that.
- ketzo 7y ago
  What kind of alternatives exist to the DOM? Even conceptual ones?
  - zelly 7y ago
    Directly drawing on the hardware graphics pipeline with WebAssembly, having identical performance to a native application
andy9775 7y ago
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.
hoten 7y ago
You should follow Surma. He's doing interesting work in this area (moving stuff off the main thread). https://twitter.com/DasSurma https://twitter.com/DasSurma
deleted 7y ago
[deleted]
zelly 7y ago
> On mobile, users spend less than 7% of their time on the web. https://vimeo.com/364402896 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 7y ago
  >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.
viklove 7y ago
> with no JS on the main thread Why?

ijpsud 7y ago

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 7y ago
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.

bordercases 7y ago

Why HTML whatsoever?

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

azemetre 7y ago

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/ https://nextjs.org/ [2] https://github.com/jaredpalmer/razzle https://github.com/jaredpalmer/razzle [3] https://www.gatsbyjs.org/ https://www.gatsbyjs.org/

dfabulich 7y ago
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 https://github.com/zeit/next.js/issues/5054 Gatsby has a no-JS plugin https://www.gatsbyjs.org/packages/gatsby-plugin-no-javascript/ 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-better-with-javascript/ https://www.gatsbyjs.org/blog/2020-01-30-why-gatsby-is-bette... https://twitter.com/kylemathews/status/1225541855925985280 https://twitter.com/kylemathews/status/1225541855925985280

thrower123 7y ago

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.

z3t4 7y ago

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 7y ago
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 7y ago
  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.

jasondclinton 7y ago

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 7y ago
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.

nicoburns 7y ago

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

ketzo 7y ago
What kind of alternatives exist to the DOM? Even conceptual ones?
- zelly 7y ago
  Directly drawing on the hardware graphics pipeline with WebAssembly, having identical performance to a native application

andy9775 7y ago

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.

hoten 7y ago

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

deleted 7y ago

[deleted]

zelly 7y ago

> On mobile, users spend less than 7% of their time on the web. https://vimeo.com/364402896 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 7y ago
>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.

viklove 7y ago

> with no JS on the main thread Why?