by kirillrogovoy on 5/9/22, 2:01 PM with 162 comments
by reactordev on 5/10/22, 2:09 AM
Writing HTML back then is very similar to writing it now, only now you wrap it in a return statement and it lives in a jsx file.
No code has never been a silver bullet. It's main use has always been to solve "known" problems with reproducible components. If you had something you wanted to do outside of those components, you were SOL.
In 1999, we used tables. In 2009 we use divs. In 2019 we use divs and custom elements. In 2022 its all about those web components!
So make sure if you are going to go back in history, that you are factual and not making stuff up. Thanks.
by rsync on 5/9/22, 11:45 PM
Not only did they quickly and easily learn how to write straight html code in a non-visual editor, but I also taught them how to interactively log in and manage the pico editor, etc.
These successes were not due to my skills as a teacher - they were due to the relatively simple skillset involved and the ability for normal people to learn something like this. These people were not geniuses. They did just fine. One of them went on to work professionally as a webmaster.
There is no reason to dumb-down web development - it is already as easy as it needs to be.
by bambax on 5/9/22, 11:24 PM
But this article has it backwards IMHO; HTML owes its incredible success to the fact that it is made up of readable and easy to access code.
If web pages had been produced by super refined, magic and "intelligent" authoring tools that output closed binaries, then they would have gone the way of the CD-Rom. Remember Front Page? Or all the other tools that were supposedly capable of creating HTML but produced unmaintainable garbage full of CDATA sections.
The beauty of HTML is that anyone can understand it and tinker with it.
I'll admit that writing HTML sucks a little. But much less than trying to make a webpage using MS Word.
by naet on 5/9/22, 9:39 PM
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.
by throwaway743 on 5/9/22, 7:59 PM
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.
by rchaud on 5/9/22, 8:10 PM
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
by norswap on 5/9/22, 11:44 PM
Yeah, no, this is definitely not how 2012 was. HMTL5 was not adopted much, but most people used XHTML, and table were definitely out of favour.
Flash was already on the decline, and this was a full 2 years after Jobs said "no Flash on iPhone/iPad".
Microsoft dropped support for IE6 at around that time, some of Google services were already not compatible anymore.
by triyambakam on 5/9/22, 11:16 PM
> ... writing HTML feels like trying to draw a picture by shooting arrows at the target. You shoot one, see where it landed, adjust, and shoot again. Code feels like the gap between you and the target.
by usrn on 5/9/22, 10:51 PM
by HomeDeLaPot on 5/9/22, 8:06 PM
by kiawe_fire on 5/10/22, 12:48 PM
We already have Visual Basic and XCode’s Interface Builder, and the industry has rejected both in favor of reactive widget trees and hand written XML-like things.
But those were not low-code tools that helped non-developers string together basic preset actions - those were tools for developers, that helped produce full apps of virtually any complexity.
They required writing event handlers and model classes. Xcode allowed you to drag right from the button into the code editor to stub out a method and even helped you pick the right source widget to pass into it.
But we rejected all of that (in the case of Interface Builder) in favor of SwiftUI and a bunch of nested declarative widgets, or hand written XAML in the case of VB.
Were the tools of old perfect? No, they needed some updating.
They didn’t hit all of the author’s wants, but it doesn’t matter - the industry said it wanted hand written widget trees instead of a better visual editor, and so, for better or worse, that’s where we are.
by irrational on 5/10/22, 5:22 AM
Well, I stopped here. You are a programmer. Typing things into an IDE or terminal or whatever is what you do. Personally I find it enjoyable. If you find typing to be slow and boring, maybe you should go through a speed typing course to learn to type faster.
by omarhaneef on 5/9/22, 7:52 PM
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?
by triptych on 5/9/22, 8:53 PM
by amadeuspagel on 5/10/22, 11:57 AM
Why don't we have browser dev tools that are worthy of the name, that are really development tools, not just debug tools?
by chrishannah on 5/9/22, 10:21 PM
by biotinker on 5/10/22, 12:31 AM
All it is is just hand-written HTML from a text editor. No fancy features aside from auto-closing tags when I open them. A few lines of CSS that just get pasted on the top of each page.
A lot of the pages out there today aren't terribly more complex than this- just serving some text and photos- with the occasional form. I'm unconvinced that I could have made that website any faster using any sort of no-code tool (99% of the time is spent writing the content).
Obviously plenty of websites require more than that, but mine doesn't, and looking at this article, it doesn't either. Writing HTML doesn't suck for these simple sites unless you make it suck- it shouldn't be "slow and boring" to write the CSS for something like the website posted here because it's something that should be done once, gives you what you want for the page, and then it's done.
Maybe the author is talking more about building some business's website rather than their own, but I don't see the problem.
by atoav on 5/10/22, 6:56 AM
Yet: It is hard to find any duo as powerful and expressive anywhere you want to create user interfaces and layouts.
Writing HTML is not annoying you just do it. You can always use templating languages if you want to do so faster.
by wraptile on 5/10/22, 9:13 AM
[%url https://example.com "see my example" %]
to
<a class="article-link" href="https://example.com" rel="noopener noreferrer">see my example</a>
I feel that HTML grew way out of control to be used directly - it's absolutely unreadable and refactoring quickly becomes a huge danger zone even with brilliant existing tools. With IDE watcher tools you can easily setup automated previews to be rendered along side the files you're working on which imho is the way to go when directly working with HTML these days.
by edgyquant on 5/9/22, 7:49 PM
by temporallobe on 5/10/22, 2:31 AM
Writing HTML does not suck, and it would benefit many things about the web if more devs knew how to write it. Instead, cluttered, almost unreadable HTML is generated by frameworks (yes, even non no-code ones like Angular).
Writing pure HTML sucks, especially for the modern web, because it is inherently flawed and made more awful by CSS, which is why frameworks like Foundation, Bootstrap, and the like have risen up to do the heavy lifting of responsive design and layouts. Being able to compose a clean layout with clean markup with tools like 12-column grids is so much easier and more reliable than hand-coding breakpoints.
Neither solution is perfect, but the latter is the lesser of two evils.
by mattlondon on 5/10/22, 5:21 AM
You don't need to wildly iterate and iterate and iterate if you spend some time doing design work upfront. If you just sit down and start slinging code at the screen without much planning then of course you are going to have to waste a lot of time reworking stuff. While "boring" it is ultimately faster to just do some up-front planning/designing so you know what your DOM needs to be before you start.
It takes discipline to work like this though, so I guess it is not for everyone.
by croes on 5/10/22, 4:46 AM
With an editor it's most likely stuck not stick. That's one of the benefits of writing html manually, you can easily switch to other frameworks without waiting to get support from the editor.
So if the author's dream editor would have existed back then, things like react and tailwind would be less popular now.
by chiefalchemist on 5/9/22, 11:42 PM
Webflow has a place. Shopify and WordPress have a place. Artisan crafted React has a place. Rail / RoR had a place. They all end up existing in a browser. But just like being at the zoo, they are different animals.
As long as you're insisting on pounding nails with a hand saw...yeah, you and/or your clients are going to have complaints.
by lima on 5/9/22, 8:01 PM
by volkandkaya on 5/11/22, 3:44 PM
All no-code tools of the past start from making it easy to use. Instead of making it flexible. They end up abstracting the HTML into custom JSON objects.
Versoly starts with HTML and gives you full flexibility.
by jordiburgos on 5/10/22, 9:32 AM
Low-code is more realistic than no-code.
by Gualdrapo on 5/9/22, 8:08 PM
Then I remember the immesurable amount of shitty code around the web and I get over it.
by code_duck on 5/9/22, 11:20 PM
by drewcoo on 5/9/22, 7:50 PM
C'mon. It's 2012. We call that Flex now . . .
by jhgb on 5/9/22, 8:46 PM
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.
by kuramitropolis on 5/10/22, 9:18 AM
by jerf on 5/9/22, 8:22 PM
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.
by cetinsert on 5/10/22, 9:46 AM
the 0-wait, 0-reload, 2-way sync web playground!
Sync𝗛𝗧𝗠𝗟.io
Try our open beta at: https://SyncHTML.io/y/
Blog post explainer: https://efn.kr/b/sync#new-playground (demoing our programmable embeds)
Multi-device sync: https://www.youtube.com/watch?v=s7WlIcYAm-s
by fswd on 5/9/22, 10:39 PM
It's almost exactly what the author is describing to want!
by kgbcia on 5/10/22, 2:00 AM
by mashaole on 5/9/22, 11:18 PM
by Kalanos on 5/9/22, 9:29 PM