I've been heads down on Chromium + Electron performance with my app around a personal knowledge repository:
Electron has been great for this but it can be slow.
We have to render PDF and HTML documents for annotation and this part can get overwhelmed if I lock up the main thread.
We still have a lot of work to go with threads and web workers to make this stuff easier I think. It's possible to do but it's definitely not easy.
Also reminds me on https://news.ycombinator.com/item?id=19038092 . I wonder if in the future we'll look at excessive JS bloat as we look at annoying pop-ups today.
It's great to seeing WebKit folks thinking along the same lines, and I hope to be able to discuss with them. Coalitions -- like the Mozilla/Chrome work on TLS adoption -- are critical in making progress in large ecosystems.
looks like it picked up on Jan 3 according to that PR?
Try telling your marketing department that they can't integrate third party scripts through Google Tag Manager, or a VP that the SDK for that third party service they championed is too large and the project will have to be shelved. Or put a pause on a critical project because the application is approaching the hardcoded JS limit and another department shipped before you did.
Hardcoded limits are the first tool most people reach for, but they fall apart completely when you have multiple teams working on a product, and when real world deadlines kick in. It's like the corporate IT approach to solving problems — people can't break things if you lock everything down. But you will make them miserable and stop them doing their job.
Secondly: For decades computers operated with extreme limits on their available memory and their processing capacity, relative to today's computers. Despite this, people managed to write software, even including companies with marketing departments and idiot VPs. It might take these people a while to accept that they can no insist on pushing whatever garbage they want, because the cost is borne entirely by the end user, but eventually they will. Or they won't, and these dysfunctional companies will die out. Either way, users win.
That is quite small actually... My application (internal use, not consumer facing, so no panic) has a single packed script file, that is around 100KB.
If this is the future, I know a lot of web apps that will need retooling. That is just enough space for react (+react-dom). We’ll have to split up react and web apps themselves in future apps if chrome goes this route; although I suppose that’s marginally better for caching performance.
For example, non-minified bootstrap.js is more than that. Just as a data point.
This will break a bunch of the web. I'll be curious to see how this gets worked out as the work progresses.
The restrictions are wire size. `bootstrap.min.js` is ~10KiB on the wire, which means it comfortably fits (as do jQuery, most analytics packages, etc.).
That said, the prototype does break a lot of the web, but that's not a crisis. The intent isn't to have this rolled out everywhere against unwitting content, but rather (like TLS), to let developers opt-in to a single set of rules when they see value. There are also places (e.g. PWAs) where the browser-imposed quality bar needs to be high. Blocking PWA install for sites that don't send the opt-in header seems like a reasonable place to start.
Luxon, I believe, is a similar story.
You need to make a business case that your whole application is modularly composable.
Some application might fit under this umbrella, but there are other stuff that don't, like a pdf-render, or something like google slides, which as I just checked, the core editor js is bundled in a single js file and as large as 1.4MB.
And ofc you’d naturally just attribute this as an artifact of optimization, just as single-file packing was. Which it is, given http 2/3
Splitting probably makes sense only for an infrequently used feature, like video chat in an app like Gmail or Slack.
(Per-script max size: 50KiB,
Total script budget: 500KiB)
The apps frensy was over years ago. Nobody wants an app anymore.
News to me. You sure you’re not just projecting your personal preference?
And I work with software. None of my colleagues wants to work with or test anything not strictly web-based.
If that's true, I'd be willing to bet there's some extreme self-selection going on. Which is fine, but I'd be very careful about generalizing your experience outside of your immediate social circle.
Citations needed. I, for one, like apps.
Anything worth it is native.
Apologies if this is a really ignorant question as I know very little about browsers/front end development.
While I'm sure there is a lot of complexity there that I'm not considering to avoid messing with legitimate usages of tab closing event handling by real apps, it would be nice if there were some kind of like alternate tab close input (eg. hold ALT or SHIFT, or both while clicking the tab 'X') where the user is signalling the intent that "yes, I absolutely want to close this tab, no matter what, kill it with extreme prejudice".
If such a thing exists, which it might, someone please correct me by telling me what it is.
I didn't make this feature; I don't have the answer to your question. It was intuitive enough for me to find it on my own without reading any documentation. So, shrug.
Feels a bit past being a proposal.
Minus the extensions, migrating everything else should be easily accomplished via importing and should only be a few clicks in a wizard.
Then you start moving your stuff, you install extensions and while fighting with your habits from old browser ux you collect history, cookies and all that stuff.
Then some time passes and you're looking back at your old browser, now with cleaned profile, so shiny and fast :)
Modern camera's take pictures measured in megabytes, and you're suggesting the per image max be 200kb, and total images to be 400kb?! Two crappy quality images would blow that out of the water (Heck a single crappy image could).
I get that this is a prototype, and seems to be intended for mobile devices, etc. But those limits are already something you'd have to work for, I'd argue it's near impossible at 5x less resources.
tl;dr by todays standards a 5x reduction in those limits is just code golf.
The per-image limit is currently set at 1MiB (not 200KiB).
Hope that helps.