4 ms·
No, the DOM will stay for a long time, since CSS is actually a really great way to build UI-s. Last time I checked C/C++ based UI libraries even text selection
by kowdermeister 9y ago
No, the DOM will stay for a long time, since CSS is actually a really great way to build UI-s.
Last time I checked C/C++ based UI libraries even text selection was a problem. If there were a cross platform way to build UI-s as good and feature rich as a modern browser is now, then it will slowly die.
That's the reason we have so many Electron based apps, because it makes UI building really simple.
- rickycook 9y agodrawing the parallel between electron and gui toolkits probably isn’t right. i think there are lots of things at play here. just for starters: - abstracts lots of file handling - js is much easier than most languages to pick up and learn - js has a large dev base because of the web - people are well versed in coding for the web, and adding a “native” layer on top of that is actually quite easy - cross platform c/c++ in general is not so simple even without the GUI
- pjmlp 9y agoThere isn't anything about Electron that I feel it is simple over Delphi, WinForms, JavaFX, Android, Cocoa, Qt, XAML, other than being easier for those that grew with HTML/CSS.
- ghettoimp 9y agoCaveat: It's been a long time since I've used GUI toolkits like Gtk+ and QT, so this may be an out-of-date perspective. What I think of GUI toolkits, I think of lots of imperative code to build out an interface, e.g., "Create a window. Add a vertical box layout. Create button1. Change button1.font to xxx. Change button1.style to bold. Set the minimum height of button1 to 20px. Add button1 to the box. Create button2. Add button2 to the box. Tell the box to grow button2 when it is resized. Create button 3..." The declarative style of HTML/CSS seems so much better. The grouping of elements becomes apparent just by looking at how they are nested, with no need to keep track of what gets added to what. And CSS gives you a really rich ability to select groups of elements, style them, try out new styles, reuse styles across pages, and so on. CSS has definitely gotten really complicated. But then, I could never build anything in a GUI toolkit without constantly referencing the API docs to figure out how to do this or that, either...
- pjmlp 9y agoGtk+ is quite basic compared to RAD UI tooling, even today I wouldn't pick Glade over VB 6 or Delphi. Qt always had a nice UI designer, with layout managers for responsive UIs, no need for imperative code to build out an interface. Since version 5 they have QML, a JavaScript like declarative language, quite similar to J3 the first version of JavaFX. Usually imperative UI code tends to be a thing only among developers that dislike RAD tooling, or game devs using immediate mode UIs.
- protomikron 9y ago> Usually imperative UI code tends to be a thing only among developers that dislike RAD tooling, or game devs using immediate mode UIs. Actually I think that most game UIs (the menus, settings, inventories - not the actual game) are done quite well - maybe immediate mode GUIs have a place outside of gamedev?
- switchbak 9y agoThat certainly used to be the case, but look at something like QML for Qt, and it's typically far more declarative and succinct than (most) HTML, eg: http://doc.qt.io/qt-5/qmlfirststeps.html http://doc.qt.io/qt-5/qmlfirststeps.html I'm not a frontend whiz by any means, but I've always found the widget-centric (GUI) approach fit my mental model better than the HTML centric one. SPA architectures help, but I find most HTML designers tend to prefer raw HTML to any composed/widget approaches. CSS (as a concept) is actually quite great, which is why you've seen the older GUI approaches adopt it. Qt itself is also leading more towards a reactive approach where you interact with an abstract data model, and the UI reflects the updates.