Writing HTML sucks and No-code doesn't help
rogovoy.me
rogovoy.me
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.
N.b. that is only really the case for React/React-flavoured frameworks. Other frameworks - notably Angular - still keep HTML and CSS in their own dedicated files (n.b. in Angular you can include the HTML in the component too, but obviously this is only really something you'd want to do for simple and small components for the same reasons that JSX is a problem).
I feel like we're headed down the same old road we had before where people were conflating jQuery with JavaScript. React is not the only way, even if it is popular now. jQuery was in the same position React is now, but today is largely forgotten apart from a few people still using it - I would urge people to remember that and try to keep an open mind and broad-horizons especially in the world of JavaScript Frameworks.
Don’t conflate my sarcasm with my understanding of javascript.
Not at all. The author may have gotten some minor details off, but all of that was present on some level in various quantities. I worked on enterprise software back then and it was a matter of editing HTML in ASPX to manually update your JS libraries. It was also a matter of manually linking your HTML tags to thousands of lines of CSS in typically a single file. It was a gigantic pain in the ass to do on a large code base with hundreds of pages and it meant acting like a human compiler/package manager, carefully grepping through to make sure you didn't miss something when you upgraded JQuery to version 2 or that your CSS class rule didn't accidentally cascade changes to some non-related context and throw your div 16px off-center. It was mind-numbingly dull and extremely error-prone.
It was back then that I realized that despite the fact that some of our web code was written in server-side C#, it by no means could keep up with the need to make dynamic fluid interfaces on the client-side. The lines of code in JS had grown higher than the lines of C# over many years. And yet the tooling was still treating JS as if it were an animated cursor plug-in. It did not have first-class tooling just yet, and JS was missing some critical features (like native modules) that would make it better to work with. This is at least part of why JS was hated so much back then and there's still quite a bit of hate that lingers from that era. It was very frustrating to work with.
It got dramatically better over the next few years, but there was a lot of churn between Bower, yarn, npm, webpack, etc. Even Node.js I believe split off into io.js back then until it re-merged. AngularJS was originally adopted because it solved a lot of these problems for devs with a kitchen sink solution, but it did so in a proprietary, non-scalable way. The JS ecosystem eventually surpassed Angular's capabilities and now we're able to freely move between React, Angular, Vue, Solid, etc while still using the same tooling.
Centering divs was still surprisingly difficult in 2012. Flash was already on life support, for sure, by then, but Flash websites were still out in the wild. Everyone was waiting on HTML5, but it took a couple of years for IE to get retired, for Edge to get released and for Safari to catch up to much of the spec. IE was still a significant market share then. CoffeeScript was at its peak in popularity probably in 2012. The author got a lot very correct in this article. The gist of what they're saying, though, absolutely true.
Personally I switched around 2015 to writing most of my web pages in markdown (well, or commonmark) because I got fed up of repeating myself too often in HTML.
VIM isn't a great IDE for HTML and all its syntax highlighting quirks either, which contributed to the markdown migration.
The beauty of markdown is that it's so lightweight, you can use it for dynamic lazy loading as well. There's almost zero overhead for layouting information for the text if you do it right.
Most enterprises at the time weren't using markdown outside of engineering documentation. The rise of JIRA during this time period helped a bit as they had their own flavor of markdown-like syntactic sugar. We started to explore other ways of generating pages. Ruby on Rails started gaining serious traction ($1B+ VC backed startups using it). Things like haml existed to make writing html "fun again" (my words). Which gave rise to other processing languages to spit out HTML from lessons learned.
It was around this time that microservices started to be a thing to replace those old enterprise SOA architectures (hello jboss). The application server began to die in favor of self-hosted apps. Docker was new. Spring Framework was relatively new. Bootstrap was just released. There weren't any standard css frameworks that provided as much as Bootstrap did at the time.
<script type="template"> was a thing. Backbone.js was used often. Underscore.js as well (Jeremy, again, sorry about Coffeescript, they can't all be winners).
Now we have web components and I'm so happy we do. It's refreshing to be able to do the things we wanted to do back then but couldn't without some other framework.
I've been around a long time. I started doing web development in 1998 right out of high school. I've written all kinds of web apps, platforms, services, etc.
I still like writing my content in markdown.
This setup's strength is its own downfall though. If you don't have the arcane keystrokes and useful patterns burned into your muscle memory you would be better off with almost anything else.
Hopefully if this project gets off the ground they will remember that many of us write HTML as a small component of our jobs rather than it's sole focus.
Many companies were adopting Vignette or Coldfusion.
AOLServer, PHP, mod-perl and Zope were the FOSS alternatives.
Dreamweaver, Frontpage were everywhere on designer computers.
Definitely not 2002.
You brought me back with Zope though, man, totally forgot about that. J2EE had a huge head start over .Net which was just coming out of microsoft to replace VB6/OCX development. I remember when C# came out how awesome it made me feel. C++ like syntax but without having to worry about memory (naively). It was great.
It did not solve the VB ASP problem, only allowed you to write your page backend in C#. Asp, Asp.cs
It sucked for about 7 years until Asp.Net MVC came out.
Tooling went from notepad/vim to Dreamweaver, to Visual Studio/Eclipse and back again.
We were going to adopt J2EE and at last minute our CTO took Microsoft's offer to migrate our product to .NET instead, and be part of the 3rd party products to be shown at .NET launch.
The key developers that were part of this project went on to found OutSystems.
WebForms was great in terms of tooling, that is why Blazor is being positioned as where the still existing WebForms projects should transition to.
https://help.siteimprove.com/support/solutions/articles/8000...
The problem being described is that, in the early 00's, there was no easy way to make column layouts with CSS due to IE6 and CSS's own lack of good column handling rules, other than float: left and (later) display: inline-block. This led to most people in web development to produce their page layouts by stacking tables within tables within tables because the end result would visually work properly in every browser. This was, however, an awful way to produce semantic content not to mention the inherit accessibility issues.
Thankfully, by 2006, nearly everyone had already been exposed to the likes of CSS Zen Garden and learned how to workaround with CSS issues to make layout with block elements instead of tables within tables.
Now we don’t use images for everything, we use CSS/iconography/typography/styles. Back then though we didn’t have a whole lot of options in CSS so we used images EVERYWHERE! Drop shadow, that’s a transparent png image. Gradients, jpgs. Animations, gifs. Want to play a video? Real player or flash. It was crude, it was hard, and it was a compatibly nightmare.
What a time to be alive.
With some "giving up", "stopping early" and appending a "...Best viewed on".
No, the most annoying thing with front end is new front end developer trying to convert data grip that is obviously meant for tables to divs. Seems like young people trying to be cool to not use tables. Use freaking tables when it is looks like grid, div for other stuff.
I said that because it seemed like every new product was using react. In my corner of the world, it was all encompassing for front-end engineers. Still kinda is.
2012 was not very far away from the end of table layouts. After all tables were ditched as a layout tool only because they were hardly responsive and a number of people were starting to browse the web on their phones.
The most popular HTML/CSS framwork (Bootstrap) is from the end of 2011. I'm still maintaining an inherited project that I was sure it is using Bootstrap (because, what else?) until I really looked into it (we've not been making changes the the UI for ages) and horror! it's some custom non responsive div based grid layout. I checked the date of the first commits, beginning of 2011. Tough luck.
I like that your brain supplied the present tense for all of those time periods except for 1999.
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.
People said this when GUIs were introduced, and when rpm and deb were introduced, and system configuration utilities, and editors like pico, and I even heard people say it about Linux OS installers. This perennial, are-you-tech-enough in-crowd gatekeeping has accomplished nothing but ensure developers are three steps behind everyone else in solving real problems with as little overhead as possible for people who might want to concentrate on running their dry cleaning business or dental practice rather than learn how the order of CSS elements affects the cascade.
If your dry cleaning business needs a page with the opening hours, it’s not more complicate than managing your expanses in Excel. Except for the hosting, which is another story altogether.
To your point, this is also where the value of Squarespace like solutions lies, for people who still want/need to touch their site but win’t go the length to understand how it works.
Now,
> people who might want to concentrate on running their dry cleaning business or dental practice
Do these people even want to deal with a website themselves, and not straight ask someone to build and maintain it for them ? The same way that cleaning business wouldn’t spend their days in Illustrator designing new business cards or posters, they’d ask someone else to do it.
The underlying HTML for their website might be as simple as a very complex excel document if they want to look like they’re from 1994… but a) that’s probably worse than having no webpage at all from a branding perspective, and b) unlike excel, HTML isn’t modeled after their common existing business practices, is a single-purpose tool for them and involves a bunch of other knowledge to make that html useful, like CSS, hosting, accessibility, etc.
If the technology exists to let them intuitively form a webpage like they’re working with clay then why not let them? If it’s easy enough, then why wouldn’t they want to form their own? If nobody wanted to do this sort of thing on their own, Squarespace and Wix wouldn’t exist.
Case in point, you probably have to order your business card from the site you built it, and you continue paying a monthly/annual fee to Squarespace/Wix once your site is up.
Both tools and services should exist, and there should be something available at every price point. The point I think was just that there are simple ways to build a site if your needs are simple and you're OK with learning how to do it. If you're not there are myriads of other solutions to tend to your needs.
I mean hell— most modern professional software development toolchains are at least partly service-based already.
I kinda disagree. You are responsible for the first, while the provider is responsible for the second.
For instance when we pay for gitlab or Adobe CS, if it's down it's on us to workaround or plan for the situation and deliver the final product to our clients according to plan.
When we pay for Squarespace, it's on them to deliver the final product to our customers, the puck ends there and if it dies there will be little we can do to help, short of switching DNS to a backup site.
Where you're drawing the line between a service and tool is an artifact of your perspective. Whether someone further along in the cycle must push a button to trigger some part of that process or if the code is executed on your local machine, a docker instance on your machine, a docker instance on a server, or wherever else is an implementation detail.
This whole industry is a mass psychosis that generates dollars.
This rhetoric vastly understates why businesses hire developers: there is far more than displaying text and pictures. Consider Hacker News. The system involves user account creation, security, and the ability to reset passwords. There is a voting system and an input system to record comments.
You need to run backups and set up auto-moderation features. There is spam detection. There is the need for performance and fast loading speeds. The software needs to be maintained over time. The website must be responsive, and adapt to different display sizes (e.g. laptop display versus smartphone). The website should run across different browsers (Chrome, Firefox, and Safari) and on various devices. The website should follow accessibility standards.
There are strong reasons to believe that there are other causes than "mass psychosis" for competently-led organizations to want to hire web developers.
Are you aware of what magazine editors and newspaper editors/writers used to make in the heyday of print media (can probably add TV and radio too since the web has eaten that as well)? This is a ridiculous trope.
Flying cars turn out to be limited by laws of physics in a cost effective way and it also turns out that communication, storytelling, software services that automate processes (such as HR, sales pipelines, etc), search, etc are hugely valuable to humanity.
We were supposed to have something that would have sounded really cool to an 11 year old boy, but was actually a profoundly stupid mode of transportation and an especially unimaginative extrapolation of 1950s American life.
No-code is to codes, as emoji's are to words... easy to read and use, but also confusing and implicit...
It's like every time you want a new chair you get out a two-by-four and a knife and start whittling. But instead of questioning why we whittle our own chairs, we reinvent the knife.
Yet the value of computers and code is almost indispensable.
I'm certainly guilty of this ("how much can boot camp really teach you") despite the fact that I saw many non programmers learn how to reliably program (as long as sufficient examples were around) games via LPMUD. LPC taught an entire generation of non-technical people how to program and nobody even realized it was doing it. Sure it wasn't "great" code, they often needed assistance, and they'd never be engineers, but it was all working game data.
Yes, you can do it all by yourself, in your house, alone. But being alone is depressing for many people, so they decide to pay whatever sum of money just to be in the same room with people in the same page, and a tutor to correct their mistakes.
And I totally agree. I'm following a course in Udemy to learn modern Front End (I'm a Back End developer) and it's boring as hell. Also, I can totally just quit studying with zero consequences.
I remember in ~2013 telling someone who was getting into web design that they should also focus on learning JavaScript, or even CoffeeScript, because just HTML and CSS weren't going to cut it in the future.
I also remember getting into a discussion with a manager in ~2018 who opined that they liked the fact that front end development now meant having to understand JavaScript, and things like React, because it meant they could hire "real engineers" for the front end.
I'm not a fan of that trend, and still kind of lament that a lot of people were forced out of web development because they didn't see the writing on the wall. And I can't really blame them, because at the time, schools were still selling students on web dev & design tracts that strayed away from traditional CS, and focused more on HTML, CSS and UI/UX over programming.
Everything is already in a framework or library, and copypasting a few lines of code from the readme/howto is enough to add a slideshow, accordion menu, or whatever other snazzy but terrible UI gimmick that clients want.
The proportion of websites on the internet that actually need React are close to zero (most sites are cms/crud instead of "real" web apps), yet if you're in the web dev sphere, everything everyone else is building seems to need it. Strange.
Citation needed. IMO most of the bloat comes from ad networks and tracking.
Webdev has automated the easy parts so much that they need zero development and the main skill needed is in writing good content; and the only stuff that does require actual webdev is those things which are not so simple to become a function in some premade system.
Maybe it's just because I haven't sat down and spent a few days learning it front-to-back, but I hate CSS. It might as well be GridBagLayout. Just the alignment of elements is magical (or not) and feels like it relies on the way the wind is blowing when you write the code.
For example, something as simple as 'justify-content' in a grid is (from my limited experience) dependent on everything around it. Change something that seems unrelated and all of a sudden your justification breaks and you have to figure out what side effect caused it. Heck, typing 'align' into WebStorm shows me a bazillion possible completions. Why are there 50 different ways to align things in CSS?
I can’t help but think that this would run into the inner platform effect sooner or later.
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.
It's also so much easier to just slap a stylesheet on .html files and they can be opened up as-is, beautifully presented, in a web browser, without any need of a rendering step.
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.
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.
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.
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.
Even things like CSS frameworks.
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?
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.
- 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.
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.
But it would be a worse user experience.
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.
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).
Also both Qt and GTK support styling with CSS by the way.
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.
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 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.
As a teen I tinkered around a bit with Flash animations and Dreamweaver stuff seemed to be related but just web-focused.
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.
Maybe TFA is asking for a solution to that problem, and as other commenters said, there are tools (that didn't really pan out) that take care of that niche.
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
1. Websites
For instance, in the US most houses look the same, so having the same website isn't a big deal.
2. Apps
Most no-code apps also are a bunch templates, which non-developers will adapt even if it's sub-standard. Think of spreadsheets, to us (devs) non-devs make terrible ones. Yet, many businesses run in Word and Excel.
3. Custom Development
Enterprise software development is too expensive and slow. Starting with the specialized knowledge transfers. For instance, it's unreal that a graphic designer and/or a developer can learn the ins and outs of a business. And instead of accepting that, we just say "requirements change" so planning doesn't matter. Which is our license to avoid understanding what we are developing.
Therefore, many businesses are fed up of developers, so any hope of not dealing with devs is appealing, e.g. that's why ERPs cost so much upfront.
Now, they're fed up of ERPs as well. So no-code or low-code are appealing to domain-experts. They are smart and they're adapting canned solutions.
It turns out coding was never the problem. Troubleshooting is. Analysis is. Integration is. Consensus building is. Repeatable testing is. Long term maintenance is. Just typing out the code is the fastest part of development, and it makes no sense to optimize it if you don't address the real time eaters.
Basically, the core lessons we got from the 1980's still apply, and people are still throwing money to every snake oil salesman promising a silver bullet. This time it will work for real.
Not to mention security, hacking them is easier than ever. Eg POLA nah
BTW, I’m developing a no-code, no-graphic design platform for prototyping technical apps. So I’m convinced it’s possible to make something useful for them. But not if they are database-first, like of all the no code platforms I’ve seen (MS Access, or query browser like)
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.
> ... 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.
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.
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.
If what you do is mostly slow and boring, somebody will eventually automate it and you'll need to learn some new thing.
The whole no-code movement is about taking the stuff that people do manually and automating it to the point that somebody without much training can do stuff with it. It's a logical outcome of this stuff being tedious and repetitive enough that it can be automated.
It's the same as writing Markdown vs a GUI editor. Sure, I'm faster with Markdown for the simple stuff, but as soon as you want some tables you go find a GUI for it [1].
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?
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.
Once you have a stable design/specification to work from you can start - I like to plan out the DOM before writing any code to avoid the excessive "firing arrows" the author struggles with. I generally try to code up the raw HTML first, then progressively add CSS afterwards. I avoid CSS frameworks like tailwind/bootstrap wherever I can as they get you started quicky yes, but in the long run make it harder to get exactly what you want (see previous remake a out designers liking to fiddle)
Why don't we have browser dev tools that are worthy of the name, that are really development tools, not just debug tools?
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.
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.
[%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.
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.
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.
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.
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.
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.
Low-code is more realistic than no-code.
Then I remember the immesurable amount of shitty code around the web and I get over it.
C'mon. It's 2012. We call that Flex now . . .
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.
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.
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
It's almost exactly what the author is describing to want!