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

Avin,

Visual Studio Code (VSC) [a very nice if somewhat heavy weight editor] is
written in part using the Electron Framework {
https://en.wikipedia.org/wiki/Visual_Studio_Code} so it's using Node.js and
the Blink rendering engine as well as C++ and C#. It's *not* using Atom,
nor can it be considered a browser by any definition. VSC is a traditional
desktop application complete with it's own UI aimed squarely at the
desktop. When you close it, you are stopping the application. If you open
multiple windows, you are running multiple instances. It's just makes use
of traditional web technologies in its development.

Just thought I would clear that up,

rik.

On Tue, Jul 30, 2019 at 10:37 PM Avin Kavish <avinkavish(at)gmail(dot)com> wrote:

> 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
>>>
>>