18 ms·

Writing HTML sucks and No-code doesn't help

148 points by kirillrogovoy 4y ago

volkandkaya 4y ago
Kind of described https://versoly.com/ https://versoly.com/ 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.
Kalanos 4y ago
html is fine. grids and components suck.
edgyquant 4y 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.
- the_other 4y ago
  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.
  - SemanticStrengh 4y ago
    Great comment
drewcoo 4y ago
> Whatever isn't run by <table> is run by Flash. C'mon. It's 2012. We call that Flex now . . .
omarhaneef 4y 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. 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 4y ago
  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 4y ago
    I'll add this: I don't know how to design and I don't have a designer.
    - throwaway743 4y ago
      Ah word. Yeah then ain't no shame in using a framework, but give a shot at styling based on design inspirations you find. Design's just another system with rules.
- mattlondon 4y ago
  Before doing anything make sure you get your UX design team/designer/person responsible for what it looks like to finalise the design. Full specs required for fonts, colours, sizing, padding, accessibility labels etc before a single line of code is written is the optimal situation, but not always realistic - get as much as you can agreed first. This is because from experience designers et al like to fiddle around with things a lot before it is "done" so don't waste time coding before the specification is ready. 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)
throwaway743 4y ago
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 4y ago
  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 4y ago
  I always wonder if modern React/Angular/Vue/Svelte developers never learned about the incredible timesaver known as Emmet :) https://emmet.io/ https://emmet.io/
  - egeozcan 4y ago
    People don't use emmet anymore? It does work with React and Vue wonderfully well.
  - Brian-Puccio 4y ago
    I am not a modern react/angular/vue developer, but this is still new to me. Thanks!
  - throwaway743 4y ago
    Oh man it's the best. Everyone should give it a go.
- aordano 4y ago
  And there's even templating engines like Pug that really simplify the markup, to make it even easier. Not everything needs to ve intantly visualizable, writing the stuff, processing it ana checking once in a while how it's growing is much more than enough, unless you happen to write it very very rarely. 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.
lima 4y ago
The commercial Pinegrow editor comes pretty close to what the author wants: https://pinegrow.com https://pinegrow.com
- Nazzareno 4y ago
  On the opposite side: https://beefree.io/bee-plugin/ https://beefree.io/bee-plugin/
HomeDeLaPot 4y ago
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/ https://developer.chrome.com/docs/devtools/workspaces/
- SemanticStrengh 4y ago
  Thanks, I needed to be reminded of this game changer!
- bambax 4y ago
  Yes! The article goes so far as saying "Spoiler: nothing fancy has happened since CSS-X-Fire which itself hasn't been ported anywhere" which is a bit of a head scratcher.
Gualdrapo 4y 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. Then I remember the immesurable amount of shitty code around the web and I get over it.
rchaud 4y ago
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
- efortis 4y ago
  No-Code won't and can't replace coding 100%, but it'll take a huge chunk. 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.
  - hyperman1 4y ago
    No-code apps are popping up left and right in my company(OutSystems). They universally suck. Performance is horrible. UI is horrible. Development is actually slower than it used to be. We are hiring no-code devs which are more expensive than other devs because they are hot on the market. non-devs can't no-code just like they can't code, who would have thought. The no-code tooling is so primitive, every kind of troubleshooting takes forever, besides it requires access that normal people can't have as they would torpedo the no-code of other people's teams. 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.
jerf 4y ago
"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.
- shkkmo 4y ago
jhgb 4y ago
> 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.
triptych 4y 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.
naet 4y ago
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.
- capableweb 4y ago
  > 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.
  - danielvaughn 4y ago
    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.
chrishannah 4y ago
Is this post asking for Dreamweaver?
- pelagicAustral 4y ago
  Somewhat accurate. I was almost thinking the same.
- bambax 4y ago
  Yes, it appears so. Or maybe Front Page.
- superkuh 4y ago
  Or the HTML editor built into Netscape Navigator.
fswd 4y 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 "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!
Alexbades 4y ago
usrn 4y 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/confuse you/someone else.
- hallway_monitor 4y ago
  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 4y ago
    Flutter is terrible for different reasons.
  - SemanticStrengh 4y ago
    Except it's not elegant nor expressive, it induce much higher complexity and coupling. A major failure.
  - aloisdg 4y ago
    like winforms?
triyambakam 4y ago
Reading these comments it looks like almost no one read the article or read very far. The main point isn'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: > ... 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.
- SemanticStrengh 4y ago
  The only flaw of the article id that it fails to mention devtools workspaces
