These days, there's a lot more boilerplate in most languages. C# was a horrible downgrade.
If you can put up with the documentation, Lazarus/Free Pascal works amazingly well, and is almost as easy as it used to be.
a) GUI programming (for the web) is hard because the core technical stack that's made up of browsers, html, js, and css is abhorrent garbage (I'll get to what I'm comparing it to in a sec). It has incomprehensible standards and almost no compliant implementation that can make it all work together -- after decades, untold millions/billions of dollars, and unbelievable quantities of person-hours.
b) the layer right above that (the frameworks and libraries) changes so often, are so buggy and fragile, and reinvent the same stuff over and over and over again, and a billion frameworks that all poorly do the same crap in slightly different ways get released every month -- usually built by bored engineering teams with nothing else to do or people who didn't exist in the "before times".
c) My first job out of college in the "before times" was building Windows desktop software. With no real internet resources, a couple of books and whatever Microsoft called their C++ visual dev environment software back then I managed to build professional GUI software in a couple months that still runs, looks, and works exactly like it did back then and made out company quite a bit of money. Later on I applied basically the same ideas to some Linux desktop software using Qt and everything worked fine and was easy. Visual Basic, Delphi, heck even Microsoft Access demonstrated that it's so easy that even relatively inexpert people can create complex and reasonably attractive GUIs.
Point is, we had the technology, it wasn't hard to use, and it worked pretty much flawlessly and the web is such a broken disaster of a mess that it's almost rewritten the brains of the entire industry to just Stockholm syndrome themselves into accepting that there must be something hard about GUIs.
It is hard to abstract and tailwindcss for example is an abstraction which goes against it for the sake of bypassing the deeper understanding. But css is powerful, elegant, and keeps moving in the right direction.
Maybe, but consider that possibly the reason why many companies go that route is more to do with financial incentives: it provides for the cheapest option (both in terms of resource costs and time), while still retaining complete control over the use of the software (and consequently their revenue generation). Even ignoring the latter aspect of that, its cheaper to have 1 team build out a single interface than multiple teams each working on platform specific interfaces. Then theres a follow-on reduction in support (and troubleshooting) costs in dealing with platform specific updates, less coordination/communication needed and thus reduced need for management level resources, etc etc. Theres also lower costs in terms of skills the company is hiring.
I'd also extend that to the possibility that the prevalance of tooling such as electron and its kin is a response to a demand for it, rather than arising out of being "best in class".
So best and/or simplest platform... well that depends on whats being measured. From a financial perspective, sure, why not. Other measures though... Im not so sure.
Can you now consider NOT Flutter with respect to the above?
Also, remember Titanium SDK?
thx
I responded to the suggestion that every company was choosing electron (html/css/js) because it was the best and easiest, by pointing out that the reason it might be picked may not have anything to do with simplicity or being the best choice, but rather based on other factors (like financial motivations). Flutter is a different toolkit, and isnt the typical "web page" type building of application UI, and so was outside of the scope of my original response.
I've never used Titanium, but have used similar types of toolkits... all of them, regardless of whether they compile to native apps or not, are (very broadly) generally selected based on the criteria mentioned in my previous comment: why build out different platform native apps when you can largely get by with a web dev(s) building a single app that compiles to the native system? Theres tradeoffs involved, and the typical optimisation in an org is to favour lower cost and/or quicker market time. Theres the "we can do it better later when we have the money to" mentality, except once a system gains enough traction, that perspective changes to "why spend time and budget on changing something thats working". The term "working" though, is subjective... its "working" for the org, but is it truly "working" for the user that is interacting with it?
I too did Windows desktop software with good GUIs using nothing more than MS Visual C++/MFC/ATL and David Kruglinski/Charles Petzold's books (no Internet). There was a learning curve but not too difficult. Later on i moved onto Networking and learnt client/server distributed programming. But when i see what is going on in the Web GUI space i am truly lost. It all seems to be duct-tape and junk. A simple document sharing protocol has been munged to do anything/everything, an ad-hoc language (i.e. JS) has become de-facto GUI language and every kludge under the sun has been employed in the service of event-driven programming just to make something work. This is not Engineering but the very worst of Hacking in the full pejorative sense of the word.
Visual Basic GUIs mostly just worked well when your users had the same resolution as the dev.
AFAIK one place where it fails though is bitmap images - the "picture" container will be scaled but not the bitmap inside it (i think metafile images will be scaled though).
VB was designed at a time when there were monitors not only with different DPIs but some didn't even have square pixels. Windows also had an option for "large fonts" even in Win3.x days which essentially increased the window scaling.
IIRC dialogs defined via resources also use (or can use) the same approach, allowing them to be automatically scaled too.
Of course in practice pretty much every application changed the coordinate mode to pixels and ignored the DPI settings, meaning not only the application didn't scale itself but it also didn't provide information for Windows to do the scaling. This is why more recent versions of Windows lie to applications about the DPI and do bitmap scaling of the window texture in DWM unless they explicitly (via a manifest file) claim they know how to scale themselves (or the user explicitly lets the application scale itself via the executable's compatibility settings).
Like Mark Weiser’s HCI work but down to the pixel/dot/vector size
Surely it is better to target more than one screen size but it seems unlikely to be better to target dozens
Any meaningful results more insightful than “4K, 1080p, 1024p 4:3, iPhone XYZ, popular Android resolution “ would be fascinating
* re-laying out the UI controls when the user resized the app window * nicely handling long-running tasks, with progress updates, allowing user interruption
In both cases the “drag and drop controls, then connect them to each other with a smattering of code” paradigm didn’t work too well.
Also since you were writing code behind control events, you could easily bind 2 buttons to the same function: one button visible on normal state, the other visible in maximized state, etc