TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Writing HTML sucks and No-code doesn't help

148 pointsby kirillrogovoyabout 3 years ago

38 comments

reactordevabout 3 years ago
I didn&#x27;t read the whole article. I couldn&#x27;t. I couldn&#x27;t get past the complete mis-analysis of what the web was in 2012. I was there. I was working as a developer, writing HTML5 code, no one was using tables, let alone flash. The initial arguments of this article are completely off base. Coffeescript was never sexy. It never took hold (despite some big dev names pushing it, sorry Jeremy).<p>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.<p>No code has never been a silver bullet. It&#x27;s main use has always been to solve &quot;known&quot; problems with reproducible components. If you had something you wanted to do outside of those components, you were SOL.<p>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!<p>So make sure if you are going to go back in history, that you are factual and not making stuff up. Thanks.
评论 #31323687 未加载
评论 #31323813 未加载
评论 #31323465 未加载
评论 #31322740 未加载
评论 #31325771 未加载
评论 #31322627 未加载
评论 #31325212 未加载
评论 #31323304 未加载
评论 #31324884 未加载
评论 #31325830 未加载
评论 #31330419 未加载
rsyncabout 3 years ago
In the mid-early years of the WWW, (think 1999-2003) I taught several different <i>completely non-technical people</i> how to create web pages with straight html.<p>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.<p>These successes were <i>not</i> 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 <i>work professionally as a webmaster</i>.<p>There is no reason to dumb-down web development - it is already as easy as it needs to be.
评论 #31321847 未加载
评论 #31322324 未加载
评论 #31321719 未加载
评论 #31321601 未加载
评论 #31321711 未加载
评论 #31323836 未加载
评论 #31322902 未加载
bambaxabout 3 years ago
The promise of &quot;no code&quot; has been around for as long as there has been... code.<p>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.<p>If web pages had been produced by super refined, magic and &quot;intelligent&quot; 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.<p>The beauty of HTML is that anyone can understand it and tinker with it.<p>I&#x27;ll admit that writing HTML sucks a little. But much less than trying to make a webpage using MS Word.
评论 #31321262 未加载
naetabout 3 years ago
People often claim there will be some kind magic &quot;visual editor&quot; 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.<p>It&#x27;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&#x27;re back to CSS programming again.<p>EG If you don&#x27;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 &quot;absolute&quot; and &quot;relative&quot; 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&#x27;ll likely prefer the flexibility in writing it yourself over searching a hugely bloated proprietary interface with a different button for every attribute.<p>There may be some value in small assistance tools like box shadow generators and visual editors, but overall I don&#x27;t think it&#x27;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.
评论 #31321244 未加载
评论 #31320169 未加载
评论 #31320217 未加载
评论 #31321258 未加载
评论 #31321786 未加载
评论 #31322346 未加载
评论 #31320592 未加载
评论 #31321081 未加载
评论 #31321515 未加载
评论 #31321145 未加载
throwaway743about 3 years ago
Umm if this is the topic the author chose to complain about, I don&#x27;t know what will please them.<p>HTML is really easy to write, and really fast if you have the right shorthand plugin. Not to mention, it&#x27;s markup, so it&#x27;s not much of a cognitive load to figure out and write. Especially when compared to writing in a programming language&#x2F;framework like js&#x2F;jsx&#x2F;react&#x2F;&lt;insert language&gt;.<p>Sure CSS can be a pain in the ass, but honestly it&#x27;s really not that bad and not worth writing a seething blog post. Like this dude&#x27;s rant is just overkill at best and annoying at worst.
评论 #31319757 未加载
评论 #31319452 未加载
评论 #31321332 未加载
rchaudabout 3 years ago
No-code is targeted at non-developers, so it&#x27;s constrained by a need to be relatively simple. The author wants to edit the UI entirely without touch markup, but that isn&#x27;t possible unless you have affordances for a context menu that scrolls for hundreds of items....because that&#x27;s the number editable properties HTML and CSS have.<p>Only mmm.page lets you edit the UI directly without ever taking you into an &quot;admin&#x2F;editor&quot; type view first. You can see from its style that it&#x27;s not designed to be a full website builder. In fact, you can&#x27;t even link two pages together. it is strictly a one-page website tool. That&#x27;s the tradeoff.<p>Most no-code tools will provide a halfway solution:<p>- 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.<p>- 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&#x2F; code that can&#x27;t be achieved within the UI<p>- Microsoft Excel is visual, but includes a scripting language for power users
评论 #31321214 未加载
norswapabout 3 years ago
&gt; glimpse of 2012: &gt; &gt; HTML5 is barely adopted; the web is run by &lt;table&gt;. &gt; Whatever isn&#x27;t run by &lt;table&gt; is run by Flash. &gt; &quot;Does it work in IE6 though?&quot;<p>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.<p>Flash was already on the decline, and this was a full 2 years after Jobs said &quot;no Flash on iPhone&#x2F;iPad&quot;.<p>Microsoft dropped support for IE6 at around that time, some of Google services were already not compatible anymore.
triyambakamabout 3 years ago
Reading these comments it looks like almost no one read the article or read very far. The main point isn&#x27;t so much no-code but tightening the feedback loop between tool and UI, where tools can be both code and no-code integrated. I particularly enjoyed this analogy:<p>&gt; ... 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.
评论 #31321170 未加载
usrnabout 3 years ago
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&#x2F;confuse you&#x2F;someone else.
评论 #31320986 未加载
HomeDeLaPotabout 3 years ago
The author talks about syncing changes from dev tools to the IDE using CSS-X-Fire, but he doesn&#x27;t mention Workspaces, found in the Chrome dev tools. I don&#x27;t use it, but it sounds similar and can support modern frameworks: <a href="https:&#x2F;&#x2F;developer.chrome.com&#x2F;docs&#x2F;devtools&#x2F;workspaces&#x2F;" rel="nofollow">https:&#x2F;&#x2F;developer.chrome.com&#x2F;docs&#x2F;devtools&#x2F;workspaces&#x2F;</a>
评论 #31321255 未加载
评论 #31320425 未加载
kiawe_fireabout 3 years ago
We seem to be intentionally running away from what the author wants.<p>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.<p>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.<p>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.<p>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.<p>Were the tools of old perfect? No, they needed some updating.<p>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.
irrationalabout 3 years ago
&gt; Why the hell do I have to write it by hand? It&#x27;s slow and it&#x27;s boring.<p>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.
评论 #31323895 未加载
评论 #31323787 未加载
omarhaneefabout 3 years ago
Feel the same way but assumed that is just because I am not a front end dev who had better ways to do it.<p>Would like to know what <i>is</i> the current workflow? Suppose you have a mockup pencil drawing on a napkin, what is the next step?<p>Create a header, menu, main, footer and start filling it in?<p>Go on github and find a design you like?<p>When do you bring tailwind into it?
评论 #31319149 未加载
评论 #31323797 未加载
triptychabout 3 years ago
I feel like the author is describing the thought process that brought about Dreamweaver - which made the gap between code and design much smaller.
amadeuspagelabout 3 years ago
I&#x27;ve always wondered why I need anything other then the browser dev tools to develop websites, why they are just this additional tool, used for debugging, maybe for experimentation. There&#x27;s something strange about changing something using the dev tools to make it looks right and then having to transfer those changes to the code, to make them permanent. Why is this necessary?<p>Why don&#x27;t we have browser dev tools that are worthy of the name, that are really <i>development</i> tools, not just debug tools?
chrishannahabout 3 years ago
Is this post asking for Dreamweaver?
评论 #31320663 未加载
评论 #31321976 未加载
评论 #31321226 未加载
biotinkerabout 3 years ago
I have a personal blog that I occasionally update to write up projects I do.<p><a href="https:&#x2F;&#x2F;biotinker.dev&#x2F;" rel="nofollow">https:&#x2F;&#x2F;biotinker.dev&#x2F;</a><p>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.<p>A lot of the pages out there today aren&#x27;t terribly more complex than this- just serving some text and photos- with the occasional form. I&#x27;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).<p>Obviously plenty of websites require more than that, but mine doesn&#x27;t, and looking at this article, it doesn&#x27;t either. Writing HTML doesn&#x27;t suck for these simple sites unless you make it suck- it shouldn&#x27;t be &quot;slow and boring&quot; to write the CSS for something like the website posted here because it&#x27;s something that should be done once, gives you what you want for the page, and then it&#x27;s done.<p>Maybe the author is talking more about building some business&#x27;s website rather than their own, but I don&#x27;t see the problem.
atoavabout 3 years ago
The weird thing about HTML and CSS is: I know it could have been better if somebody took today&#x27;s requirements and turned them into both a markup and a stylesheet language.<p>Yet: It is hard to find any duo as powerful and expressive anywhere you want to create user interfaces and layouts.<p>Writing HTML is not annoying you just do it. You can always use templating languages if you want to do so faster.
wraptileabout 3 years ago
I think HTML benefits well from an additional abstraction level. For example, for our blog we use wordpress style shortcodes[1] (or other html templating really) which essentially turns:<p>[%url <a href="https:&#x2F;&#x2F;example.com" rel="nofollow">https:&#x2F;&#x2F;example.com</a> &quot;see my example&quot; %]<p>to<p>&lt;a class=&quot;article-link&quot; href=&quot;<a href="https:&#x2F;&#x2F;example.com" rel="nofollow">https:&#x2F;&#x2F;example.com</a>&quot; rel=&quot;noopener noreferrer&quot;&gt;see my example&lt;&#x2F;a&gt;<p>I feel that HTML grew way out of control to be used directly - it&#x27;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&#x27;re working on which imho is the way to go when directly working with HTML these days.<p>1 - <a href="https:&#x2F;&#x2F;github.com&#x2F;Granitosaurus&#x2F;shortcoder" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Granitosaurus&#x2F;shortcoder</a>
edgyquantabout 3 years ago
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.
评论 #31320143 未加载
temporallobeabout 3 years ago
I’m gonna argue both sides.<p>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 <i>generated</i> by frameworks (yes, even non no-code ones like Angular).<p>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.<p>Neither solution is perfect, but the latter is the lesser of two evils.
mattlondonabout 3 years ago
Sounds to me like the author should perhaps stop and think a bit more before &quot;firing the arrows&quot;.<p>You don&#x27;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 &quot;boring&quot; it is ultimately faster to just do some up-front planning&#x2F;designing so you know what your DOM needs to be before you start.<p>It takes discipline to work like this though, so I guess it is not for everyone.
croesabout 3 years ago
&gt;To keep the context manageable, I&#x27;ll stick to React + Tailwind (with official support for Next.js) simply because that&#x27;s the stack I&#x27;m using and it&#x27;s wildly popular today.<p>With an editor it&#x27;s most likely stuck not stick. That&#x27;s one of the benefits of writing html manually, you can easily switch to other frameworks without waiting to get support from the editor.<p>So if the author&#x27;s dream editor would have existed back then, things like react and tailwind would be less popular now.
chiefalchemistabout 3 years ago
A tool, any tool, has an intended purpose and a sweet spot. Try to pound nails with a screwdriver and you&#x27;re, well, um, screwed.<p>Webflow has a place. Shopify and WordPress have a place. Artisan crafted React has a place. Rail &#x2F; RoR had a place. They all end up existing in a browser. But just like being at the zoo, they are different animals.<p>As long as you&#x27;re insisting on pounding nails with a hand saw...yeah, you and&#x2F;or your clients are going to have complaints.
limaabout 3 years ago
The commercial Pinegrow editor comes pretty close to what the author wants: <a href="https:&#x2F;&#x2F;pinegrow.com" rel="nofollow">https:&#x2F;&#x2F;pinegrow.com</a>
评论 #31327443 未加载
volkandkayaabout 3 years ago
Kind of described <a href="https:&#x2F;&#x2F;versoly.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;versoly.com&#x2F;</a><p>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.<p>Versoly starts with HTML and gives you full flexibility.
jordiburgosabout 3 years ago
Better than no-code, I would expect a library in React, Vue, Web-Components, etc... with high level components that I can just use. I mean easy to put in my page, not having to write a lot of code and they look fairly well with not custom style code.<p>Low-code is more realistic than no-code.
Gualdrapoabout 3 years ago
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.<p>Then I remember the immesurable amount of shitty code around the web and I get over it.
code_duckabout 3 years ago
I feel like a the early points in the 2012 were taken care of by that time. In 2012 I hadn’t used tables for years except to display a table, was using HTML 5, never used Flash, had ended IE 6 support and certainly my variables were not all global. So, maybe 2008-2009.
drewcooabout 3 years ago
&gt; Whatever isn&#x27;t run by &lt;table&gt; is run by Flash.<p>C&#x27;mon. It&#x27;s 2012. We call that Flex now . . .
jhgbabout 3 years ago
&gt; Take HTML&#x2F;CSS. Ten years ago, I would&#x27;ve killed for Flexbox alone.<p>I wonder if the author knew about Sciter back then.<p>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.
kuramitropolisabout 3 years ago
Just write Pug lol<p><a href="https:&#x2F;&#x2F;pugjs.org&#x2F;api&#x2F;getting-started.html" rel="nofollow">https:&#x2F;&#x2F;pugjs.org&#x2F;api&#x2F;getting-started.html</a>
jerfabout 3 years ago
&quot;Why are we still writing HTML by hand? Could we do that visually instead, and have that kind of immediate connection with our app?&quot;<p>It seems to me there&#x27;s a rich answer to that question. It&#x27;s not a good one per se, but it&#x27;s a lot richer than meets the eye.<p>I&#x27;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&#x27;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.<p>That is, for instance, you don&#x27;t click the &quot;center&quot; button and get just the &lt;center&gt; tag added, or the correct CSS attribute, or dream of dreams, get center added to the &quot;correct&quot; CSS style. (Though that&#x27;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 &quot;center&quot; something and the &quot;interprets&quot; that in a way the manager for the product believes you &quot;meant&quot; 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&#x27;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&#x27;s all that was possible.<p>Run through a few iterations of &quot;features&quot; 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 &quot;View Source&quot; 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 <i>lot</i> more &quot;style=&quot; attributes.<p>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 &quot;what CSS rule did you want to add this change to?&quot;, and whether it can integrate with every glorious CSS framework out there I don&#x27;t know. But it might just about be able to work.
评论 #31319527 未加载
评论 #31320883 未加载
cetinsertabout 3 years ago
Everyone that hates feedback loop delays, we build<p>the 0-wait, 0-reload, 2-way sync web playground!<p>Sync𝗛𝗧𝗠𝗟.io<p>Try our open beta at: <a href="https:&#x2F;&#x2F;SyncHTML.io&#x2F;y&#x2F;" rel="nofollow">https:&#x2F;&#x2F;SyncHTML.io&#x2F;y&#x2F;</a><p>Blog post explainer: <a href="https:&#x2F;&#x2F;efn.kr&#x2F;b&#x2F;sync#new-playground" rel="nofollow">https:&#x2F;&#x2F;efn.kr&#x2F;b&#x2F;sync#new-playground</a> (demoing our programmable embeds)<p>Multi-device sync: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=s7WlIcYAm-s" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=s7WlIcYAm-s</a>
fswdabout 3 years ago
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 &quot;just html5&quot; escape hatch (or html5 first and react second), and official tailswind support.<p>It&#x27;s almost exactly what the author is describing to want!
kgbciaabout 3 years ago
no it doesn&#x27;t. i was there for Geocities, angelfire, tripod, myspace. once you know how to copy and paste
mashaoleabout 3 years ago
Try Teleport.io Quarkly.io Framer.com
评论 #31321906 未加载
Kalanosabout 3 years ago
html is fine. grids and components suck.