People often claim there will be some kind magic "visual editor" that can produce the same level of visually styled web pages as an actual programmer, but IMO there will never be such a thing. Maybe because it is a visual exercise it gets easily trivialized, but CSS is a full on programming language and you need to understand its properties and functionality to make full use of it.
It's easy to get something looking similar-ish to your design with a visual editor, at a single screen size.... But then you have to start thinking about how things are actually positioned, where they will be anchored when the window is a different size, or the content a different length, or how it will respond to a user interaction or a given state- and then you're back to CSS programming again.
EG If you don't on some level understand the difference between absolute and relative positioning you might not be able to achieve your design properly (and this applies to many properties, not just positioning). So now "absolute" and "relative" must get added as options to the visual editor, and the users have to on some level understand these terms or behaviors to use them. As you learn in this way about CSS directly and approach CSS literacy, (I think) you'll likely prefer the flexibility in writing it yourself over searching a hugely bloated proprietary interface with a different button for every attribute.
There may be some value in small assistance tools like box shadow generators and visual editors, but overall I don't think it's reasonable to assume a non-technical no-code user will ever be able to produce the level of customization that a technical user can, at least with our current implementation of CSS styling.
I don't like this insistence on calling non programming languages like CSS/HTML programming languages. What we call programming languages are general programming languages. CSS and HTML are DSLs (In specific presentation and markup languages)
People push back against this criticism because they think it comes from elitism, but the fact is that they're valuable because they're not programming languages, and in the web they're as important as programming languages, so it's not that. Not all computer languages are programming languages, and a DSL doesn't suddenly become a GPL because it's complex.
100% agree. "It's not a real programming language" has become construed as an attack against anyone who makes a career in tech writing DSLs, now everyone labels anything technical as "programming". Laypeople probably think JSON is programming.
DSLs hardly mean "not a real programmer". SQL is a DSL, and I'd wager some people make more money writing SQL than other mainstream languages.
> People often claim there will be some kind magic "visual editor" that can produce the same level of visually styled web pages as an actual programmer, but IMO there will never be such a thing.
I'm not claiming I have a solution, but I will say that I've seen "X will never exist" a number of times over the years, about pretty much anything we take for granted today, and it's always possible that X will exists in the near future, or future future.
And I thank you for saying it like that, because my mind immediately started thinking about how it can be solved, and I'm sure I'm not alone.
The problem with something like this is that it's a moving target.
People in 2000 were saying visual editors couldn't match hand-written code, and were right at the time. But I would happily use today's visual editors instead of hand-writing 2000s websites, using only the tools available in 2000, if all I wanted was a 2000-level website.
But so far, every time we've made things more powerful - even if it makes it easier to have a good visual editor - it's also pushed the frontier of what a bespoke experience can give you.
If you’re doing something trivial, or solving a couple of specific use cases, then a framework full of CSS classes that give you Twitter-looking cards or a no code solution that helps you send an email every time a user clicks a “subscribe” button IS helpful.
But the problem is, once you’ve used the tool for that initial problem, you’re stuck with it. And inevitably, if your thing is successful at all, you will outgrow that tool quickly and need to start making bespoke things to keep up.
I say this not out of gate keeping either - I say this as an overworked full stack software developer who would LOVE to be able to provide a CSS framework or a visual editor to my co-workers and have them produce long term solutions.
But as soon as they find some tool and ask me to help adopt it, it works for them for a couple use cases, and then guess who’s stuck trying to make it work with all the fancy new things we need that then requires extending the tool or working around it entirely?
I also don't think that it will exist, but not because it's technically infeasible. I just don't think it makes sense as a solution.
The complexity of a task depends on the complexity of the problem. That complexity has to live somewhere, and it doesn't matter whether it lives in a GUI or in code.
Just recently I overheard a conversation where some people were complaining about their Zapier integration. Someone had built a data flow for all these tasks, and it was an absolute mess and a maze to wander through. I found myself laughing because it's the same kind of complaint developers often make about code.
Bottom line is that if the UI is complex, the GUI that is used to build it will be complex.
Most of the solutions fall into one of three categories
- they don't give users the amount of control they want because fundamentally, HTML and CSS together couple content and layout in a very programmer way... This is been a huge advantage for them as a user interface language because they create user interfaces that can work on many screen and window dimensions, but if you don't wrap your head around the layout algorithm, you're going to end up surprised.
- they try to give users the level of control over content and layout that users want, and the end result is extremely buggy
- they try to give users the level of control over content and layout that users want, and the end result is incredibly verbose and basically illegible HTML and CSS. This tends to cause problems down the road because it doesn't couple well with other tools and tends to cause problems later if somebody has to debug by hand or they want to move away from the tool used to originally create the page.
I agree with the parent comment, but I also see your point that there is room for innovation. For example, the article mentions flexboxes. Flexboxes have many possible behaviors that a tool could help visualize and decide between.
When someone equals the Web programming with innane CSS knowledge I want to facepalm so hard.
CSS is just a way to present things. 99% of the things you do could be equally solved with a basic HTML4 POST form and no one would be hurt except the guys who desperately needs the round corners to show a three paragraphs of text.
This is true on some level, but not true on another. The reality is that as web products change over time, they bring on new customer expectations. For instance, when searching for something with a finite set of possible results, the users' expectation is that they will see a dropdown with auto-complete suggestions. And on top of that, they expect to be able to navigate up and down the list with their up/down arrow keys. That, as well as a mountain of other examples, cannot be done with CSS.
You can achieve many effects with js/dom although yes emulating CSS is in general absurd goal (slower, more complex). And not everything can be programmatically emulated (except with canvas/webGL/webGPU/SVG/PDF but that is cheating)
In fairness, flash used to be a thing, and it was probably 80% of the way there. There's also a fair bit of accidental complexity in CSS. (e.g. position: relative and overflow: hidden having weird-if-youre-not-used-to-them side effects)
I think Wix, Squarespace, etc suit a lot of people's needs pretty well, and they have visual editors. There are businesses that run on those platforms that never had to touch code at all to get their work done.
The idea of a visual editor that replaces code tends to dominate, but I really want better tools to augment it. Firebug and all the descendants of Firebug like Chrome's inspector are a good start, but those tools help you view and make minor edits to your markup tree rather than build it.
I think the problem is that HTML and CSS are so fiddly and so big. Seemingly okay things don't work properly. You end up with an editor that only works on a subset, and then you're back to replacing rather than augmenting.
There are things like Qt Designer and Glade for GTK; I don't see why that can't exist for the web. The layout system for most toolkits are less complex than HTML/CSS though, and since CSS isn't that difficult it's just a poor effort/benefit trade-off.
Meanwhile, there are plenty of "website building tools" that don't offer all features but more than enough for most normal non-programmers looking to create a site, and these go back a long time (e.g. Geocities).
The comparison to desktop native is interesting because you could also just not style everything to hell with css and...there you are, you are native styled with the web
The default style for the web kind of sucks though, so that's a bit of an issue. It also doesn't include a rich set of "widgets" that you get with Qt and GTK, so you often need to provide your own.
Also both Qt and GTK support styling with CSS by the way.
One big difference between websites/webapps and native apps is that your app is also often your sales page - or at least made with the same technology.
You could dress up the box and the press kit for your system-toolkit-using desktop app, but now all that is done on the web, and everyone still wants to stand out. The late-stage desktop app era even saw this creep into those, after all: MS Office's ribbon, Apple's brushed metal, etc.
"People often claim there will be some kind magic "visual editor" that can produce the same level of visually styled web pages as an actual programmer,"
The wrong bit there is the word "programmer".
I'm 52 and own an IT consultancy. I've used Wordperfect 4 onwards, Wordstar, manual typewriters, MS Word from 2.0 onwards, Quark Express, Word Star, Open Office, Libre Office and many many many more. I'm very familiar with the notions of leading where you put lead shims in between words to pretty things up and avoid widows and orphans and kerning for a similar reason but between letters (or is it vv, can't remember - don't care) I also run a fair few Mediawikis and I note you picked on the phrase "Visual Editor".
The content should be king, the way you display it should always be second but it should be fairly decent. In my opinion.
FWIW: VE on mediawikis, in my opinion, is quite an enabler.
I think the next generation of tools like Figma (i.e. Figma 2.0) may end up being polished and able enough for a semi-technical user to visually build out a whole (bespoke, custom) website and with the click of a button publish/host it.
I know there are extensions available for Figma that allow that right now, but from what I could see they weren't as polished as one would want.
May have been, but from the little I've seen/read about DW it didn't seem like it was used to create custom-to-the-nth-degree, production-ready websites that interfaced with APIs etc. I definitely could be wrong on that though.
As a teen I tinkered around a bit with Flash animations and Dreamweaver stuff seemed to be related but just web-focused.
It's easy to get something looking similar-ish to your design with a visual editor, at a single screen size.... But then you have to start thinking about how things are actually positioned, where they will be anchored when the window is a different size, or the content a different length, or how it will respond to a user interaction or a given state- and then you're back to CSS programming again.
EG If you don't on some level understand the difference between absolute and relative positioning you might not be able to achieve your design properly (and this applies to many properties, not just positioning). So now "absolute" and "relative" must get added as options to the visual editor, and the users have to on some level understand these terms or behaviors to use them. As you learn in this way about CSS directly and approach CSS literacy, (I think) you'll likely prefer the flexibility in writing it yourself over searching a hugely bloated proprietary interface with a different button for every attribute.
There may be some value in small assistance tools like box shadow generators and visual editors, but overall I don't think it's reasonable to assume a non-technical no-code user will ever be able to produce the level of customization that a technical user can, at least with our current implementation of CSS styling.