Re: pgadmin4 - Use classic style interface, don't launch browser?

On the topic of speed, the current limitation is not imposed by the fact that it is run inside the browser, fyi some really popular and successful apps are web based, even visual studio code. It's more of an architectural and design problem than a platform issue.

I'm not very familiar with the code yet, but I suspect the following could be factors,

• a lack of caching on both the client and the server, 
• excessive amounts of DOM nodes (currently around 4000 at idle), 
• excessive nesting using tables, 
• lack of a view reconciliation library such as React/Angular
• usage of AMD modules making dead-code elimination (tree-shaking) impossible, if asynchronous loading was the intention, webpack supports dynamic imports with ESModules while retaining the benefits of tree-shaking.
• lack of skeleton uis that are perceived as being faster - most top sites do this now making them look faster even if the time to interactive is the same
• waiting on ajax requests before loading UIs, (theory) (the query tool takes 2-3s to open, is this why?)

There's more to discover, I'm still reading through.

Modern UI design philosophy is to react immediately to user response by showing something as close to the real interface as possible and then to load the data asynchronously behind a loading indicator, which is done in some situations but often not convincing enough or not immediate enough. (again, query tool, anywhere between 2-4s till first paint) Anywhere over one second and frustration sets in. 100ms should be the target to keep power users happy.

More info: 
Performance: https://developers.google.com/web/fundamentals/performance/rail

DOM Size: https://developers.google.com/web/tools/lighthouse/audits/dom-size

The best way to identify areas that require improvement is to run the lighthouse auditing tool.

On Tue, Jul 30, 2019 at 5:46 PM richard coleman <rcoleman.ascentgl@gmail.com> wrote:

Dave, 

That's true.  Of course that's the ultimate draw back of the client/server model.  Having just a server isn't enough, you need a client as well.  pgAdmin4 is just the server portion of that model.  It's relying on borrowing someone else's client.  That's frees up quite a bit of resources, not having to write an actual client.  Unfortunately that means you have to deal with all of the limitations; speed, footprint, compatibility, security, capabilities that that entails.  Contrary to the thought in some circles, not everything is amenable to being served through a web browser.  

just one man's opinion.

On Tue, Jul 30, 2019 at 4:10 AM Dave Page <dpage@pgadmin.org> wrote:

On Mon, Jul 29, 2019 at 7:31 PM Mark Murawski <markm-lists@intellasoft.net> wrote:

Would there be a possibility of embedding chromium?  Since of course
it's actively developed and everyone including their pet cat are using
it as a rendering engine these days (including microsoft)  Not sure of
the compatibility with the BSD license would go...

It's technically possible of course (one most, but not all of our supported platforms), but would be a massive amount of work, probably tying up most of my team for months whilst they figure out how to glue all the pieces together into Qt on Windows, Mac and Linux. I'd far rather they were building actual features.

 

--

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company