JavaScript pushes my buttons immensely—we have a resentful, adversarial relationship. I am an odd duck in that I happen to like server-side rendered pages (PHP, ftw), and I go to great lengths to...
JavaScript pushes my buttons immensely—we have a resentful, adversarial relationship. I am an odd duck in that I happen to like server-side rendered pages (PHP, ftw), and I go to great lengths to use JavaScript as little as possible—unless I need to expose bits of local browser functionality, like native share sheets. The grand majority of the sites I maintain have less than 10 lines of JavaScript, and I like it that way.
However, I have one major bone to pick, because it hurts me and my (quite reasonable) design style. It's First Contentful Paint (FCP). FCP is the score (in seconds, lower is better) in how long it takes you to get the first itty bit of content rendered on the page.
My CMS—without caching—can fully render and deliver any page to a normal user in just under a second. This full-render speed is nearly impossible on JavaScript-heavy projects that fiddle around with the DOM for pretty much everything, like any site that uses Vue, Angular, React, etc. Here's an example case: a typical page of The Verge takes about 8-10 seconds.
In contrast, JavaScript-heavy sites know they take a long time to render, so instead they send a very simple first payload before doing the heavy lifting, to trick the FCP timer. For example, The Verge very quickly paints a plain black background div as soon as possible, before building out the full DOM. This gets it a First Contentful Paint (FCP) time that's faster than I can get—about half as fast as my server-rendered content. Which pisses me the hell off, because it takes about 8x as long to actually see even the first bit of text on their site!
Here's why this is important: FCP is the most important thing to Google when they calculate a webpage's render speed for SEO. Other things like payload size and full paint times matter too, but the #1 metric that you want to optimize for is FCP.
I just can't beat a tiny payload that paints a simple black div in half the time as my entire webpage. This makes FCP times quite dishonest—that metric provides next-to-nothing of value to the user, other than the idea that the page is rendering, even if it will take 10 seconds for the first bit of text to appear. My server-rendered pages shouldn't get dinged for being a bit slower because I don't follow this bad but "important" practice.
This was a great post about how long it actually takes Javascript-heavy sites to reach the point of being interactive/usable, especially when you start considering lower-end phones: The Cost Of...
This was a great post about how long it actually takes Javascript-heavy sites to reach the point of being interactive/usable, especially when you start considering lower-end phones: The Cost Of JavaScript In 2018
I am with you completely. My philosophy has always been that Javascript is like a seasoning, you use it to make your site better, but overusing it ruins the whole thing.
I am with you completely. My philosophy has always been that Javascript is like a seasoning, you use it to make your site better, but overusing it ruins the whole thing.
You're probably running it on higher-end hardware, 'cause it takes my laptop 400ms just to load the main assets. It does load pretty quickly when not subjected to DevTools' scrutiny. Then again,...
In a less scientific but more real-world example, my phone took 3 seconds to load @jmilliken's page the first time and slightly more than 2.5 seconds on a reload. For reference, this comments page...
In a less scientific but more real-world example, my phone took 3 seconds to load @jmilliken's page the first time and slightly more than 2.5 seconds on a reload. For reference, this comments page loaded in 2 seconds.
I disable JavaScript on most websites... (Tildes is an exception). I don't like this whole websites replacing (or becoming) software thing. If something wants to execute code on my computer, then...
I disable JavaScript on most websites... (Tildes is an exception).
I don't like this whole websites replacing (or becoming) software thing. If something wants to execute code on my computer, then it should be something that I intentionally installed, not just a website I happened to visit.
JavaScript for small additions that dont break the site if you're missing it (at least make text load) and HTML + CSS for everything else.
I think it depends. I think, for example, Google Docs genuinely provides me something that a traditional desktop application could not, and provides most of the functionality. Web browsers have...
don't like this whole websites replacing (or becoming) software thing.
I think it depends. I think, for example, Google Docs genuinely provides me something that a traditional desktop application could not, and provides most of the functionality.
Web browsers have somehow realized the dream of Java and Flash--a universal runtime.
And it's great sometimes, because sometimes Idon't want to install an app or an application, and having it as a web app means I don't waste space on my device, I run it in a sandbox that (bar exploits) has very select access to my actual device, and I can use the same one on just about all of my devices.
They (at least the native apps, I haven’t used office online) also don’t support collaborative editing, or the powerful permissions system that google docs has, which is fundamentally based on web...
They (at least the native apps, I haven’t used office online) also don’t support collaborative editing, or the powerful permissions system that google docs has, which is fundamentally based on web technologies (web sockets, oauth, etc)
The native versions of Office do support collaborative editing. And as far as permissions go, that's one thing that's usually taken care of by the filesystem, but for what you're specifically...
The native versions of Office do support collaborative editing. And as far as permissions go, that's one thing that's usually taken care of by the filesystem, but for what you're specifically looking for you'll need to also use Sharepoint (which is included in your Office subscription).
Pages does have collaborative editing on the web. I used it today. (And I would assume that Numbers and Keynote do, also, but I have not used those collaboratively.) And yes, Apple's stuff has...
Pages does have collaborative editing on the web. I used it today. (And I would assume that Numbers and Keynote do, also, but I have not used those collaboratively.) And yes, Apple's stuff has view, comment, and edit capabilities natively and on the web.
Combination of high portability + collaboration + integration with server storage. I use a bunch of different devices, so it's nice that you can start a doc on a macbook and finish it off on a...
Combination of high portability + collaboration + integration with server storage. I use a bunch of different devices, so it's nice that you can start a doc on a macbook and finish it off on a linux desktop.
You could, say, put the word on cloud storage, but then will it look the same when I open it on open office? If I want to collaborate, can I easily edit the same document with everyone who has a google account?
That last one is big. Windows, linux, chromebook, or just an ipad--no matter what the other person has, they can probably open a google doc and edit on it.
I agree with your perspective. The web has a strong security model which is far better than desktop executables. It allows more customization than any other platform. HTML, CSS, and JS are...
I agree with your perspective. The web has a strong security model which is far better than desktop executables. It allows more customization than any other platform. HTML, CSS, and JS are visible-source by default, and require extra effort to obfuscate. Plus, the web isn't owned by a single entity. It won't be replaced tomorrow by a siloed "app store" as we've seen on other platforms.
The web is the ideal platform, and PWAs (powered by JavaScript) are what help power that. That's why I love that Tildes is a website, not an "app".
It's very good. It's not ideal. I prefer to have my data on my station. I prefer to have control over it. I can back it up, I can edit it to my needs, I can delete whatever it has on me...
The web is the ideal platform
It's very good. It's not ideal.
I prefer to have my data on my station. I prefer to have control over it. I can back it up, I can edit it to my needs, I can delete whatever it has on me immediately.
The Web doesn't allow that. At best, it allows you to download a backup (if the app provides such an option), or stores your data – in its proprietary format – in Local Storage.
Open-sourcedness of the Web is a big boon, but it's not the ultimate security. Websites are still able to spy on you against your consent, or send your machine malicious code to execute, even if you may follow it up by looking through its JS base. The only way to permanently protect yourself against this is to disable JS on all sites by default, which I consider extreme. (And I'm telling you this after only ever enabling cookies on per-site basis.)
You still have to look out for fake pages presenting themselves as legitimate site fronts. You still have to consider which links to follow when you search for something more obscure than surface-level. People will still try to abuse your default-to-truth understanding of the world online. Pretty much the same as with desktop apps, isn't that so?
The Web's also enabled us to produce great pieces of software: Google Maps, fora, voice-/videochat, Steam... Many good and mediocre ones, too. Overall, I'd say it's been a boon to humanity to have the Web and see it develop as it did, without a doubt. I'm also persistently worried about how my shit is being handled by the various faceless entities that run the things I use, and few recent developments have made it any easier for me to subscribe to a calmer view of things.
You're right. There are still some things I would still change. Though we are getting closer to my idealized vision each year. For a long time I've had this idea of webapps acting as packages that...
It's very good. It's not ideal.
You're right. There are still some things I would still change. Though we are getting closer to my idealized vision each year.
I prefer to have my data on my station. ... The Web doesn't allow that. At best, it allows you to download a backup (if the app provides such an option), or stores your data – in its proprietary format – in Local Storage.
For a long time I've had this idea of webapps acting as packages that could be downloaded and shared without a central authority. Those authorities would still exist, but they wouldn't be the only way to view content.
Pick a random webapp like regexr. It's entirely JS-driven with no dependence on a server. It could feasibly be downloaded and saved to a device like a Chromebook where it could live in perpetuity, with no risk of being taken down or experiencing link rot.
I find this idea attractive because it solves issues of dependence and data sovereignty in one fell swoop. We're getting closer to that point with PWAs and the Web Packaging API, but it's not quite realized. Signed exchanges could ensure data consistency when sharing webapps between users.
I think it's a neat idea. I also think rights holders are probably going to muck it up, but I'll hold out hope.
The current web isn't tooled for this. The client and server are tightly coupled. In a funny way this move to React and JS-based webapps are loosening the dependence on servers, which gives more control to the client. Instead of servers generating the whole page, they're beginning to act more like APIs that can be reached for updates. Even Google Maps can work offline if you download maps ahead of time.
You still have to look out for fake pages presenting themselves as legitimate site fronts.
Phishing sucks. We've found a lot of ways to mitigate these issues, but it'll probably never be a solved problem. I'd say it's not something inherent to the web, though it is made easier through the web's inherent sharability. Native applications have no concept of linking to each other in the way that the web does, which makes them act as isolated islands most of the time. It takes a lot more work to be phished by an application.
Anything sharable though means you're only ever one click away from a bad actor. It could be a website, or email, or social media post. I can't tell you how many fake "Elon Musk's Bitcoin giveaways" I've seen on Twitter.
It's something I think we'll need to continue iterating on as better heuristics and trust networks become available.
This is very much the reasoning I hold onto while developing Intergrid, in its current local mode. You're still in control of your data. I'm going to move on to a point where you can even back it...
Pick a random webapp like regexr. It's entirely JS-driven with no dependence on a server. It could feasibly be downloaded and saved to a device like a Chromebook where it could live in perpetuity, with no risk of being taken down or experiencing link rot.
This is very much the reasoning I hold onto while developing Intergrid, in its current local mode. You're still in control of your data. I'm going to move on to a point where you can even back it up, so that if you run out of drive space, or the browser crashes, or I fuck up the migration process, you could still have your stuff.
It's also why I'm somewhat hesitant to move any further with the prognosed server-side access-from-anywhere mode where your notes may be stored onto a server (if you choose to do so) so that you could get ahold of it without being restricted to a single browser on a single device. This relegates control of your data to me entirely. It's a lot of responsibility: I know how dearly I hold onto my notes.
(I know I'd be livid to lose my notes because I have been. One extension I used to use up until very recently replaced the new tab screen with a note-taking mini-app that saved data between session. I could pop in, jot a thought down, close the tab, and continue with the workflow.
Updating to v2, however, didn't feature a migration function, which led me to think I'd lost all of my temporary thoughts – thoughts that, by their nature, I chose to relegate to a more permanent memory. It also led me to leave an angrily-worded issue on the extension's GitHub page. The dev's excuse was "But I only use it for temporary stuff anyway, I didn't think anyone used it differently". Which is, like... your work as a dev to find out.)
It also means there are more links in the chain that can break: the server itself, the backups, the connection between browser instance and the server... It means neither you nor I have to make a mistake, or even suffer a force majeure, for something to go wrong.
It's why I think about stuff like this: at some point, I have to. Otherwise, I'm making terrible software. It's become all too common in today's world to make terrible software as long as you're making money off of it, and it's not a mistake I'm willing to make.
Native applications have no concept of linking to each other in the way that the web does, which makes them act as isolated islands most of the time.
For what it's worth, PWAs can work in offline mode and send push notifications. Though Tildes isn't currently designed to work that way. There's no replacement for a native UI though. It would...
For what it's worth, PWAs can work in offline mode and send push notifications. Though Tildes isn't currently designed to work that way.
There's no replacement for a native UI though. It would have to be a website through and through.
My thoughts on web technologies are rather... Churchillian. It’s the worst tech stack, except for all the others. (If you really want a laugh, go talk to an engineer who works on one of the...
My thoughts on web technologies are rather... Churchillian.
It’s the worst tech stack, except for all the others.
(If you really want a laugh, go talk to an engineer who works on one of the JavaScript VMs: many of them hate the language itself, they just like working on JITted, garbage collected VMs!)
Completely speculating here, but I think that, for some of them at least, their code runs far enough away from the front-end that they’re just operating on bytecode by that point.
Completely speculating here, but I think that, for some of them at least, their code runs far enough away from the front-end that they’re just operating on bytecode by that point.
Good article. I think on some level I understood this, but hadn't put it into words before. That's a useful distinction and a really valid reason to consider React (or Vue, Angular, Svelte, whatever).
Good article.
There is an entire category of bugs which are now impossible for us to have in our app: sources of truth being out of sync.
I think on some level I understood this, but hadn't put it into words before. That's a useful distinction and a really valid reason to consider React (or Vue, Angular, Svelte, whatever).
JavaScript pushes my buttons immensely—we have a resentful, adversarial relationship. I am an odd duck in that I happen to like server-side rendered pages (PHP, ftw), and I go to great lengths to use JavaScript as little as possible—unless I need to expose bits of local browser functionality, like native share sheets. The grand majority of the sites I maintain have less than 10 lines of JavaScript, and I like it that way.
However, I have one major bone to pick, because it hurts me and my (quite reasonable) design style. It's First Contentful Paint (FCP). FCP is the score (in seconds, lower is better) in how long it takes you to get the first itty bit of content rendered on the page.
My CMS—without caching—can fully render and deliver any page to a normal user in just under a second. This full-render speed is nearly impossible on JavaScript-heavy projects that fiddle around with the DOM for pretty much everything, like any site that uses Vue, Angular, React, etc. Here's an example case: a typical page of The Verge takes about 8-10 seconds.
In contrast, JavaScript-heavy sites know they take a long time to render, so instead they send a very simple first payload before doing the heavy lifting, to trick the FCP timer. For example, The Verge very quickly paints a plain black background div as soon as possible, before building out the full DOM. This gets it a First Contentful Paint (FCP) time that's faster than I can get—about half as fast as my server-rendered content. Which pisses me the hell off, because it takes about 8x as long to actually see even the first bit of text on their site!
Here's why this is important: FCP is the most important thing to Google when they calculate a webpage's render speed for SEO. Other things like payload size and full paint times matter too, but the #1 metric that you want to optimize for is FCP.
I just can't beat a tiny payload that paints a simple black div in half the time as my entire webpage. This makes FCP times quite dishonest—that metric provides next-to-nothing of value to the user, other than the idea that the page is rendering, even if it will take 10 seconds for the first bit of text to appear. My server-rendered pages shouldn't get dinged for being a bit slower because I don't follow this bad but "important" practice.
This was a great post about how long it actually takes Javascript-heavy sites to reach the point of being interactive/usable, especially when you start considering lower-end phones: The Cost Of JavaScript In 2018
I am with you completely. My philosophy has always been that Javascript is like a seasoning, you use it to make your site better, but overusing it ruins the whole thing.
I agree. I use NoScript and the amount of shit that a single page pulls in is insane.
Very good point. These “first skeleton” renders never even fucking line up with the final rendered page. It’s so stupid.
You're probably running it on higher-end hardware, 'cause it takes my laptop 400ms just to load the main assets.
It does load pretty quickly when not subjected to DevTools' scrutiny. Then again, so does Intergrid, and it's 90% JS.
In a less scientific but more real-world example, my phone took 3 seconds to load @jmilliken's page the first time and slightly more than 2.5 seconds on a reload. For reference, this comments page loaded in 2 seconds.
I disable JavaScript on most websites... (Tildes is an exception).
I don't like this whole websites replacing (or becoming) software thing. If something wants to execute code on my computer, then it should be something that I intentionally installed, not just a website I happened to visit.
JavaScript for small additions that dont break the site if you're missing it (at least make text load) and HTML + CSS for everything else.
I think it depends. I think, for example, Google Docs genuinely provides me something that a traditional desktop application could not, and provides most of the functionality.
Web browsers have somehow realized the dream of Java and Flash--a universal runtime.
And it's great sometimes, because sometimes Idon't want to install an app or an application, and having it as a web app means I don't waste space on my device, I run it in a sandbox that (bar exploits) has very select access to my actual device, and I can use the same one on just about all of my devices.
They (at least the native apps, I haven’t used office online) also don’t support collaborative editing, or the powerful permissions system that google docs has, which is fundamentally based on web technologies (web sockets, oauth, etc)
The native versions of Office do support collaborative editing. And as far as permissions go, that's one thing that's usually taken care of by the filesystem, but for what you're specifically looking for you'll need to also use Sharepoint (which is included in your Office subscription).
This is good to know! I guess it’s been a while since I checked in on this stuff.
Pages does have collaborative editing on the web. I used it today. (And I would assume that Numbers and Keynote do, also, but I have not used those collaboratively.) And yes, Apple's stuff has view, comment, and edit capabilities natively and on the web.
Combination of high portability + collaboration + integration with server storage. I use a bunch of different devices, so it's nice that you can start a doc on a macbook and finish it off on a linux desktop.
You could, say, put the word on cloud storage, but then will it look the same when I open it on open office? If I want to collaborate, can I easily edit the same document with everyone who has a google account?
That last one is big. Windows, linux, chromebook, or just an ipad--no matter what the other person has, they can probably open a google doc and edit on it.
I agree with your perspective. The web has a strong security model which is far better than desktop executables. It allows more customization than any other platform. HTML, CSS, and JS are visible-source by default, and require extra effort to obfuscate. Plus, the web isn't owned by a single entity. It won't be replaced tomorrow by a siloed "app store" as we've seen on other platforms.
The web is the ideal platform, and PWAs (powered by JavaScript) are what help power that. That's why I love that Tildes is a website, not an "app".
It's very good. It's not ideal.
I prefer to have my data on my station. I prefer to have control over it. I can back it up, I can edit it to my needs, I can delete whatever it has on me immediately.
The Web doesn't allow that. At best, it allows you to download a backup (if the app provides such an option), or stores your data – in its proprietary format – in Local Storage.
Open-sourcedness of the Web is a big boon, but it's not the ultimate security. Websites are still able to spy on you against your consent, or send your machine malicious code to execute, even if you may follow it up by looking through its JS base. The only way to permanently protect yourself against this is to disable JS on all sites by default, which I consider extreme. (And I'm telling you this after only ever enabling cookies on per-site basis.)
You still have to look out for fake pages presenting themselves as legitimate site fronts. You still have to consider which links to follow when you search for something more obscure than surface-level. People will still try to abuse your default-to-truth understanding of the world online. Pretty much the same as with desktop apps, isn't that so?
The Web's also enabled us to produce great pieces of software: Google Maps, fora, voice-/videochat, Steam... Many good and mediocre ones, too. Overall, I'd say it's been a boon to humanity to have the Web and see it develop as it did, without a doubt. I'm also persistently worried about how my shit is being handled by the various faceless entities that run the things I use, and few recent developments have made it any easier for me to subscribe to a calmer view of things.
You're right. There are still some things I would still change. Though we are getting closer to my idealized vision each year.
For a long time I've had this idea of webapps acting as packages that could be downloaded and shared without a central authority. Those authorities would still exist, but they wouldn't be the only way to view content.
Pick a random webapp like regexr. It's entirely JS-driven with no dependence on a server. It could feasibly be downloaded and saved to a device like a Chromebook where it could live in perpetuity, with no risk of being taken down or experiencing link rot.
I find this idea attractive because it solves issues of dependence and data sovereignty in one fell swoop. We're getting closer to that point with PWAs and the Web Packaging API, but it's not quite realized. Signed exchanges could ensure data consistency when sharing webapps between users.
I think it's a neat idea. I also think rights holders are probably going to muck it up, but I'll hold out hope.
The current web isn't tooled for this. The client and server are tightly coupled. In a funny way this move to React and JS-based webapps are loosening the dependence on servers, which gives more control to the client. Instead of servers generating the whole page, they're beginning to act more like APIs that can be reached for updates. Even Google Maps can work offline if you download maps ahead of time.
Phishing sucks. We've found a lot of ways to mitigate these issues, but it'll probably never be a solved problem. I'd say it's not something inherent to the web, though it is made easier through the web's inherent sharability. Native applications have no concept of linking to each other in the way that the web does, which makes them act as isolated islands most of the time. It takes a lot more work to be phished by an application.
Anything sharable though means you're only ever one click away from a bad actor. It could be a website, or email, or social media post. I can't tell you how many fake "Elon Musk's Bitcoin giveaways" I've seen on Twitter.
It's something I think we'll need to continue iterating on as better heuristics and trust networks become available.
This is very much the reasoning I hold onto while developing Intergrid, in its current local mode. You're still in control of your data. I'm going to move on to a point where you can even back it up, so that if you run out of drive space, or the browser crashes, or I fuck up the migration process, you could still have your stuff.
It's also why I'm somewhat hesitant to move any further with the prognosed server-side access-from-anywhere mode where your notes may be stored onto a server (if you choose to do so) so that you could get ahold of it without being restricted to a single browser on a single device. This relegates control of your data to me entirely. It's a lot of responsibility: I know how dearly I hold onto my notes.
(I know I'd be livid to lose my notes because I have been. One extension I used to use up until very recently replaced the new tab screen with a note-taking mini-app that saved data between session. I could pop in, jot a thought down, close the tab, and continue with the workflow.
Updating to v2, however, didn't feature a migration function, which led me to think I'd lost all of my temporary thoughts – thoughts that, by their nature, I chose to relegate to a more permanent memory. It also led me to leave an angrily-worded issue on the extension's GitHub page. The dev's excuse was "But I only use it for temporary stuff anyway, I didn't think anyone used it differently". Which is, like... your work as a dev to find out.)
It also means there are more links in the chain that can break: the server itself, the backups, the connection between browser instance and the server... It means neither you nor I have to make a mistake, or even suffer a force majeure, for something to go wrong.
It's why I think about stuff like this: at some point, I have to. Otherwise, I'm making terrible software. It's become all too common in today's world to make terrible software as long as you're making money off of it, and it's not a mistake I'm willing to make.
Do beware if you think antivirus is for wimps.
For what it's worth, PWAs can work in offline mode and send push notifications. Though Tildes isn't currently designed to work that way.
There's no replacement for a native UI though. It would have to be a website through and through.
Why?
My thoughts on web technologies are rather... Churchillian.
It’s the worst tech stack, except for all the others.
(If you really want a laugh, go talk to an engineer who works on one of the JavaScript VMs: many of them hate the language itself, they just like working on JITted, garbage collected VMs!)
How does one reconcile this? Working on something you outright hate because it affords you the opportunity to work on something you enjoy.
Completely speculating here, but I think that, for some of them at least, their code runs far enough away from the front-end that they’re just operating on bytecode by that point.
Good article.
I think on some level I understood this, but hadn't put it into words before. That's a useful distinction and a really valid reason to consider React (or Vue, Angular, Svelte, whatever).