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.
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.
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?
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.
OCD.
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.
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.
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.
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
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.
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.
That would have been just as true in 1996. Programming is hard, that's why not everyone is doing it. You can't get someone to code just by dumbing down programming, many people will fail and just don't have the focus, perseverance, or aptitude for it, and that's okay. I can't ride a skateboard without coming close to killing myself, but many people can.
But people coming into it now actually have it easier because all the wonky stuff and been fixed, there are new ways to do thing that are actually much easier than it was in CSS1 or CSS2, or even CSS as it was 2 years ago. The new people learn "best practices" that didn't exist even 5 years ago. And just because a layout or programming language has lots of features doesn't mean you need to use all of them or feel like it's too difficult to know how to use all of it.
>There is nothing magical about CSS that makes it uniquely suited for responsive layouts, especially compared to print layout software
I also have to take issue with this. CSS has evolved quite a bit specifically for responsive layouts. Flexbox is easily the best example of why your argument is wrong. It's been around for 15 years. And quite a bit more has been added to CSS since then specifically to make responsive layouts easier. Media queries for example. And citing Illustrator and Word and InDesign are just kind of nonsensical, because the output from those programs are not designed to be resized at will by the person holding a piece of paper (printed page). I'm not even sure how you can use that as an example except if you're trolling?
>or bespoke UIs like game UIs that have had to support different monitor and window sizes since the Everquest and WoW days and before.
These aren't tools to use for layout, they are hard-coded programs that adapt as far as they can to specific screen sizes. I seriously doubt they would resize correctly for a portrait display.
>Hacking together a bunch of pixel measurements and percentage calculations and virtual pixels to do responsive layout is just so... unnecessary
I'm sorry if you think that's the only way to do responsive layout.
>, 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.
You don't need to have different levels of specificity or overrides or anything complicated to use CSS and get a simple page working. These advanced things exist because there are absolutely a million valid use cases for specificity and overrides that don't fit into your narrow view of what web browser should do.
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.
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.
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.