[HN Gopher] Writing HTML sucks and No-code doesn't help
___________________________________________________________________
Writing HTML sucks and No-code doesn't help
Author : kirillrogovoy
Score : 47 points
Date : 2022-05-09 14:01 UTC (8 hours ago)
(HTM) web link (rogovoy.me)
(TXT) w3m dump (rogovoy.me)
| HomeDeLaPot wrote:
| The author talks about syncing changes from dev tools to the IDE
| using CSS-X-Fire, but he doesn't mention Workspaces, found in the
| Chrome dev tools. I don't use it, but it sounds similar and can
| support modern frameworks:
| https://developer.chrome.com/docs/devtools/workspaces/
| SemanticStrengh wrote:
| Thanks, I needed to be reminded of this game changer!
| triptych wrote:
| I feel like the author is describing the thought process that
| brought about Dreamweaver - which made the gap between code and
| design much smaller.
| chrishannah wrote:
| Is this post asking for Dreamweaver?
| pelagicAustral wrote:
| Somewhat accurate. I was almost thinking the same.
| Gualdrapo wrote:
| Sometimes I hate having to deal with three different syntaxes for
| content, styling and interaction each, and I think of QML and how
| things could be if all the frontend stack could follow a similar
| fashion.
|
| Then I remember the immesurable amount of shitty code around the
| web and I get over it.
| naet wrote:
| 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.
| Beltalowda wrote:
| 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).
| tonto wrote:
| 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
| Beltalowda wrote:
| 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.
| majormajor wrote:
| 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.
| capableweb wrote:
| > 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.
| uneekname wrote:
| 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.
| majormajor wrote:
| 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.
| shadowgovt wrote:
| 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.
|
| It's an extremely non-trivial problem to solve.
| danielvaughn wrote:
| 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.
| justsomehnguy wrote:
| 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.
| post-it wrote:
| 99% of the things you do could be equally solved with email.
|
| But it would be a worse user experience.
| danielvaughn wrote:
| 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.
| rchaud wrote:
| No-code is targeted at non-developers, so it's constrained by a
| need to be relatively simple. The author wants to edit the UI
| entirely without touch markup, but that isn't possible unless you
| have affordances for a context menu that scrolls for hundreds of
| items....because that's the number editable properties HTML and
| CSS have.
|
| Only mmm.page lets you edit the UI directly without ever taking
| you into an "admin/editor" type view first. You can see from its
| style that it's not designed to be a full website builder. In
| fact, you can't even link two pages together. it is strictly a
| one-page website tool. That's the tradeoff.
|
| Most no-code tools will provide a halfway solution:
|
| - Bootstrap Studio is a visual webpage builder, but has a code
| window so you can write the markup and styles either there or in
| your editor of choice. Same was true with Dreamweaver back in the
| day.
|
| - Tulmult Hype is similar, but for Flash-like web animation. Both
| visual-only and code-based views are supported, so you can add in
| custom logic w/ code that can't be achieved within the UI
|
| - Microsoft Excel is visual, but includes a scripting language
| for power users
| Alexbades wrote:
| It's a lie
| edgyquant wrote:
| I like writing html and css, and I really love writing react
| components with scss. I feel like I'm the only one but to me it's
| like a bonsai tree I slowly curate over time. It's not a rush in
| the same sense as writing algorithms but I don't get the hate
| either.
| the_other wrote:
| I'm with you, sibling. I mainly write TypeScript, React and
| RXJS these days. They're good. But my favourite days are still
| the ones with a good chunk of CSS. It's zen-like. I suspect
| it's 'cos I wrote a lot of CSS when I was younger: I know
| enough that looking up new or forgotten directives takes
| seconds; the problem space is clear; the feedback is quick
| (depending on build process) and tangible; and the results of
| the work make people happy.
| usrn wrote:
| HTML is no code. Stop stacking random crap ontop of other random
| crap. At the end of the day you still have to enter your idea
| into the computer and the more frameworks you use the more likely
| it is to break/confuse you/someone else.
| hallway_monitor wrote:
| This is exactly what I like about UI programming with Flutter.
| There is no markup, there is only code. The DOM is an object
| model by definition, so why not build up that model using code
| and bypass markup altogether? It's an elegant solution.
| usrn wrote:
| Flutter is terrible for different reasons.
| drewcoo wrote:
| > Whatever isn't run by <table> is run by Flash.
|
| C'mon. It's 2012. We call that Flex now . . .
| omarhaneef wrote:
| Feel the same way but assumed that is just because I am not a
| front end dev who had better ways to do it.
|
| Would like to know what _is_ the current workflow? Suppose you
| have a mockup pencil drawing on a napkin, what is the next step?
|
| Create a header, menu, main, footer and start filling it in?
|
| Go on github and find a design you like?
|
| When do you bring tailwind into it?
| throwaway743 wrote:
| Don't use a css framework unless you don't know how to design
| or don't have a designer. In my experience, you end up
| stripping out/overwriting more than the help it suggests it
| provides.
|
| Also, from concept start to final product, the process is
| extensive. There are plenty of resources online, but boiled
| down > start with a concept, research/validation,
| wires/prototypes, test/reiterate, design exploration, design,
| test/reiterate, dev, test/reiterate 10+x, release, repeat.
| Missing a bunch of details and likely steps, but that's the
| gist.
| omarhaneef wrote:
| I'll add this: I don't know how to design and I don't have a
| designer.
| jerf wrote:
| "Why are we still writing HTML by hand? Could we do that visually
| instead, and have that kind of immediate connection with our
| app?"
|
| It seems to me there's a rich answer to that question. It's not a
| good one per se, but it's a lot richer than meets the eye.
|
| I've used any number of live HTML coders, going all the way back
| to the 20th century. (Dreamweaver, for instance, goes back to
| 1997!) But they always seem to suffer from the same problem for
| coders: They don't just take the HTML on the screen and then make
| it something you can use in code, because they always end up with
| a foreign model laid on top of them.
|
| That is, for instance, you don't click the "center" button and
| get just the <center> tag added, or the correct CSS attribute, or
| dream of dreams, get center added to the "correct" CSS style.
| (Though that's starting to ask for a lot there, since multiple
| could be in effect.) The graphical editor invariably turns into a
| piece of software that receives that you want to "center"
| something and the "interprets" that in a way the manager for the
| product believes you "meant" for that command to mean. This
| generally involves spans and divs being thrown about willy-nilly
| as the programmers internally struggle to implement this vision
| in a way that works with HTML all the time. The crazier the
| manager setting the direction gets, the crazier the program gets.
| They start asking for things essentially impossible in HTML (or
| at least until recently), like, let me add this image with
| transparency and flow the text around the border rather than
| rectilinearly. The managers don't want their bullet-point feature
| list to be confined to merely what is good in HTML. They need
| more shiny flashy features! So, in this case, you probably end up
| with the text hard-laid out, losing all reflow capability, since
| that's all that was possible.
|
| Run through a few iterations of "features" like that, and the
| resulting HTML is a monstrosity and useless to programmers.
| FrontPage was notorious for that sort of thing. Back when people
| still cared if you could hit "View Source" and learn something
| about how the page worked, FrontPage was something that made you
| groan... the sea of HTML looked like, well, what it looked like
| was a lot like a lot of modern pages, honestly! Only with a _lot_
| more "style=" attributes.
|
| It would be interesting to build an HTML editor that worked like
| the Inspect mode. With enough source map support, you might just
| be able to scrape it all together now. UI will still be a bit
| klunky when it comes to "what CSS rule did you want to add this
| change to?", and whether it can integrate with every glorious CSS
| framework out there I don't know. But it might just about be able
| to work.
| efortis wrote:
| I agree, I wish WebStorm did more than autocomplete and color
| picking.
| shkkmo wrote:
| I think a "yes-code" HTML editor GUI is much more achievable if
| limited to specific CSS frameworks since there are fewer ways
| to do things and the logic of what to add to what CSS rule
| seems a bit cleaner.
| jhgb wrote:
| > Take HTML/CSS. Ten years ago, I would've killed for Flexbox
| alone.
|
| I wonder if the author knew about Sciter back then.
|
| Which reminds me that I still need to look into how one could
| generate Sciter UIs and web browser UIs from one codebase.
| Preferably with as little client JS as possible.
| throwaway743 wrote:
| Umm if this is the topic the author chose to complain about, I
| don't know what will please them.
|
| HTML is really easy to write, and really fast if you have the
| right shorthand plugin. Not to mention, it's markup, so it's not
| much of a cognitive load to figure out and write. Especially when
| compared to writing in a programming language/framework like
| js/jsx/react/<insert language>.
|
| Sure CSS can be a pain in the ass, but honestly it's really not
| that bad and not worth writing a seething blog post. Like this
| dude's rant is just overkill at best and annoying at worst.
| shkkmo wrote:
| It's not a rant, or at least not just a rant. It is also
| advertising for the tool the Author is building. I hope they
| are pleased using their tool or learn a lot in the process if
| trying to make it
| wildrhythms wrote:
| I always wonder if modern React/Angular/Vue/Svelte developers
| never learned about the incredible timesaver known as Emmet :)
| https://emmet.io/
| egeozcan wrote:
| People don't use emmet anymore? It does work with React and
| Vue wonderfully well.
| Brian-Puccio wrote:
| I am not a modern react/angular/vue developer, but this is
| still new to me. Thanks!
| lima wrote:
| The commercial Pinegrow editor comes pretty close to what the
| author wants: https://pinegrow.com
| Kalanos wrote:
| html is fine. grids and components suck.
| fswd wrote:
| remix.run, a replacement for next.js, is react framework with
| vannilla js like abilities, a simple and powerful CSS setup (that
| makes sense!), a "just html5" escape hatch (or html5 first and
| react second), and official tailswind support.
|
| It's almost exactly what the author is describing to want!
___________________________________________________________________
(page generated 2022-05-09 23:00 UTC)