[cuffe]

That's a fair concern and something we're working on improving every day! It's fairly common when you consider Retool in the context of other development platforms. VSCode is a 200MB download and is considered small in the desktop space. Even gdocs is ~30MB.

For context, these resources are cached on your machine. So you should find that the actual data transferred significantly decreases after the first visit.

[chrismorgan]

> VSCode is a 200MB download

I presume that figure will be including a full browser, which is obviously inapplicable if you’re opening it in an existing browser, as you can and as the cited page is.

For comparison, on Arch Linux, the code package is a 15 MiB download, 90 MiB installed, and depends on electron22 (that is, it doesn’t include a browser itself).

> and is considered small in the desktop space.

Citation needed. I don’t think anyone reasonable would consider it small, not by a long shot. Not as huge as some very large things, sure, but certainly not small.

As for Google Docs, I hope no one uses Google stuff as an example of good or justifiable largeness. I can’t speak for Google Docs at all, but Gmail is one that I was historically somewhat familiar with, and around five years ago it was generally around 10× the download size and memory usage of Fastmail’s webmail on reasonably similar functionality (with one having more in one direction and the other more in another direction), and I know a more recent change made things at least twice as bad, though they could have clawed that back by now, and Fastmail resource requirements have definitely increased somewhat since.

[csomar]

> It's fairly common when you consider Retool in the context of other development platforms. VSCode is a 200MB download and is considered small in the desktop space. Even gdocs is ~30MB.

Are you even reading the parent comment? He is pointing to the login page. I don't understand the comparison with VSCode.

[tipiirai]

> something we're working on improving every day!

Great to hear that! There is hope to frontend obesity crisis. What actions have you done to slip down the login page to 6MB? How large was it in the beginning? What is the bulk of that file? I mean React framework would span only 0.1% of that room.

[cuffe]

I checked in with an engineer who’s focussing on app performance. You're right that this screen should not be 6MB. One part of the bloat is due to our webpack configuration. In lighthouse, you can see that >50% of the app.js file is unused for login. Most of this is actually used for the app after login.

We’re working on getting this down significantly but, that being said, the login page isn’t our highest priority. It’s the first thing customers see, but >99% of the time, they’ll already be logged in and navigate straight to the apps page, or a specific Retool app. For these pages, we’ve:

1. re-written our core runtime to avoid excessive message passing with iframes (up to 75% faster page load for slowest apps)

2. parallelized resource fetching with JS execution

3. cached app graph information in IndexedDB

4. tweaked webpack chunking strategy to avoid very small JS/CSS chunks

5. optimized resource fetching to avoid over fetching

Hope that’s helpful context. Definitely let me know if you have thoughts/other ideas

[meowtimemania]

I imagine they have a huge task list with a lot of higher priority tasks than reducing the js bundle. Sure it'd be nice, but it's not what users most want.