4 ms·

Not really. The problem isn't about stylesheets. For the context, I have worked with Qt, QML, Gtk, jQuery, Sencha/ExtJS, React based codebases at various points

Not really. The problem isn't about stylesheets. For the context, I have worked with Qt, QML, Gtk, jQuery, Sencha/ExtJS, React based codebases at various points of time in my career. Qt, Gtk both support stylesheets and no one complains. Everytime i had to deal with web frontend issues, I keep getting frustrated about how we are trying to make "Application UIs" out of what was meant to be a "Document description framework". Be it in Layouts. Be it in debugging. Be it when creating custom widgets/elements. "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.

parasti 4y ago
Your anecdote about the button and vertical alignment doesn't really hold. Vertical alignment has been a solved problem for many years thanks to flexbox. And obviously, use a <button> tag to make a button.
seanalltogether 4y ago
I couldn't agree more, html was designed as a simple way for users to create documents, not interactive applications. IMO stylesheets are the only good feature from html worth pulling into the app ecosystem, but otherwise I really dislike the trend of bringing web technologies designed to solve the limitation of web pages or stateless servers into desktop/mobile application development.
thiht 4y ago
> how we are trying to make "Application UIs" out of what was meant to be a "Document description framework" 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.
- saidinesh5 4y ago
  > We try, we can, and we do. Successfully. 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.
- int_19h 4y ago
  Successfully for whom? As a user, I find that when a desktop app is using a web stack like Electron, that's one of the best predictors for poor and inconsistent UX.
foldr 4y ago
>"You want a button? you have to style a div to get what you want" 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.
rikroots 4y ago
> Of course, there's nothing stopping us from being able to use just a Canvas/WebGL/etc [...] But so far, they seem to do badly when it comes to content addressability, accessibility and search engine optimization. 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 https://codepen.io/kaliedarik/project/editor/DVeMVj Proof-of-concept of an accessible set of related graphs: https://codepen.io/kaliedarik/project/editor/AMVKPx https://codepen.io/kaliedarik/project/editor/AMVKPx

parasti 4y ago

Your anecdote about the button and vertical alignment doesn't really hold. Vertical alignment has been a solved problem for many years thanks to flexbox. And obviously, use a <button> tag to make a button.

seanalltogether 4y ago

I couldn't agree more, html was designed as a simple way for users to create documents, not interactive applications. IMO stylesheets are the only good feature from html worth pulling into the app ecosystem, but otherwise I really dislike the trend of bringing web technologies designed to solve the limitation of web pages or stateless servers into desktop/mobile application development.

thiht 4y ago

> how we are trying to make "Application UIs" out of what was meant to be a "Document description framework" 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.

saidinesh5 4y ago
> We try, we can, and we do. Successfully. 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.
int_19h 4y ago
Successfully for whom? As a user, I find that when a desktop app is using a web stack like Electron, that's one of the best predictors for poor and inconsistent UX.

foldr 4y ago

>"You want a button? you have to style a div to get what you want" 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.

rikroots 4y ago

> Of course, there's nothing stopping us from being able to use just a Canvas/WebGL/etc [...] But so far, they seem to do badly when it comes to content addressability, accessibility and search engine optimization. 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 https://codepen.io/kaliedarik/project/editor/DVeMVj Proof-of-concept of an accessible set of related graphs: https://codepen.io/kaliedarik/project/editor/AMVKPx https://codepen.io/kaliedarik/project/editor/AMVKPx