We reduced the size of our JavaScript bundles by 33%
dropbox.tech
dropbox.tech
On mobile Twitter/X it happens every time I reload the page.
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.
I vividly remember "printer drivers" whose installer would take a whole CD.
Both of these problems are ridiculous. But the web one is arguably more severe, since you only download an app once.
Congrats, I guess.
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 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?
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'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.
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
> 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?
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.
I'd probably reach for vite or parcel for a bundler, but using Rollup directly is okay.
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.
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 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.
- 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.
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.
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.
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.
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>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?
> 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".