How about "Every GUI toolkit out there trying to avoid using web tech is going to end up implementing a half-baked implementation of CSS", to coin a phrase.
"You want a button? you have to style a div to get what you want". "You want to center an element vertically? You have to use a table. You have to use these css hacks." "You want to debug the component you've written? Enjoy diving through the div soup".
Of course, there's nothing stopping us from being able to use just a Canvas/WebGL/etc.. based frameworks. Hell even the imgui, qt etc.. have webassembly/webgl targets. But so far, they seem to do badly when it comes to content addressability, accessibility and search engine optimization.
The only good things I have to say about electron: They have decent free tooling that makes producing cross platform binaries easy/easier than the native alternatives. Accessing http resources in javascript is nicer than trying to do the same in C++/Java/etc... The latter is a very important consideration in this day and age.
We try, we can, and we do. Successfully.
> "You want a button? you have to style a div to get what you want". "You want to center an element vertically? You have to use a table. You have to use these css hacks." "You want to debug the component you've written? Enjoy diving through the div soup".
Honestly I don’t think you’re entitled to an opinion on this given you obviously haven’t done anything web related in the last 20 years. I mean, even <button> was there from the beginning. Flexbox layout itself is almost 10 years old now. CSS hacks are mostly unheard of since the death of Internet Explorer 9.
My point is not that you can't do it. It is about what kind of abstractions people have hacked past to beat a document into behaving like an application.
That's why I think every couple of years people keep reinventing the wheel to accomplish the same basic things. JQuery-Ui, Sencha, Angular, React, Vue, Svelte etc... Inline styling was a sin. Then it's the recommended practise. Not even sure what's hip these days in what framework.There is a reason why your actual application abstractions get lost when you inspect an element in developer tools.
I'm well aware of button tags and i am also aware of the reasons why people styled div and anchor elements to behave like buttons in the codebases I've dealt with. They had good reasons why they did those things the way they did.
If you reread my above comment, You'd see how I've also mentioned the tradeoffs of actually using proper ui/application development libraries and frameworks to make "Web Applications".
But if one is making an electron application, search engine discoverability and content addressability bring absolutely nothing to the table and one might as well use a more appropriate framework.
No, you don't, there's a <button> tag. If you don't like the default button style, then yes, you'll need to style it. But that goes for any UI framework.
In my experience the key to solving accessibility etc, when building out a canvas-based web UI, is to work with the DOM instead of trying to replace it. Use <input> to control the placement and display of graphical elements, <button> elements to start/stop animations, etc; make good use of DOM events to track user movement/interaction across the canvas; tie clickable actions to real <a> elements instead of trying to reinvent them. Graphical text also needs to be reflected back into the DOM. Good use of ARIA also helps. Etc. And don't be afraid to tap into CSS --variables or even HTML data- attributes: not everything needs to be defined in the JS (or WASM-enabled language of choice) canvas code if the end result - a <canvas> UI or infographic - is destined to live in a web page.
Proof-of-concept of an accessible design system: https://codepen.io/kaliedarik/project/editor/DVeMVj
Proof-of-concept of an accessible set of related graphs: https://codepen.io/kaliedarik/project/editor/AMVKPx
Ancient knowledge lost to the druids in the mountains and dead trees instead of TikTok tutorials.
This mage will always pick native over Web when given the option, even though Web has paid the bills most of the time since the last 25 years.
I get them, but I'm just not interested anymore with 3 desktop and 2 mobile platforms to think about. Sure it makes sense sometimes, but this should be fun.
Then where is it?
Also, I can make a standalone app in a few hours using Electron. I guess it would take me more than a few weeks with Delphi, given that I don’t know anything about it. So your point might just be that you know Delphi and not JavaScript.
Of all people, tech workers and enthusiasts should know that being superior doesn't ensure survival.
Are there even Delphi enthusiasts still, or is it just nostalgia? Would the people that claim Delphi is superior use it?
There are.
There is a major commercially relevant DAW produced in Delphi. You can figure out which one.
> I believe Electron and web technologies are superior for UIs given their pragmatism and ubiquity.
This opinion is questionable given a clearly narrow view. Outside of this bubble they aren’t ubiquitous.
There are plenty of LOB apps still used and maintained in VB6. One of the most heavily used applications in the US federal government is a C++Builder app (the C++ RAD counterpart to Delphi) - it is a piece of crap, but that’s a factor of the authors not the language - and when it was first released more than 20 years ago it started up in a few seconds on hardware at the time with slow spinning disks! Looking at the vast majority of LOB web apps - nothing has gotten better on that front.
One of the employees they lured away was Anders Hejlsberg, former chief architect of Delphi, which built C# at Microsoft. WinForms had an uncanny resemblance to VCL.
Before that Microsoft had tried to extend-embrace-extinguish Java with J++, but got sued by Sun into submission.
MS were utter scum back then, but Borland’s mistakes certainly didn’t help either.
Of course, 99% of the time the server and client are ran together, so you don't notice it is distributed. But that doesn't mean it isn't.
I can understand the appeal and advantages of using native GUI tech. Really. But there is a reason people use stuff like Electron/Tauri/Wails. Web tech has seen so much investment, and as a result, you now basically have a app platform that runs anyhwere, offers a huge ecosystem and a great developer experience. Which I never found to be matched in any other GUI toolkit.
If there was a GUI toolkit that offered me all of this without requiring the bloat of a browser, then I would switch in an instant. It's just not there.
I never missed any GUI builder. Browser dev tools are phenomenal IMO, you can drag&drop elements across your layout, change any part of your styles and instantly see the effects, measure rendering performance, memory consumption, debug your Javascript or simulate different screen sizes.
About React, nobody forces you to use it. There is a myriad of frontend frameworks, at all levels of complexity. If you feel your app is so simple that you don't need any framework, you can do without. Frameworks (and again, there is a huge world outside React!) came up because they make managing state in complex UIs easier.
"In a few hours instead of weeks" I'd argue that the web stack only takes less time, not more.
JavaScript is popular because developers like it, because it works well, not because some "large corps" "push" for things to happen. There are more than scattered evidences to show that.
Next time, come up with something better and more convincing when hating the web stack.
For better or worse, but the reality is nobody wants them anymore. Branding is a thing. When a client wanted something different you used to tell them "You can't have that" and they had to take it, because there was no other option.
The instant web enabled and normalized arbitrary UIs, "You can't have that" Delphi people simply went out of business. Because it turned out Delphi was far inferior at doing what people actually wanted.
What people think they want and what would make them happier and productive in the long run are different things. They buy junk food and complain they don't feel well. They buy Marvel movies, but in the long run stop going to the theater because movies aren't interesting anymore. Modern web apps are basically the incarnation of that principle.
Are people really happier and more productive with shitty web apps? Because it seems like everyone complains about Slack, Teams, etc. Google Docs certainly doesn't have the die-hard fans Word Perfect still has. Apple still collects quite a premium remembering that people don't know what they want and need people with judgment to make decisions for them.
Were you actually there in the 90s and 00s or are you just imagining how things could have been?
I personally developed fully skinned UIs in Delphi’s cousin, C++ builder on Windows in the late 90s and in the 00s. In addition to that, VCL apps had a rich palette of drag & drop widgets, including commercial products that were better than anything the competition was offering, including Microsoft.
I used a lot of Windows apps over the years and literally everything from custom windows shapes, colors and background, to custom widgets and cursors, etc I’ve ever seen was possible to develop in Delphi or C++ builder.
”The instant web enabled and normalized arbitrary UIs, "You can't have that" Delphi people simply went out of business. Because it turned out Delphi was far inferior at doing what people actually wanted.”
Delphi was mismanaged by Borland, sabotaged by Microsoft and they charged a ton of money for the software. Starting with WinForms and C# MS finally had a reasonably competitive alternative to offer.
The web had nothing to do with Delphi’s decline. In the 00s we used a combination of back-end languages with some JS for enhancement and Flash for special cases or multimedia-heavy sites. Macromedia Flash remained the most capable web-based technology for a long time after Delphi was already in decline. As a former Flash developer, I can say confidently that Flash and Delphi/C++ Builder served different use-cases and were not competing with each-other.
Additionally, UI work on the web is pretty much only CSS. React doesn't handle drawing elements, it delegates it to the browser. React is the easy part of drawing UIs. You could also make a fancy DSL in Rust for Qt and say "look how bad the web is my UI runs 50 times faster clearly Rust is better at rendering UIs", but we both know that's a lie.
Also, CSS is an awful wart and alternatives that have popped up like Compose's Modifier system and CompositionLocals are infinitely better.
The problem is it's not guarantee, and it's way more expensive and hard.
Hence electron being so popular.