3 ms·

This is mandated by responsive design. WYSIWYG is terrible for the web not because of the languages used. It just does not make sense. And responsive design n

This is mandated by responsive design. WYSIWYG is terrible for the web not because of the languages used. It just does not make sense. And responsive design not only means mobile, it means all screen sizes and includes other factors. Flexbox is a good example for this.

tracerbulletx 3y ago
Forget responsive design and WYSIWYG... VSCode, Figma, Discord, Slack.. etc.. etc.. can be implemented with html and css and it's a better experience than any other GUI framework for any other platform.
- solardev 3y ago
  Why do you believe that (it's a better experience)? Are you talking about for the developer or the user?
  - wiseowise 3y ago
    Both. As a developer you can tap into endless pit of resources for web development. As a user, you can access same program on all platforms without any changes and continue where you left off, what’s not to like?
    - bee_rider 3y ago
      I would rather know straight-out that a company doesn’t have real native support.
      - moritzwarhier 3y ago
        I have used many native GUIs on Windows that looked blurry because they din't get font rendering right and that only work at a fixed window size. Both in enterprise and consumer software. Yes, they probably weren't holding it right, were written in Java and/or sth else. But I don't understand where the sentiment that native=better comes from. I like native applications too, when done well. For example, I still like IntelliJ IIRC, this does use Java for GUI? Also it doesn't use native controls.
        wiseowise 3y ago
        > But I don't understand where the sentiment that native=better comes from. OCD.
        bee_rider 3y ago
        > But I don't understand where the sentiment that native=better comes from. Some of it is integration, the UI just looks nicer for native apps and the graphical language is the same as the rest of the system. Some of it is performance, these non-native toolkits always seem to bring along too much junk. Some of it is vibes, if an organization is willing to invest in a native app, it seems like they are probably more interested in sticking around.
  - tracerbulletx 3y ago
    So just for context the one's I've used are WPF, UIKit, Electron, and Qt. And using Electron was easiest to develop on for me because the tooling just worked, everything updates instantly in a real running browser environment, and layout was predictable and easy to get it to work exactly how I wanted on actual devices. Is that cause I have more experience with the browser platform? Maybe it is, but that is probably the other main reason people use it. Personally I think the dom and css makes total sense. A tree of nodes where you can address nodes with selectors to style them. Seems pretty ideal, I don't know what I would do differently.
- moritzwarhier 3y ago
  Well, I meant not only all screen sizes but also all feasible window sizes! I agree that HTML+CSS is a great GUI framework. Responsive design as a term has long gone out of fashion. But I see nothing wrong with its meaning.
xandrius 3y ago
This is because of what we have today, it's not how it needs to be. I wouldn't mind a GUI where I put constraints to the elements visually and then check the different ratios/sizes I want to support and bam, done. As a field we're under a general assumption that it makes sense to do visual work textually. Just because WYSIWYG tended to be overly verbose and used by "noobs" that it's not how it should be. Imagine most people making music by just writing notes and then only playing it back afterwards.
dexwiz 3y ago
Design tools often have controls on how you can scale a box by locking expansion in different directions and anchoring elements to specific side. Its results in the same thing as flexbox and alignment but is was more intuitive. The real issue with CSS is the eternal question of, do I fill my parent or expand to fit children? You have to trace multiple levels and rules, and even then it might be a guessing game. This is because the rules that govern this can change at each level, and that changes how you answer the question. I have been using CSS for 20 years. It’s too difficult for what it primarily does.
- emllnd 3y ago
  > The real issue with CSS is the eternal question of, do I fill my parent or expand to fit children? This is one of the real issues of GUI tools in general, not just CSS. You run into the same complexity on e.g. UIKit/SwiftUI (Apple) or any other toolkit that tackles the full complexity of defining UI layouts for any screen simultaneously. Agree that CSS has a bit of extra cruft due to it’s evolution which makes it more difficult to learn and slower to work in than it perhaps could be if the web standards process allowed pruning features more easily
- leptons 3y ago
  >I have been using CSS for 20 years. It’s too difficult for what it primarily does. I've been using CSS since the day it first appeared in IE3 in 1996. "Too difficult" is not at all how I would describe it. Considering how many kinds of layouts need to be created, CSS has performed really well for the task it was designed to do. New features are added every year. It keeps getting easier. The difficulty is in trying to support every kind of device layout, which wouldn't really be any easier in any other layout language.
  - solardev 3y ago
    I think it's easier for us because we've kept up with small incremental changes over 20 years. To someone just jumping in fresh from school or boot camp or whatever, it's quite overwhelming. We've had the benefit of having mastered the simple basics back when they still were simple, and then gradually increasing complexity on an as-needed basis, every few years at a time. It's different when you're just thrust into it new, with decades of built-up cruft. There is nothing magical about CSS that makes it uniquely suited for responsive layouts, especially compared to print layout software (Illustrator or Word or InDesign have had to deal with many container and page sizes and be able to reflow text between and around them for decades) or other GUIs (like Winforms or the ill-fated WPF, or today's mobile platforms, all of which have responsive layouts) or bespoke UIs like game UIs that have had to support different monitor and window sizes since the Everquest and WoW days and before. Hacking together a bunch of pixel measurements and percentage calculations and virtual pixels to do responsive layout is just so... unnecessary. Even with Bootstrap or Tailwind, when a lot of it is abstracted away with helper classes, it's still often much slower than defining the same layout in GUI tools with a few simple clicks and drags. Having to try to guesstimate a resulting layout from code is a poor way to lay out visual designs, which is why full-time designers usually use Figma or a similar tool, not just tinker with CSS until it looks almost right. I don't hate (or even dislike) CSS; it's a powerful tool uniquely suited for the job it was intended for (wrangling HTML "documents" into complex app UIs), but I do wish we had an entirely different workflow that was custom-built to be UI-first and not a paint layer over a hacky XML document... CSS itself has to compete with HTML layout rules, different levels of specificity and overrides, etc. It's a lot of unnecessary complexity that only exists because of history and backward compatibility, not because it was the best design choice overall.
solardev 3y ago
The two aren't mutually exclusive (responsive design and GUIs). Winforms was responsive long before HTML. Dreamweaver was OK at responsive layout shifts in real time. Figma handles it OK too. Even the browser inspector with hot module reload can do the job. But not having easy drag and drop at the component level, and having instead to cut and paste chunks of code, makes it slower and more error prone in my experience.
- moritzwarhier 3y ago
  Fair point. There surely is a space for new tools of this kind. All that is needed to build such a tool is available. I think you are talking about a developer-focused tool you mentioned WinForms. The largest issue building something like this is probably what the input (widgets/components) and output formats (a layout description to be consumed by some framework like react? or pure HTML/CSS?) should be. It needs to be integrated with the code, and we're leaving pure HTML/CSS territory here for purely technical reasons. The web still has no proper native component abstraction. Outputting pure HTML/CSS wouldn't be very useful to me, but might still be cool to visually design layouts, and be useful in some cases.

tracerbulletx 3y ago

Forget responsive design and WYSIWYG... VSCode, Figma, Discord, Slack.. etc.. etc.. can be implemented with html and css and it's a better experience than any other GUI framework for any other platform.

solardev 3y ago
Why do you believe that (it's a better experience)? Are you talking about for the developer or the user?
- wiseowise 3y ago
  Both. As a developer you can tap into endless pit of resources for web development. As a user, you can access same program on all platforms without any changes and continue where you left off, what’s not to like?
  - bee_rider 3y ago
    I would rather know straight-out that a company doesn’t have real native support.
    - moritzwarhier 3y ago
      I have used many native GUIs on Windows that looked blurry because they din't get font rendering right and that only work at a fixed window size. Both in enterprise and consumer software. Yes, they probably weren't holding it right, were written in Java and/or sth else. But I don't understand where the sentiment that native=better comes from. I like native applications too, when done well. For example, I still like IntelliJ IIRC, this does use Java for GUI? Also it doesn't use native controls.
      - wiseowise 3y ago
        > But I don't understand where the sentiment that native=better comes from. OCD.
      - bee_rider 3y ago
        > But I don't understand where the sentiment that native=better comes from. Some of it is integration, the UI just looks nicer for native apps and the graphical language is the same as the rest of the system. Some of it is performance, these non-native toolkits always seem to bring along too much junk. Some of it is vibes, if an organization is willing to invest in a native app, it seems like they are probably more interested in sticking around.
- tracerbulletx 3y ago
  So just for context the one's I've used are WPF, UIKit, Electron, and Qt. And using Electron was easiest to develop on for me because the tooling just worked, everything updates instantly in a real running browser environment, and layout was predictable and easy to get it to work exactly how I wanted on actual devices. Is that cause I have more experience with the browser platform? Maybe it is, but that is probably the other main reason people use it. Personally I think the dom and css makes total sense. A tree of nodes where you can address nodes with selectors to style them. Seems pretty ideal, I don't know what I would do differently.
moritzwarhier 3y ago
Well, I meant not only all screen sizes but also all feasible window sizes! I agree that HTML+CSS is a great GUI framework. Responsive design as a term has long gone out of fashion. But I see nothing wrong with its meaning.

xandrius 3y ago

This is because of what we have today, it's not how it needs to be. I wouldn't mind a GUI where I put constraints to the elements visually and then check the different ratios/sizes I want to support and bam, done. As a field we're under a general assumption that it makes sense to do visual work textually. Just because WYSIWYG tended to be overly verbose and used by "noobs" that it's not how it should be. Imagine most people making music by just writing notes and then only playing it back afterwards.

dexwiz 3y ago

Design tools often have controls on how you can scale a box by locking expansion in different directions and anchoring elements to specific side. Its results in the same thing as flexbox and alignment but is was more intuitive. The real issue with CSS is the eternal question of, do I fill my parent or expand to fit children? You have to trace multiple levels and rules, and even then it might be a guessing game. This is because the rules that govern this can change at each level, and that changes how you answer the question. I have been using CSS for 20 years. It’s too difficult for what it primarily does.

emllnd 3y ago
> The real issue with CSS is the eternal question of, do I fill my parent or expand to fit children? This is one of the real issues of GUI tools in general, not just CSS. You run into the same complexity on e.g. UIKit/SwiftUI (Apple) or any other toolkit that tackles the full complexity of defining UI layouts for any screen simultaneously. Agree that CSS has a bit of extra cruft due to it’s evolution which makes it more difficult to learn and slower to work in than it perhaps could be if the web standards process allowed pruning features more easily
leptons 3y ago
>I have been using CSS for 20 years. It’s too difficult for what it primarily does. I've been using CSS since the day it first appeared in IE3 in 1996. "Too difficult" is not at all how I would describe it. Considering how many kinds of layouts need to be created, CSS has performed really well for the task it was designed to do. New features are added every year. It keeps getting easier. The difficulty is in trying to support every kind of device layout, which wouldn't really be any easier in any other layout language.
- solardev 3y ago
  I think it's easier for us because we've kept up with small incremental changes over 20 years. To someone just jumping in fresh from school or boot camp or whatever, it's quite overwhelming. We've had the benefit of having mastered the simple basics back when they still were simple, and then gradually increasing complexity on an as-needed basis, every few years at a time. It's different when you're just thrust into it new, with decades of built-up cruft. There is nothing magical about CSS that makes it uniquely suited for responsive layouts, especially compared to print layout software (Illustrator or Word or InDesign have had to deal with many container and page sizes and be able to reflow text between and around them for decades) or other GUIs (like Winforms or the ill-fated WPF, or today's mobile platforms, all of which have responsive layouts) or bespoke UIs like game UIs that have had to support different monitor and window sizes since the Everquest and WoW days and before. Hacking together a bunch of pixel measurements and percentage calculations and virtual pixels to do responsive layout is just so... unnecessary. Even with Bootstrap or Tailwind, when a lot of it is abstracted away with helper classes, it's still often much slower than defining the same layout in GUI tools with a few simple clicks and drags. Having to try to guesstimate a resulting layout from code is a poor way to lay out visual designs, which is why full-time designers usually use Figma or a similar tool, not just tinker with CSS until it looks almost right. I don't hate (or even dislike) CSS; it's a powerful tool uniquely suited for the job it was intended for (wrangling HTML "documents" into complex app UIs), but I do wish we had an entirely different workflow that was custom-built to be UI-first and not a paint layer over a hacky XML document... CSS itself has to compete with HTML layout rules, different levels of specificity and overrides, etc. It's a lot of unnecessary complexity that only exists because of history and backward compatibility, not because it was the best design choice overall.

solardev 3y ago

The two aren't mutually exclusive (responsive design and GUIs). Winforms was responsive long before HTML. Dreamweaver was OK at responsive layout shifts in real time. Figma handles it OK too. Even the browser inspector with hot module reload can do the job. But not having easy drag and drop at the component level, and having instead to cut and paste chunks of code, makes it slower and more error prone in my experience.

moritzwarhier 3y ago
Fair point. There surely is a space for new tools of this kind. All that is needed to build such a tool is available. I think you are talking about a developer-focused tool you mentioned WinForms. The largest issue building something like this is probably what the input (widgets/components) and output formats (a layout description to be consumed by some framework like react? or pure HTML/CSS?) should be. It needs to be integrated with the code, and we're leaving pure HTML/CSS territory here for purely technical reasons. The web still has no proper native component abstraction. Outputting pure HTML/CSS wouldn't be very useful to me, but might still be cool to visually design layouts, and be useful in some cases.