We reduced the size of our JavaScript bundles by 33%(dropbox.tech)
dropbox.tech
We reduced the size of our JavaScript bundles by 33%
https://dropbox.tech/frontend/how-we-reduced-the-size-of-our-javascript-bundles-by-33-percent
9 comments
Ya, basically every site where they load inline advertisements of an unknown height (or maybe they intentionally leave the height out of the CSS so you accidentally click on the ad).
I have to think it's often intentional... It's the most annoying thing tapping/clicking and then the ad url comes up instead of what you were expecting.
They added a neat feature recently where they have a popup asking you something stupid, with a button you have to click to hide it. Then, exactly as the page seems loaded enough for you to attempt tapping the button, a new popup appears from google asking if you want to share your google account with twitter, with the "agree" button in the exact position of the previous button. It didn't work on me, but seems like a pretty cool doxx nonetheless.
one time I worked at a company that shipped an app with a version of this bug that caused people to charge money to the wrong individual, because sometimes the buttons would shuffle right before the click
[deleted]
It amuses me that there is so much criticism of the modern web - but a modern app is massively larger.
The dropbox app is 237.7 MB - that's so much more insane to me.
Of course that app size does include all the assets - images, icons, fonts, etc which the JS bundle for the site doesn't include. But its still insanely large to me.
I don't mean this as a criticism of the app size - just that web/android/ios all are platforms which require a large amount of code and assets to be uniform and available everywhere - web, desktop, phone, tablet, etc.
The dropbox app is 237.7 MB - that's so much more insane to me.
Of course that app size does include all the assets - images, icons, fonts, etc which the JS bundle for the site doesn't include. But its still insanely large to me.
I don't mean this as a criticism of the app size - just that web/android/ios all are platforms which require a large amount of code and assets to be uniform and available everywhere - web, desktop, phone, tablet, etc.
>The dropbox app is 237.7 MB - that's so much more insane to me.
I vividly remember "printer drivers" whose installer would take a whole CD.
I vividly remember "printer drivers" whose installer would take a whole CD.
completely agree, i dont have many apps on phone but the average size is over 200mb and they want to update constantly w hehe funny patch notes which is rude considering the bandwidth you expect users to burn updating. i find it completely amazing no one bats an eye on these ( not to mention the mobile data usage )
> It amuses me that there is so much criticism of the modern web - but a modern app is massively larger.
Both of these problems are ridiculous. But the web one is arguably more severe, since you only download an app once.
Both of these problems are ridiculous. But the web one is arguably more severe, since you only download an app once.
With modern caching don’t you also only download the web app once as well? I feel the reason web is worse is more because the download happens right before you want to use it, not ahead of time like app bundles.
I just have to laugh. This website is 6.36MB big, out of which 4.51 MB is Javascript.
Congrats, I guess.
Congrats, I guess.
Yes, there's still a useless 1.85MB. One day we'll find out how to economically shove it all in Javascript/WebASM, and than the website will be perfect.
Yeah, wasm gives me some home... though, I don't think the likes of Blazor is the answer. I can say that Rust+yew is interesting to say the least and there are even better performing options. The yew todomvc[1] example is around 100k total.
I would really like to see a complete component library (something similar to mui.com) for Yew. There are a couple Material Design libraries, but last I checked they are all very incomplete and rough around the edges. Doesn't have to be material, necessarily, just consider mui the nicest, most feature complete UI component library I've ever seen for the web.
Aside: anyone know how to exclude extension resources in devtools network tab?
https://yew-todomvc.netlify.app/
I would really like to see a complete component library (something similar to mui.com) for Yew. There are a couple Material Design libraries, but last I checked they are all very incomplete and rough around the edges. Doesn't have to be material, necessarily, just consider mui the nicest, most feature complete UI component library I've ever seen for the web.
Aside: anyone know how to exclude extension resources in devtools network tab?
https://yew-todomvc.netlify.app/
Of course, it has to display text, images (gasp!), and needs working links (oh!!). Thats at least 150 npm packages already.
If only, create react app is closer to 1500 packages. To be fair, the react team is moving away from CRA. However, they’re pushing people to next.js, which is even bigger.
Next is also primarily maintained by Vercel, and that gives me the creeps as time goes on. Vercel resells other services and ensures Next.js deploys most seamlessly on its own platform. Sure, it's still easy to deploy anywhere, but you will hit edge cases where deep internals are tailored to their own platform. Perhaps I'm too pessimistic here, but I expect that to get worse.
I wouldn't discourage anyone from using it for that reason alone, but I'm not sure I like React's team favouring a commercial-by-proxy framework.
I wouldn't discourage anyone from using it for that reason alone, but I'm not sure I like React's team favouring a commercial-by-proxy framework.
This is what I worth the most as well. In fact, you can already notice the conflict of interest in many of the GitHub issues.
This goes to show that you need to work in the ecosystem to effectively meme on it - I had no idea it was an order of magnitude worse than I thought.
TL;DR, they had a better look at their dependencies, applied code splitting, and used Rollup. They updated their build from the initial 2014 version, at long last.
Something webpack doesn't get right to this day: building consumable libraries.
It has all the bones, and it would be great if it did, as its extremely powerful at manipulating the AST as part of the process etc so you could do some neat optimizations, but it won't output to a standard format, even with experimental ESM output feature enabled, that makes the library reasonably consumable.
Rollup / Vite really excel here but I love competition pushing things forward, meaning webpack having a better library building experience would be a good thing.
It has all the bones, and it would be great if it did, as its extremely powerful at manipulating the AST as part of the process etc so you could do some neat optimizations, but it won't output to a standard format, even with experimental ESM output feature enabled, that makes the library reasonably consumable.
Rollup / Vite really excel here but I love competition pushing things forward, meaning webpack having a better library building experience would be a good thing.
I was actually looking into building a library today with Webpack and ran into similar problems. But could you help me understand what you meant here?
> but it won't output to a standard format, even with experimental ESM output feature enabled,
Are you saying ESM is not a standard format? Or that the ESM output doesn't actually follow standard ESM? Or maybe you meant something else entirely?
> but it won't output to a standard format, even with experimental ESM output feature enabled,
Are you saying ESM is not a standard format? Or that the ESM output doesn't actually follow standard ESM? Or maybe you meant something else entirely?
opposite issue, webpack doesn't output plain ESM code for libraries (IE, no __webpack__require__ etc.). Its both experimental and sometimes completely incorrectly generated, while still generating library code with webpack specific references.
Trying to make ESM actually work in the JS ecosystem is still wildly experimental and incredibly painful. https://blog.isquaredsoftware.com/2023/08/esm-modernization-...
It's bad for them because their support matrix still includes versions of Node and webpack that haven't been in even LTS support for years at this point.
It's great that they want to support such a long tail. I know that makes a lot of developers very happy that they can rely on that.
In my experience ESM is not painful at all if you can rip the bandaid off and drop Webpack 4 (and below) and any version of Node less recent than current LTS. That's a lot easier done in greenfield projects than those that have long tail support matrices to contend. Brownfield projects should get better as more and more of that tail dies off.
It's great that they want to support such a long tail. I know that makes a lot of developers very happy that they can rely on that.
In my experience ESM is not painful at all if you can rip the bandaid off and drop Webpack 4 (and below) and any version of Node less recent than current LTS. That's a lot easier done in greenfield projects than those that have long tail support matrices to contend. Brownfield projects should get better as more and more of that tail dies off.
esbuild any day. JS tooling doesn't need to be written in JS, and when it's not, it's properly blazing fast.
My complaint with esbuild is it doesn't use `tslib` nor does it have its own sharable helpers like it that can be shared across builds, so you have all this repeated code that doesn't treeshake away.
If it did, I'd use esbuild in a heartbeat for libraries.
It also uses generic polling for watchmode, I'd like to see something more robust
If it did, I'd use esbuild in a heartbeat for libraries.
It also uses generic polling for watchmode, I'd like to see something more robust
Can't say I've every used esbuild for watching, mostly because if I'm running in dev mode, I'm going to load "my files", not a bundle. The bundle is only for final delivery, so it needs to pass tests, but that's a precommit step, not a continuous development process.
monorepo setups is where you will likely find this to be more of an issue, especially if you spin up watch mode on several libraries that may be undergoing changes
Vite uses esbuild under the hood. Providing much nicer DX
At this point in my life I think "DX" - if you mean things like performance, reliability, simplicity and maintainability - is inversely proportional to the amount of (transitive) dependencies, layers of abstraction and (only half jokingly) also the percentage of JS that something includes.
I've encountered a pretty back breaking memory leak in vite that has been unresolved for about 2y now. The project I work on that uses vite doesn't need the flexibility, feature set and plugin system that vite offers. It just needs a fast bundler.
I've encountered a pretty back breaking memory leak in vite that has been unresolved for about 2y now. The project I work on that uses vite doesn't need the flexibility, feature set and plugin system that vite offers. It just needs a fast bundler.
esbuild has a decent DX and for some projects (especially libraries) the extra bells and whistles of Vite can be YAGNI.
Depends on what you need, tbh. I looked into Vite briefly but esbuild seemed more obvious/ direct for hooking into the build system.
Yeah.. I think the two things I'd look for first on older codebases would be removing and JS shims and looking for larger libraries like moment and similar that can be removed. Expressly lazy loading any graph/chart libraries helps a lot too.
I'd probably reach for vite or parcel for a bundler, but using Rollup directly is okay.
I'd probably reach for vite or parcel for a bundler, but using Rollup directly is okay.
I know some people still use Dropbox, but tbh it never clicked for me. It went from being a simple cloud solution to a bloated crapware. To my surprise, MS OneDrive performs better than DB, but it's kinda slow at times. Google Drive otoh, is fast but I'd never put all my data there. iCloud is "ecosystem-ware"—you can access it from Android and Windows, for sure, but the UI treats you like a child (maybe it was made for kids). On top of that, Apple is anal in terms of authentication. I don't want to own an iDevice just to login to my cloud. I wonder if there are genuinely decent cloud platforms out there...
At some point, I'm going to really buckle down and try out Seafile (https://www.seafile.com/en/home/). It looks like it's just the good parts of Dropbox, and I can run it on my own hardware/systems.
I would assume most of Dropbox's appeal lies in its cross-platform nature, but for me that's turned out to not add much actual value. I find that I don't really need everything to be everywhere and accessible at all times… no point in most of the things on my daily driver Mac to be accessible from from my gaming desktop or ultrabook used mostly for studying.
On the odd occasion I need something to be mobile-accessible, iCloud does the trick (and if I were to switch to Android, Google Drive would fill that niche). Once a blue moon when I need to get files to other machines on my local network, Syncthing and Snapdrop do the trick.
On the odd occasion I need something to be mobile-accessible, iCloud does the trick (and if I were to switch to Android, Google Drive would fill that niche). Once a blue moon when I need to get files to other machines on my local network, Syncthing and Snapdrop do the trick.
[deleted]
I just use rsync
this is overly simplistic. rsync to where? please tell us more :p
It may be a reference to this famous comment https://news.ycombinator.com/item?id=9224 :)
It depends on your needs. I primarily used Dropbox as a backup destination for a range of directories on my computer.
About a decade ago, this worked great. All I had to do was create a symlink within my Dropbox and the directories were backed up.
Then a few years ago, Dropbox stopped supporting symlinks because they “caused problems”. It’s unclear what problems exactly because I’ve never actually heard of anyone who experienced any issues. Nonetheless, the solution was to move the real directories into Dropbox and put a symlink in their original location. This _did_ cause problems, including needing to disable SIP, and breaking navigation in Finder which treats symlinks like shortcuts.
Finally, the latest update completely broke backups for me. Admittedly this was not Dropbox’s fault; they were forced by Apple to use a new API which doesn’t allow the Photos library to be backed up.
I moved my backups to Backblaze B2 and cancelled my Dropbox subscription. Now I use rsync to back up my machine, and utilise Dropbox’s free tier for the small amount of cloud storage I actually need.
Oh, and for the amount of data I back up, B2 is almost an order of magnitude cheaper.
About a decade ago, this worked great. All I had to do was create a symlink within my Dropbox and the directories were backed up.
Then a few years ago, Dropbox stopped supporting symlinks because they “caused problems”. It’s unclear what problems exactly because I’ve never actually heard of anyone who experienced any issues. Nonetheless, the solution was to move the real directories into Dropbox and put a symlink in their original location. This _did_ cause problems, including needing to disable SIP, and breaking navigation in Finder which treats symlinks like shortcuts.
Finally, the latest update completely broke backups for me. Admittedly this was not Dropbox’s fault; they were forced by Apple to use a new API which doesn’t allow the Photos library to be backed up.
I moved my backups to Backblaze B2 and cancelled my Dropbox subscription. Now I use rsync to back up my machine, and utilise Dropbox’s free tier for the small amount of cloud storage I actually need.
Oh, and for the amount of data I back up, B2 is almost an order of magnitude cheaper.
> stopped supporting symlinks because they “caused problems”.
If the reason for that was really written with such vagueness, it's almost certain that there was some sort of vulnerability / Security issue. The most vague, the most serious the issue. If it was just "they cause problems" then someone somehow figured out how to use symlinks to get access to someone else's data.
If the reason for that was really written with such vagueness, it's almost certain that there was some sort of vulnerability / Security issue. The most vague, the most serious the issue. If it was just "they cause problems" then someone somehow figured out how to use symlinks to get access to someone else's data.
It's been a long while since I worked there, but IIRC one of the big issues at the time was that the symlink "support" couldn't actually work properly:
- some users want symlinks to be synced as symlinks (and they might not know it, old Apple file formats have internal symlinks), so their files got corrupted if they were accessed on another computer - some users want the sync client to follow the symlink and copy all the files at the destination, which requires the client to listen to filesystem events for potentially the entire filesystem, which is no longer permitted in many cases
so, not exactly a vulnerability, but a mix of security and product issues.
- some users want symlinks to be synced as symlinks (and they might not know it, old Apple file formats have internal symlinks), so their files got corrupted if they were accessed on another computer - some users want the sync client to follow the symlink and copy all the files at the destination, which requires the client to listen to filesystem events for potentially the entire filesystem, which is no longer permitted in many cases
so, not exactly a vulnerability, but a mix of security and product issues.
> The most vague, the most serious the issue.
It depends. When I was working on security software, any problems that impacted security were explained to customers in great detail.
Problems that were merely embarrassing, though, were always described in the vaguest possible terms.
It depends. When I was working on security software, any problems that impacted security were explained to customers in great detail.
Problems that were merely embarrassing, though, were always described in the vaguest possible terms.
[deleted]
I reduced my JavaScript 100% and experienced no loss of business.
How is the static-text "serving my own blog" business doing these days?
There are bunches of ways to do dynamic sites that don't use any js, and even more that use just a tiny bit of js. For examples of the first, "update on submit" and "long-polling HTML" (you can use CSS to make this like an SPA) come immediately to mind. The first has the advantage of demanding a conversational UI (the UI never changes except when the user expects), and the second has, well, ok, not much, but it gives you a WebSockets-like flow while being compatible with mid-90s tech.
I can't think of any good "update on submit" sites that don't benefit from JS, but I'd love an example to prove me wrong.
Even a forum like HN, an obvious choice for this, benefits from some JS for things like collapsible comments, upvoting/downvoting, etc.
My other thought would be e-commerce checkout workflows, but those benefit from more advanced validation than you can do with HTML alone.
Even a forum like HN, an obvious choice for this, benefits from some JS for things like collapsible comments, upvoting/downvoting, etc.
My other thought would be e-commerce checkout workflows, but those benefit from more advanced validation than you can do with HTML alone.
HN does use js for expand/collapse, but could be using <summary> / <details> native element to do the same thing. Upvote/downvote could use <input type="submit"> instead, no reload required. These have the same fundamental behavior, no js necessary.
If you need conditional behavior based on the response from the server, see my previous comment. None of that requires js. I say this as a person who does js frontend/backend all day, and I really don't have a bias against js like some devs do. I just wish people better knew the platform.
If you need conditional behavior based on the response from the server, see my previous comment. None of that requires js. I say this as a person who does js frontend/backend all day, and I really don't have a bias against js like some devs do. I just wish people better knew the platform.
Pretty sure type="submit" just means that clicking the button triggers form submit (as opposed to a button without type="submit" that woudn't submit the form). Submitting the form reloads the page, there is no way to repevent that without JS.
Hmm, how can you post a form without js and not require sending and loading the full page from the server? I don't think there a way to do a partial form submission?
An iframe could work but it's really messy and likely slow?
Keeping in mind that I'm not advocating this per se but in the spirit of exploration:
In the case of HN ui, no response from the server is strictly necessary on submit, and thus no reload is needed. Hence mentioning <input type="submit"> rather than <form>. You can indicate that the vote was made by using a checkbox and styling appropriately. A submitted comment can be similarly controlled with CSS.
For non-HN cases, you can do long-polling, where the original response from the server is never closed, and thus you can always append new HTML to the end, hiding outdated elements as necessary with CSS.
Example:
In the case of HN ui, no response from the server is strictly necessary on submit, and thus no reload is needed. Hence mentioning <input type="submit"> rather than <form>. You can indicate that the vote was made by using a checkbox and styling appropriately. A submitted comment can be similarly controlled with CSS.
For non-HN cases, you can do long-polling, where the original response from the server is never closed, and thus you can always append new HTML to the end, hiding outdated elements as necessary with CSS.
Example:
<iframe name="do_nothing" style="display:none;"></iframe>
<form action="vote" target="do_nothing">
<input type="submit" name="my_vote" value="up">
<input type="submit" name="my_vote" value="down">
<input type="hidden" name="comment_id" value="234">
</form>Something like HTML-over-the-wire [1]. It means rendering HTML on the server side instead of JSON, and using javascript (mostly) to replace some parts of the current page with some parts of the returned response. It sounds kind of bad, tbh, but it works ok. The inconveniences get offloaded by all the javascript that you no longer need. And someone using a non-js browser still can get a regular form-that-you-send-and-reloads-the-whole-page.
https://hotwired.dev/
https://hotwired.dev/
Sounds like HTMX? So far I have failed to understand the attraction of this solution outside of very small personal projects. Front end is not just a presentational layer - we are rendering _data_, so having business logic on the front end makes perfect sense. I have built many BE template driven websites in the past (early 2000s PHP, then Django) and this approach does not scale well.
What parts of the page do you reload with HTMX when user's state changes? A GET request to retrieve updated page header? Another request to retrieve updated page footer? Another request to reload the dropdown menu below a post? All of which could be rerefencing user's state.
And then do you implement endpoints for literally every partial and propagate state to all these endpoints?
What parts of the page do you reload with HTMX when user's state changes? A GET request to retrieve updated page header? Another request to retrieve updated page footer? Another request to reload the dropdown menu below a post? All of which could be rerefencing user's state.
And then do you implement endpoints for literally every partial and propagate state to all these endpoints?
No familiarity with HTMX, but familiar with the thing I linked. There, you render the whole page on the server side. The js "picks" which parts it needs to refresh by essentially using specific classes/attributes. It is a very "pedestrian" system, really. The fact that the whole page is sent is what makes "graceful degradation" possible.
> Front end is not just a presentational layer
I agree that front is not a presentational layer in all projects, but I also think that most web projects out there are CRUD-like, and for a lot of those, front can be just a presentational layer. I'm just saying that the effort of making front more than that and going the Single Page App route needs to be justified by some business reason - even something vague like "we want to leave the door open releasing a mobile app later so we need an API anyway".
> Front end is not just a presentational layer
I agree that front is not a presentational layer in all projects, but I also think that most web projects out there are CRUD-like, and for a lot of those, front can be just a presentational layer. I'm just saying that the effort of making front more than that and going the Single Page App route needs to be justified by some business reason - even something vague like "we want to leave the door open releasing a mobile app later so we need an API anyway".
It doesn't have to work like that. You can fetch the entire body and then let HTMX or whatever hypermedia lib you're using DOM diff the parts that have changed in place.
Without ads, probably pretty badly.
So you are saying that this is what JavaScript is only good for? Rhetorical question here.
That is not a valid takeaway from what I said at all, rhetorical or not.
[deleted]
The less JS a site uses, the more likely I am to use the site regularly.
sharts(1)
On mobile Twitter/X it happens every time I reload the page.