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
<https://chrome.google.com/webstore/detail/lighthouse/blipmdconlkpinefehnmjammfjpmpbjk>
auditing tool.

On Tue, Jul 30, 2019 at 5:46 PM richard coleman <rcoleman(dot)ascentgl(at)gmail(dot)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(at)pgadmin(dot)org> wrote:
>
>>
>>
>> On Mon, Jul 29, 2019 at 7:31 PM Mark Murawski <
>> markm-lists(at)intellasoft(dot)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
>>
>