mashaole 4y ago
Try Teleport.io Quarkly.io Framer.com
- mateomorris 4y ago
  Also primo.so
code_duck 4y 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.
bambax 4y ago
The promise of "no code" has been around for as long as there has been... code. 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.
- dheera 4y ago
  Agreed. In fact I detest Markdown, and use a subset of HTML for all of my notes. It's much more syntactically consistent and easier to read. I know <b> means bold and I don't have to memorize how many asterisks correspond to bold vs. italic vs. underline. 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.
chiefalchemist 4y ago
A tool, any tool, has an intended purpose and a sweet spot. Try to pound nails with a screwdriver and you're, well, um, screwed. 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.
norswap 4y ago
> glimpse of 2012: > > HTML5 is barely adopted; the web is run by <table>. > Whatever isn't run by <table> is run by Flash. > "Does it work in IE6 though?" 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.
rsync 4y ago
In the mid-early years of the WWW, (think 1999-2003) I taught several different completely non-technical people how to create web pages with straight html. 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.
- Blackthorn 4y ago
  I think we as professionals tend to overestimate how difficult the basics are for people. 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.
  - frostwarrior 4y ago
    IMHO boot camps are for coding like going to the gym is for exercise. 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.
- heavyset_go 4y ago
  Until recently, front end development meant knowing how to use HTML and CSS, same thing with web design. 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.
biotinker 4y ago
I have a personal blog that I occasionally update to write up projects I do. https://biotinker.dev/ https://biotinker.dev/ 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.
kgbcia 4y ago
no it doesn't. i was there for Geocities, angelfire, tripod, myspace. once you know how to copy and paste
reactordev 4y ago
I didn't read the whole article. I couldn't. I couldn'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). 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.
- joenathanone 4y ago
  What's wrong with tables? Datatables are my jam!
  - Saoshyant 4y ago
    There's absolutely nothing wrong with tables when properly used for data. 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.
    - gabereiser 4y ago
      Yup, no grid, no flex, the only way to ensure your chopped up photoshop design would work was with 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.
temporallobe 4y ago
I’m gonna argue both sides. 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.
croes 4y ago
>To keep the context manageable, I'll stick to React + Tailwind (with official support for Next.js) simply because that's the stack I'm using and it's wildly popular today. 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.
mattlondon 4y ago
Sounds to me like the author should perhaps stop and think a bit more before "firing the arrows". 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.
irrational 4y ago
> Why the hell do I have to write it by hand? It's slow and it's boring. 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.
- donmcronald 4y ago
  If you tried something like SceneBuilder (JavaFX) you'd probably change your mind. At least for me, using a visual tool to do layouts saves a ton of time. Even if there's some fine tuning at the end, just being able to do the basic layout is some much easier with a GUI. 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]. 1. https://www.tablesgenerator.com/markdown_tables https://www.tablesgenerator.com/markdown_tables
- jillesvangurp 4y ago
  If it's slow and boring, automate it. That's your job as a programmer. Repetitive work is ideally suited for automation. It's not about typing faster but being creative without getting bogged down by the keyboard. 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.
atoav 4y ago
The weird thing about HTML and CSS is: I know it could have been better if somebody took today's requirements and turned them into both a markup and a stylesheet language. 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.
wraptile 4y 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: [%url https://example.com https://example.com "see my example" %] to <a class="article-link" href="https://example.com 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. 1 - https://github.com/Granitosaurus/shortcoder https://github.com/Granitosaurus/shortcoder
kuramitropolis 4y ago
Just write Pug lol https://pugjs.org/api/getting-started.html https://pugjs.org/api/getting-started.html
jordiburgos 4y 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. Low-code is more realistic than no-code.
cetinsert 4y ago
Everyone that hates feedback loop delays, we build the 0-wait, 0-reload, 2-way sync web playground! Sync𝗛𝗧𝗠𝗟.io Try our open beta at: https://SyncHTML.io/y/ https://SyncHTML.io/y/ Blog post explainer: https://efn.kr/b/sync#new-playground https://efn.kr/b/sync#new-playground (demoing our programmable embeds) Multi-device sync: https://www.youtube.com/watch?v=s7WlIcYAm-s https://www.youtube.com/watch?v=s7WlIcYAm-s
amadeuspagel 4y ago
I'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'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? Why don't we have browser dev tools that are worthy of the name, that are really development tools, not just debug tools?
kiawe_fire 4y ago
We seem to be intentionally running away from what the author wants. 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.

148 points by kirillrogovoy 4y ago

Kind of described https://versoly.com/ https://versoly.com/ 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.

Kalanos 4y ago

html is fine. grids and components suck.

edgyquant 4y 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.

the_other 4y ago
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.
- SemanticStrengh 4y ago
  Great comment

drewcoo 4y ago

> Whatever isn't run by <table> is run by Flash. C'mon. It's 2012. We call that Flex now . . .

omarhaneef 4y 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. 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 4y ago
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 4y ago
  I'll add this: I don't know how to design and I don't have a designer.
  - throwaway743 4y ago
    Ah word. Yeah then ain't no shame in using a framework, but give a shot at styling based on design inspirations you find. Design's just another system with rules.
mattlondon 4y ago
Before doing anything make sure you get your UX design team/designer/person responsible for what it looks like to finalise the design. Full specs required for fonts, colours, sizing, padding, accessibility labels etc before a single line of code is written is the optimal situation, but not always realistic - get as much as you can agreed first. This is because from experience designers et al like to fiddle around with things a lot before it is "done" so don't waste time coding before the specification is ready. 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)

throwaway743 4y ago

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 4y ago
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 4y ago
I always wonder if modern React/Angular/Vue/Svelte developers never learned about the incredible timesaver known as Emmet :) https://emmet.io/ https://emmet.io/
- egeozcan 4y ago
  People don't use emmet anymore? It does work with React and Vue wonderfully well.
- Brian-Puccio 4y ago
  I am not a modern react/angular/vue developer, but this is still new to me. Thanks!
- throwaway743 4y ago
  Oh man it's the best. Everyone should give it a go.
aordano 4y ago
And there's even templating engines like Pug that really simplify the markup, to make it even easier. Not everything needs to ve intantly visualizable, writing the stuff, processing it ana checking once in a while how it's growing is much more than enough, unless you happen to write it very very rarely. 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.

lima 4y ago

The commercial Pinegrow editor comes pretty close to what the author wants: https://pinegrow.com https://pinegrow.com

Nazzareno 4y ago
On the opposite side: https://beefree.io/bee-plugin/ https://beefree.io/bee-plugin/

HomeDeLaPot 4y ago

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/ https://developer.chrome.com/docs/devtools/workspaces/

SemanticStrengh 4y ago
Thanks, I needed to be reminded of this game changer!
bambax 4y ago
Yes! The article goes so far as saying "Spoiler: nothing fancy has happened since CSS-X-Fire which itself hasn't been ported anywhere" which is a bit of a head scratcher.

Gualdrapo 4y 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. Then I remember the immesurable amount of shitty code around the web and I get over it.

rchaud 4y ago

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

efortis 4y ago
No-Code won't and can't replace coding 100%, but it'll take a huge chunk. 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.
- hyperman1 4y ago
  No-code apps are popping up left and right in my company(OutSystems). They universally suck. Performance is horrible. UI is horrible. Development is actually slower than it used to be. We are hiring no-code devs which are more expensive than other devs because they are hot on the market. non-devs can't no-code just like they can't code, who would have thought. The no-code tooling is so primitive, every kind of troubleshooting takes forever, besides it requires access that normal people can't have as they would torpedo the no-code of other people's teams. 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.

jerf 4y ago

"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.

shkkmo 4y ago

jhgb 4y ago

> 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.

triptych 4y 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.

naet 4y ago

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.

capableweb 4y ago
> 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.
- danielvaughn 4y ago
  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.

chrishannah 4y ago

Is this post asking for Dreamweaver?

pelagicAustral 4y ago
Somewhat accurate. I was almost thinking the same.
bambax 4y ago
Yes, it appears so. Or maybe Front Page.
superkuh 4y ago
Or the HTML editor built into Netscape Navigator.

fswd 4y 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 "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!

Alexbades 4y ago

usrn 4y 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/confuse you/someone else.

hallway_monitor 4y ago
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 4y ago
  Flutter is terrible for different reasons.
- SemanticStrengh 4y ago
  Except it's not elegant nor expressive, it induce much higher complexity and coupling. A major failure.
- aloisdg 4y ago
  like winforms?

triyambakam 4y ago

Reading these comments it looks like almost no one read the article or read very far. The main point isn'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: > ... 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.

SemanticStrengh 4y ago
The only flaw of the article id that it fails to mention devtools workspaces

mashaole 4y ago

Try Teleport.io Quarkly.io Framer.com

mateomorris 4y ago
Also primo.so

code_duck 4y 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.

bambax 4y ago

The promise of "no code" has been around for as long as there has been... code. 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.

dheera 4y ago
Agreed. In fact I detest Markdown, and use a subset of HTML for all of my notes. It's much more syntactically consistent and easier to read. I know <b> means bold and I don't have to memorize how many asterisks correspond to bold vs. italic vs. underline. 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.

chiefalchemist 4y ago

A tool, any tool, has an intended purpose and a sweet spot. Try to pound nails with a screwdriver and you're, well, um, screwed. 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.

norswap 4y ago

> glimpse of 2012: > > HTML5 is barely adopted; the web is run by <table>. > Whatever isn't run by <table> is run by Flash. > "Does it work in IE6 though?" 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.

rsync 4y ago

In the mid-early years of the WWW, (think 1999-2003) I taught several different completely non-technical people how to create web pages with straight html. 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.

Blackthorn 4y ago
I think we as professionals tend to overestimate how difficult the basics are for people. 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.
- frostwarrior 4y ago
  IMHO boot camps are for coding like going to the gym is for exercise. 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.
heavyset_go 4y ago
Until recently, front end development meant knowing how to use HTML and CSS, same thing with web design. 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.

biotinker 4y ago

I have a personal blog that I occasionally update to write up projects I do. https://biotinker.dev/ https://biotinker.dev/ 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.

kgbcia 4y ago

no it doesn't. i was there for Geocities, angelfire, tripod, myspace. once you know how to copy and paste

reactordev 4y ago

I didn't read the whole article. I couldn't. I couldn'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). 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.

joenathanone 4y ago
What's wrong with tables? Datatables are my jam!
- Saoshyant 4y ago
  There's absolutely nothing wrong with tables when properly used for data. 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.
  - gabereiser 4y ago
    Yup, no grid, no flex, the only way to ensure your chopped up photoshop design would work was with 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.

temporallobe 4y ago

I’m gonna argue both sides. 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.

croes 4y ago

>To keep the context manageable, I'll stick to React + Tailwind (with official support for Next.js) simply because that's the stack I'm using and it's wildly popular today. 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.

mattlondon 4y ago

Sounds to me like the author should perhaps stop and think a bit more before "firing the arrows". 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.

irrational 4y ago

> Why the hell do I have to write it by hand? It's slow and it's boring. 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.

donmcronald 4y ago
If you tried something like SceneBuilder (JavaFX) you'd probably change your mind. At least for me, using a visual tool to do layouts saves a ton of time. Even if there's some fine tuning at the end, just being able to do the basic layout is some much easier with a GUI. 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]. 1. https://www.tablesgenerator.com/markdown_tables https://www.tablesgenerator.com/markdown_tables
jillesvangurp 4y ago
If it's slow and boring, automate it. That's your job as a programmer. Repetitive work is ideally suited for automation. It's not about typing faster but being creative without getting bogged down by the keyboard. 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.

atoav 4y ago

The weird thing about HTML and CSS is: I know it could have been better if somebody took today's requirements and turned them into both a markup and a stylesheet language. 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.

wraptile 4y 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: [%url https://example.com https://example.com "see my example" %] to <a class="article-link" href="https://example.com 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. 1 - https://github.com/Granitosaurus/shortcoder https://github.com/Granitosaurus/shortcoder

kuramitropolis 4y ago

Just write Pug lol https://pugjs.org/api/getting-started.html https://pugjs.org/api/getting-started.html

jordiburgos 4y 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. Low-code is more realistic than no-code.

cetinsert 4y ago

Everyone that hates feedback loop delays, we build the 0-wait, 0-reload, 2-way sync web playground! Sync𝗛𝗧𝗠𝗟.io Try our open beta at: https://SyncHTML.io/y/ https://SyncHTML.io/y/ Blog post explainer: https://efn.kr/b/sync#new-playground https://efn.kr/b/sync#new-playground (demoing our programmable embeds) Multi-device sync: https://www.youtube.com/watch?v=s7WlIcYAm-s https://www.youtube.com/watch?v=s7WlIcYAm-s

amadeuspagel 4y ago

I'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'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? Why don't we have browser dev tools that are worthy of the name, that are really development tools, not just debug tools?

kiawe_fire 4y ago

We seem to be intentionally running away from what the author wants. 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.