Writing HTML sucks and No-code doesn't help(rogovoy.me)
rogovoy.me
Writing HTML sucks and No-code doesn't help
https://rogovoy.me/blog/writing-html-sucks
166 comments
> 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.
N.b. that is only really the case for React/React-flavoured frameworks. Other frameworks - notably Angular - still keep HTML and CSS in their own dedicated files (n.b. in Angular you can include the HTML in the component too, but obviously this is only really something you'd want to do for simple and small components for the same reasons that JSX is a problem).
I feel like we're headed down the same old road we had before where people were conflating jQuery with JavaScript. React is not the only way, even if it is popular now. jQuery was in the same position React is now, but today is largely forgotten apart from a few people still using it - I would urge people to remember that and try to keep an open mind and broad-horizons especially in the world of JavaScript Frameworks.
N.b. that is only really the case for React/React-flavoured frameworks. Other frameworks - notably Angular - still keep HTML and CSS in their own dedicated files (n.b. in Angular you can include the HTML in the component too, but obviously this is only really something you'd want to do for simple and small components for the same reasons that JSX is a problem).
I feel like we're headed down the same old road we had before where people were conflating jQuery with JavaScript. React is not the only way, even if it is popular now. jQuery was in the same position React is now, but today is largely forgotten apart from a few people still using it - I would urge people to remember that and try to keep an open mind and broad-horizons especially in the world of JavaScript Frameworks.
I’m aware, it was tongue in cheek. From my perspective (startup accelerators/incubators) it seemed like everything was react for the last 6 years.
Don’t conflate my sarcasm with my understanding of javascript.
Don’t conflate my sarcasm with my understanding of javascript.
I know little enough about the topic that I took your statement at face value. I appreciate the commenter pointing out that you only spoke about the react world. Your sarcasm did not come across as such.
> Writing HTML back then is very similar to writing it now
Not at all. The author may have gotten some minor details off, but all of that was present on some level in various quantities. I worked on enterprise software back then and it was a matter of editing HTML in ASPX to manually update your JS libraries. It was also a matter of manually linking your HTML tags to thousands of lines of CSS in typically a single file. It was a gigantic pain in the ass to do on a large code base with hundreds of pages and it meant acting like a human compiler/package manager, carefully grepping through to make sure you didn't miss something when you upgraded JQuery to version 2 or that your CSS class rule didn't accidentally cascade changes to some non-related context and throw your div 16px off-center. It was mind-numbingly dull and extremely error-prone.
It was back then that I realized that despite the fact that some of our web code was written in server-side C#, it by no means could keep up with the need to make dynamic fluid interfaces on the client-side. The lines of code in JS had grown higher than the lines of C# over many years. And yet the tooling was still treating JS as if it were an animated cursor plug-in. It did not have first-class tooling just yet, and JS was missing some critical features (like native modules) that would make it better to work with. This is at least part of why JS was hated so much back then and there's still quite a bit of hate that lingers from that era. It was very frustrating to work with.
It got dramatically better over the next few years, but there was a lot of churn between Bower, yarn, npm, webpack, etc. Even Node.js I believe split off into io.js back then until it re-merged. AngularJS was originally adopted because it solved a lot of these problems for devs with a kitchen sink solution, but it did so in a proprietary, non-scalable way. The JS ecosystem eventually surpassed Angular's capabilities and now we're able to freely move between React, Angular, Vue, Solid, etc while still using the same tooling.
Centering divs was still surprisingly difficult in 2012. Flash was already on life support, for sure, by then, but Flash websites were still out in the wild. Everyone was waiting on HTML5, but it took a couple of years for IE to get retired, for Edge to get released and for Safari to catch up to much of the spec. IE was still a significant market share then. CoffeeScript was at its peak in popularity probably in 2012. The author got a lot very correct in this article. The gist of what they're saying, though, absolutely true.
Not at all. The author may have gotten some minor details off, but all of that was present on some level in various quantities. I worked on enterprise software back then and it was a matter of editing HTML in ASPX to manually update your JS libraries. It was also a matter of manually linking your HTML tags to thousands of lines of CSS in typically a single file. It was a gigantic pain in the ass to do on a large code base with hundreds of pages and it meant acting like a human compiler/package manager, carefully grepping through to make sure you didn't miss something when you upgraded JQuery to version 2 or that your CSS class rule didn't accidentally cascade changes to some non-related context and throw your div 16px off-center. It was mind-numbingly dull and extremely error-prone.
It was back then that I realized that despite the fact that some of our web code was written in server-side C#, it by no means could keep up with the need to make dynamic fluid interfaces on the client-side. The lines of code in JS had grown higher than the lines of C# over many years. And yet the tooling was still treating JS as if it were an animated cursor plug-in. It did not have first-class tooling just yet, and JS was missing some critical features (like native modules) that would make it better to work with. This is at least part of why JS was hated so much back then and there's still quite a bit of hate that lingers from that era. It was very frustrating to work with.
It got dramatically better over the next few years, but there was a lot of churn between Bower, yarn, npm, webpack, etc. Even Node.js I believe split off into io.js back then until it re-merged. AngularJS was originally adopted because it solved a lot of these problems for devs with a kitchen sink solution, but it did so in a proprietary, non-scalable way. The JS ecosystem eventually surpassed Angular's capabilities and now we're able to freely move between React, Angular, Vue, Solid, etc while still using the same tooling.
Centering divs was still surprisingly difficult in 2012. Flash was already on life support, for sure, by then, but Flash websites were still out in the wild. Everyone was waiting on HTML5, but it took a couple of years for IE to get retired, for Edge to get released and for Safari to catch up to much of the spec. IE was still a significant market share then. CoffeeScript was at its peak in popularity probably in 2012. The author got a lot very correct in this article. The gist of what they're saying, though, absolutely true.
Around 2012 there were all kinds of static prebuilding frameworks rising again, and by 2014ish pandoc was very popular already.
Personally I switched around 2015 to writing most of my web pages in markdown (well, or commonmark) because I got fed up of repeating myself too often in HTML.
VIM isn't a great IDE for HTML and all its syntax highlighting quirks either, which contributed to the markdown migration.
The beauty of markdown is that it's so lightweight, you can use it for dynamic lazy loading as well. There's almost zero overhead for layouting information for the text if you do it right.
Personally I switched around 2015 to writing most of my web pages in markdown (well, or commonmark) because I got fed up of repeating myself too often in HTML.
VIM isn't a great IDE for HTML and all its syntax highlighting quirks either, which contributed to the markdown migration.
The beauty of markdown is that it's so lightweight, you can use it for dynamic lazy loading as well. There's almost zero overhead for layouting information for the text if you do it right.
Yeah, prebuilding frameworks like Jekyll in 2013 changed the game for some. However, as much as I love markdown, the issue in my post was with the OP's assessment of what web development was like in 2012 which was off base.
Most enterprises at the time weren't using markdown outside of engineering documentation. The rise of JIRA during this time period helped a bit as they had their own flavor of markdown-like syntactic sugar. We started to explore other ways of generating pages. Ruby on Rails started gaining serious traction ($1B+ VC backed startups using it). Things like haml existed to make writing html "fun again" (my words). Which gave rise to other processing languages to spit out HTML from lessons learned.
It was around this time that microservices started to be a thing to replace those old enterprise SOA architectures (hello jboss). The application server began to die in favor of self-hosted apps. Docker was new. Spring Framework was relatively new. Bootstrap was just released. There weren't any standard css frameworks that provided as much as Bootstrap did at the time.
<script type="template"> was a thing. Backbone.js was used often. Underscore.js as well (Jeremy, again, sorry about Coffeescript, they can't all be winners).
Now we have web components and I'm so happy we do. It's refreshing to be able to do the things we wanted to do back then but couldn't without some other framework.
I've been around a long time. I started doing web development in 1998 right out of high school. I've written all kinds of web apps, platforms, services, etc.
I still like writing my content in markdown.
Most enterprises at the time weren't using markdown outside of engineering documentation. The rise of JIRA during this time period helped a bit as they had their own flavor of markdown-like syntactic sugar. We started to explore other ways of generating pages. Ruby on Rails started gaining serious traction ($1B+ VC backed startups using it). Things like haml existed to make writing html "fun again" (my words). Which gave rise to other processing languages to spit out HTML from lessons learned.
It was around this time that microservices started to be a thing to replace those old enterprise SOA architectures (hello jboss). The application server began to die in favor of self-hosted apps. Docker was new. Spring Framework was relatively new. Bootstrap was just released. There weren't any standard css frameworks that provided as much as Bootstrap did at the time.
<script type="template"> was a thing. Backbone.js was used often. Underscore.js as well (Jeremy, again, sorry about Coffeescript, they can't all be winners).
Now we have web components and I'm so happy we do. It's refreshing to be able to do the things we wanted to do back then but couldn't without some other framework.
I've been around a long time. I started doing web development in 1998 right out of high school. I've written all kinds of web apps, platforms, services, etc.
I still like writing my content in markdown.
[deleted]
Vim with Emmet and the right tweaks is very good if your job is churning out HTML. I've had a few projects that would have been endless slogs with nearly any other setup get completed at lightspeed.
This setup's strength is its own downfall though. If you don't have the arcane keystrokes and useful patterns burned into your muscle memory you would be better off with almost anything else.
Hopefully if this project gets off the ground they will remember that many of us write HTML as a small component of our jobs rather than it's sole focus.
This setup's strength is its own downfall though. If you don't have the arcane keystrokes and useful patterns burned into your muscle memory you would be better off with almost anything else.
Hopefully if this project gets off the ground they will remember that many of us write HTML as a small component of our jobs rather than it's sole focus.
Maybe the author confused 2012 with 2002.
In 2002, J2EE was having the first adoption steps, while .NET was still hot out of the factory.
Many companies were adopting Vignette or Coldfusion.
AOLServer, PHP, mod-perl and Zope were the FOSS alternatives.
Dreamweaver, Frontpage were everywhere on designer computers.
Definitely not 2002.
Many companies were adopting Vignette or Coldfusion.
AOLServer, PHP, mod-perl and Zope were the FOSS alternatives.
Dreamweaver, Frontpage were everywhere on designer computers.
Definitely not 2002.
CF, PHP, cgi scripts in Perl, that sounds like 2002 to me!
You brought me back with Zope though, man, totally forgot about that. J2EE had a huge head start over .Net which was just coming out of microsoft to replace VB6/OCX development. I remember when C# came out how awesome it made me feel. C++ like syntax but without having to worry about memory (naively). It was great.
It did not solve the VB ASP problem, only allowed you to write your page backend in C#. Asp, Asp.cs
It sucked for about 7 years until Asp.Net MVC came out.
Tooling went from notepad/vim to Dreamweaver, to Visual Studio/Eclipse and back again.
You brought me back with Zope though, man, totally forgot about that. J2EE had a huge head start over .Net which was just coming out of microsoft to replace VB6/OCX development. I remember when C# came out how awesome it made me feel. C++ like syntax but without having to worry about memory (naively). It was great.
It did not solve the VB ASP problem, only allowed you to write your page backend in C#. Asp, Asp.cs
It sucked for about 7 years until Asp.Net MVC came out.
Tooling went from notepad/vim to Dreamweaver, to Visual Studio/Eclipse and back again.
Having been part of a MSFT Partner that was involved in the .NET launch for Portugal, I am quite sure that WebForms allowed to use VB.NET.
We were going to adopt J2EE and at last minute our CTO took Microsoft's offer to migrate our product to .NET instead, and be part of the 3rd party products to be shown at .NET launch.
The key developers that were part of this project went on to found OutSystems.
WebForms was great in terms of tooling, that is why Blazor is being positioned as where the still existing WebForms projects should transition to.
We were going to adopt J2EE and at last minute our CTO took Microsoft's offer to migrate our product to .NET instead, and be part of the 3rd party products to be shown at .NET launch.
The key developers that were part of this project went on to found OutSystems.
WebForms was great in terms of tooling, that is why Blazor is being positioned as where the still existing WebForms projects should transition to.
That would then make more sense with his claims.
coffeescript was created around 2009, so unlikely.
No there wasn't confusion in fact he made a reference to the Mayan (Mesoamerican Long Count calendar) ending 2012.
My boss/coworkers hate it when I use divs instead of tables :(
You should mention that using tables for layouts messes up screen readers because it reads the cells off like they're data
https://help.siteimprove.com/support/solutions/articles/8000...
https://help.siteimprove.com/support/solutions/articles/8000...
We only build internal tools and we don't (can't?) hire people who would need accessibility accommodations to begin with. Not making a value judgement on that stance, just telling it as it is.
What's wrong with tables? Datatables are my jam!
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.
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.
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.
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.
Can't say that I still have nightmares about slicing out all those decorative elements out of a PSD file, but I absolutely don't miss that era.
I was explaining how we used to add drop shadows on web pages to one of the younger members of our team a month or two ago and they found it hilarious. An image sliced up into several bits, a table (often embedded in another table) and various other hacks to make everything line up nicely versus a single line of CSS now.
What a time to be alive.
What a time to be alive.
> a compatibly nightmare
With some "giving up", "stopping early" and appending a "...Best viewed on".
With some "giving up", "stopping early" and appending a "...Best viewed on".
Or worse, showing a splash screen that said to please use chrome. Ugh…
I remember doing rounded corners with images inside a 3x3 table!
It was rough early-on. You could do complex layouts with hacks but they worked inconsistently on each browser, CSS itself was inconsistent across browsers, vendor prefixes all over the place. Remember the 'holy grail' layout of three columns, header and footer? Trivial in CSS Grid of course, but practically impossible without tables before.
Let alone trying to get the center section with the 3 columns to fill the available window space. Ugh… So glad those days are over.
It's insane to think now that including your good reasons to avoid them one was also that apparently they slowed down the browser doing the layout. Never experienced it but I'm certain some important figures explained it.
Now everything is so slow with all that latest js fad that it sounds like a meme. Things being clunky and slow are accepted.
>There's absolutely nothing wrong with tables when properly used for data.
No, the most annoying thing with front end is new front end developer trying to convert data grip that is obviously meant for tables to divs. Seems like young people trying to be cool to not use tables. Use freaking tables when it is looks like grid, div for other stuff.
No, the most annoying thing with front end is new front end developer trying to convert data grip that is obviously meant for tables to divs. Seems like young people trying to be cool to not use tables. Use freaking tables when it is looks like grid, div for other stuff.
If you're writing JSX the way you write html, that sounds painful too. Html is low-level. Jsx let's you make a high level language for your markup, composing prebuilt things together. You can actually engineer your markup
It wasn’t meant to be taken so seriously. Yeah I agree, it allows you to build up a higher level tag library of components to use for your layout.
I said that because it seemed like every new product was using react. In my corner of the world, it was all encompassing for front-end engineers. Still kinda is.
I said that because it seemed like every new product was using react. In my corner of the world, it was all encompassing for front-end engineers. Still kinda is.
[deleted]
> no one was using tables
2012 was not very far away from the end of table layouts. After all tables were ditched as a layout tool only because they were hardly responsive and a number of people were starting to browse the web on their phones.
The most popular HTML/CSS framwork (Bootstrap) is from the end of 2011. I'm still maintaining an inherited project that I was sure it is using Bootstrap (because, what else?) until I really looked into it (we've not been making changes the the UI for ages) and horror! it's some custom non responsive div based grid layout. I checked the date of the first commits, beginning of 2011. Tough luck.
2012 was not very far away from the end of table layouts. After all tables were ditched as a layout tool only because they were hardly responsive and a number of people were starting to browse the web on their phones.
The most popular HTML/CSS framwork (Bootstrap) is from the end of 2011. I'm still maintaining an inherited project that I was sure it is using Bootstrap (because, what else?) until I really looked into it (we've not been making changes the the UI for ages) and horror! it's some custom non responsive div based grid layout. I checked the date of the first commits, beginning of 2011. Tough luck.
Yeah I called out bootstrap somewhere else in this thread having launched in 2011. It really changed the game as far as standardization of css styles. Yes there were others then too but nothing that had a market impact like bootstrap did.
> 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!
I like that your brain supplied the present tense for all of those time periods except for 1999.
I like that your brain supplied the present tense for all of those time periods except for 1999.
I wrote it on my phone so grammar isn't Apple's forte. Replace use with used.
lol. No worries, Gabe.
I briefly met you once at Senchacon 2013 in Orlando. You probably don’t remember but I do. Good to see you still have your head in the hacker space.
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.
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.
“it is already as easy as it needs to be”
People said this when GUIs were introduced, and when rpm and deb were introduced, and system configuration utilities, and editors like pico, and I even heard people say it about Linux OS installers. This perennial, are-you-tech-enough in-crowd gatekeeping has accomplished nothing but ensure developers are three steps behind everyone else in solving real problems with as little overhead as possible for people who might want to concentrate on running their dry cleaning business or dental practice rather than learn how the order of CSS elements affects the cascade.
People said this when GUIs were introduced, and when rpm and deb were introduced, and system configuration utilities, and editors like pico, and I even heard people say it about Linux OS installers. This perennial, are-you-tech-enough in-crowd gatekeeping has accomplished nothing but ensure developers are three steps behind everyone else in solving real problems with as little overhead as possible for people who might want to concentrate on running their dry cleaning business or dental practice rather than learn how the order of CSS elements affects the cascade.
I read parent’s post as an argument for simple sites where nothing more is needed. If your goal is to convey information in an acceptable format, _and you want to manage it yourself_, it can be hand written pretty straightforward in a notepad, in single html page with a bootstrap include.
If your dry cleaning business needs a page with the opening hours, it’s not more complicate than managing your expanses in Excel. Except for the hosting, which is another story altogether.
To your point, this is also where the value of Squarespace like solutions lies, for people who still want/need to touch their site but win’t go the length to understand how it works.
Now,
> people who might want to concentrate on running their dry cleaning business or dental practice
Do these people even want to deal with a website themselves, and not straight ask someone to build and maintain it for them ? The same way that cleaning business wouldn’t spend their days in Illustrator designing new business cards or posters, they’d ask someone else to do it.
If your dry cleaning business needs a page with the opening hours, it’s not more complicate than managing your expanses in Excel. Except for the hosting, which is another story altogether.
To your point, this is also where the value of Squarespace like solutions lies, for people who still want/need to touch their site but win’t go the length to understand how it works.
Now,
> people who might want to concentrate on running their dry cleaning business or dental practice
Do these people even want to deal with a website themselves, and not straight ask someone to build and maintain it for them ? The same way that cleaning business wouldn’t spend their days in Illustrator designing new business cards or posters, they’d ask someone else to do it.
I’ll bet you somewhere in the neighborhood of 5% off small business owners used a professional-grade Adobe layout product to design their business cards but most have business cards that look approximately they way they want. They probably put them together with a neat WYSIWYG interface with heavy-handed guides that let them go from idea to ordering in a half hour max. Do you think they’d have done that if their choice was to create them with HTML and CSS?
The underlying HTML for their website might be as simple as a very complex excel document if they want to look like they’re from 1994… but a) that’s probably worse than having no webpage at all from a branding perspective, and b) unlike excel, HTML isn’t modeled after their common existing business practices, is a single-purpose tool for them and involves a bunch of other knowledge to make that html useful, like CSS, hosting, accessibility, etc.
If the technology exists to let them intuitively form a webpage like they’re working with clay then why not let them? If it’s easy enough, then why wouldn’t they want to form their own? If nobody wanted to do this sort of thing on their own, Squarespace and Wix wouldn’t exist.
The underlying HTML for their website might be as simple as a very complex excel document if they want to look like they’re from 1994… but a) that’s probably worse than having no webpage at all from a branding perspective, and b) unlike excel, HTML isn’t modeled after their common existing business practices, is a single-purpose tool for them and involves a bunch of other knowledge to make that html useful, like CSS, hosting, accessibility, etc.
If the technology exists to let them intuitively form a webpage like they’re working with clay then why not let them? If it’s easy enough, then why wouldn’t they want to form their own? If nobody wanted to do this sort of thing on their own, Squarespace and Wix wouldn’t exist.
I feel we're discussing a difference in terminology, where to me business card creation sites and Squarespace/Wix are not tools but services.
Case in point, you probably have to order your business card from the site you built it, and you continue paying a monthly/annual fee to Squarespace/Wix once your site is up.
Both tools and services should exist, and there should be something available at every price point. The point I think was just that there are simple ways to build a site if your needs are simple and you're OK with learning how to do it. If you're not there are myriads of other solutions to tend to your needs.
Case in point, you probably have to order your business card from the site you built it, and you continue paying a monthly/annual fee to Squarespace/Wix once your site is up.
Both tools and services should exist, and there should be something available at every price point. The point I think was just that there are simple ways to build a site if your needs are simple and you're OK with learning how to do it. If you're not there are myriads of other solutions to tend to your needs.
The distinction between software and service is irrelevant to this conversation. In this context, a webpage and a business card are functionally the same thing— static advertisement and identification. If nontechnical users have software to create an abstraction which gets written into a machine-readable format, whether than gets sent directly to a web host or business card printer doesn't matter.
I mean hell— most modern professional software development toolchains are at least partly service-based already.
I mean hell— most modern professional software development toolchains are at least partly service-based already.
> The distinction between software and service
I kinda disagree. You are responsible for the first, while the provider is responsible for the second.
For instance when we pay for gitlab or Adobe CS, if it's down it's on us to workaround or plan for the situation and deliver the final product to our clients according to plan.
When we pay for Squarespace, it's on them to deliver the final product to our customers, the puck ends there and if it dies there will be little we can do to help, short of switching DNS to a backup site.
I kinda disagree. You are responsible for the first, while the provider is responsible for the second.
For instance when we pay for gitlab or Adobe CS, if it's down it's on us to workaround or plan for the situation and deliver the final product to our clients according to plan.
When we pay for Squarespace, it's on them to deliver the final product to our customers, the puck ends there and if it dies there will be little we can do to help, short of switching DNS to a backup site.
Ok— Figma is a browser-based SaaS design and vector graphics creation tool— a large chunk of commercially-used vector graphics are made using Figma right now. Figma isn't a service because the end-user doesn't touch it?
Where you're drawing the line between a service and tool is an artifact of your perspective. Whether someone further along in the cycle must push a button to trigger some part of that process or if the code is executed on your local machine, a docker instance on your machine, a docker instance on a server, or wherever else is an implementation detail.
Where you're drawing the line between a service and tool is an artifact of your perspective. Whether someone further along in the cycle must push a button to trigger some part of that process or if the code is executed on your local machine, a docker instance on your machine, a docker instance on a server, or wherever else is an implementation detail.
Web development shouldn't even be a thing in the year 2021. We were supposed to have flying cars, and instead we pay people 3-5x salary of the average worker to make a screen display some text and pictures. But it's fancy text. It requires codes.
This whole industry is a mass psychosis that generates dollars.
This whole industry is a mass psychosis that generates dollars.
>to make a screen display some text and pictures. But it's fancy text. It requires codes.
This rhetoric vastly understates why businesses hire developers: there is far more than displaying text and pictures. Consider Hacker News. The system involves user account creation, security, and the ability to reset passwords. There is a voting system and an input system to record comments.
You need to run backups and set up auto-moderation features. There is spam detection. There is the need for performance and fast loading speeds. The software needs to be maintained over time. The website must be responsive, and adapt to different display sizes (e.g. laptop display versus smartphone). The website should run across different browsers (Chrome, Firefox, and Safari) and on various devices. The website should follow accessibility standards.
There are strong reasons to believe that there are other causes than "mass psychosis" for competently-led organizations to want to hire web developers.
This rhetoric vastly understates why businesses hire developers: there is far more than displaying text and pictures. Consider Hacker News. The system involves user account creation, security, and the ability to reset passwords. There is a voting system and an input system to record comments.
You need to run backups and set up auto-moderation features. There is spam detection. There is the need for performance and fast loading speeds. The software needs to be maintained over time. The website must be responsive, and adapt to different display sizes (e.g. laptop display versus smartphone). The website should run across different browsers (Chrome, Firefox, and Safari) and on various devices. The website should follow accessibility standards.
There are strong reasons to believe that there are other causes than "mass psychosis" for competently-led organizations to want to hire web developers.
> We were supposed to have flying cars, and instead we pay people 3-5x salary of the average worker to make a screen display some text and pictures. But it's fancy text. It requires codes.
Are you aware of what magazine editors and newspaper editors/writers used to make in the heyday of print media (can probably add TV and radio too since the web has eaten that as well)? This is a ridiculous trope.
Flying cars turn out to be limited by laws of physics in a cost effective way and it also turns out that communication, storytelling, software services that automate processes (such as HR, sales pipelines, etc), search, etc are hugely valuable to humanity.
Are you aware of what magazine editors and newspaper editors/writers used to make in the heyday of print media (can probably add TV and radio too since the web has eaten that as well)? This is a ridiculous trope.
Flying cars turn out to be limited by laws of physics in a cost effective way and it also turns out that communication, storytelling, software services that automate processes (such as HR, sales pipelines, etc), search, etc are hugely valuable to humanity.
>We were supposed to have flying cars,
We were supposed to have something that would have sounded really cool to an 11 year old boy, but was actually a profoundly stupid mode of transportation and an especially unimaginative extrapolation of 1950s American life.
We were supposed to have something that would have sounded really cool to an 11 year old boy, but was actually a profoundly stupid mode of transportation and an especially unimaginative extrapolation of 1950s American life.
Many have tried to remove the codes, but looks like text is just the most expressive way to write software.
No-code is to codes, as emoji's are to words... easy to read and use, but also confusing and implicit...
No-code is to codes, as emoji's are to words... easy to read and use, but also confusing and implicit...
Almost anybody who has used a computer before can, in about an hour, quickly compile text and pictures in an animated sequence to present to their team (after they forgot it's demo day) with a thing called PowerPoint. But to make text and pictures for a web site, we can't just fire up a tool and drag and drop some text and pictures. We have to develop software.
It's like every time you want a new chair you get out a two-by-four and a knife and start whittling. But instead of questioning why we whittle our own chairs, we reinvent the knife.
It's like every time you want a new chair you get out a two-by-four and a knife and start whittling. But instead of questioning why we whittle our own chairs, we reinvent the knife.
You must have a good add blocker if you haven’t seen the promos for tools that let you point and click your way to a functional website. There are plenty of storefronts out there built with those tools by people with little or no coding knowledge.
Actually a very good point, things can definitely be better
I tend to come to the same conclusion. we communicate in characters forming words or sentences, symbols, and whitespace. As you indicate, text can be imprecise, but a good author knows how to phrase a sentence such that its meaning is better understood by a reader through varying techniques
you make it seem easy, and yet not everyone can code.
Yet the value of computers and code is almost indispensable.
Yet the value of computers and code is almost indispensable.
I bet those people wrote far more accessible and faster-loading pages than what the average professional web developer today creates. It's weird to see the complexity that's grown out of the latter group, which almost serves as a sort of gatekeeping. Always changing things for the sake of changing them, deprecating simple functionality in favour of doing the same thing in a more complex way, etc. My other suspicion is that Big Browser is pushing them to adopt that insane complexity in order to keep out competitors.
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.
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.
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.
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.
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.
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.
I've been a webmaster for 25 years and never had to learn JS. The vast, vast majority of websites on the internet could have been designed by someone like me who doesn't know JS.
Everything is already in a framework or library, and copypasting a few lines of code from the readme/howto is enough to add a slideshow, accordion menu, or whatever other snazzy but terrible UI gimmick that clients want.
The proportion of websites on the internet that actually need React are close to zero (most sites are cms/crud instead of "real" web apps), yet if you're in the web dev sphere, everything everyone else is building seems to need it. Strange.
Everything is already in a framework or library, and copypasting a few lines of code from the readme/howto is enough to add a slideshow, accordion menu, or whatever other snazzy but terrible UI gimmick that clients want.
The proportion of websites on the internet that actually need React are close to zero (most sites are cms/crud instead of "real" web apps), yet if you're in the web dev sphere, everything everyone else is building seems to need it. Strange.
The zero-knowledge, copy/paste frontend development you’re describing is a big part of why so much of the web is such a bloated mess. It’s certainly not React or other FE frameworks that are the problem. At least not in and of themselves.
> why so much of the web is such a bloated mess.
Citation needed. IMO most of the bloat comes from ad networks and tracking.
Citation needed. IMO most of the bloat comes from ad networks and tracking.
I agree with all of this, yet I can't in good faith tell others who are looking to get a job in this field that they don't need to learn JS, React etc. Most employers are basically only hiring React devs for the front end, to build projects that really don't need it. I'm not a fan of it, but it is what it is.
There's a bifurcation when some of the jobs that used to be done by HTML/CSS webdevs is getting done by engineers writing Javascript, but many (IMHO most) of the earlier 'webmaster' tasks are now effectively done by someone putting content in what-you-see-is-what-you-get CMS.
Webdev has automated the easy parts so much that they need zero development and the main skill needed is in writing good content; and the only stuff that does require actual webdev is those things which are not so simple to become a function in some premade system.
Webdev has automated the easy parts so much that they need zero development and the main skill needed is in writing good content; and the only stuff that does require actual webdev is those things which are not so simple to become a function in some premade system.
> it is already as easy as it needs to be
Maybe it's just because I haven't sat down and spent a few days learning it front-to-back, but I hate CSS. It might as well be GridBagLayout. Just the alignment of elements is magical (or not) and feels like it relies on the way the wind is blowing when you write the code.
For example, something as simple as 'justify-content' in a grid is (from my limited experience) dependent on everything around it. Change something that seems unrelated and all of a sudden your justification breaks and you have to figure out what side effect caused it. Heck, typing 'align' into WebStorm shows me a bazillion possible completions. Why are there 50 different ways to align things in CSS?
Maybe it's just because I haven't sat down and spent a few days learning it front-to-back, but I hate CSS. It might as well be GridBagLayout. Just the alignment of elements is magical (or not) and feels like it relies on the way the wind is blowing when you write the code.
For example, something as simple as 'justify-content' in a grid is (from my limited experience) dependent on everything around it. Change something that seems unrelated and all of a sudden your justification breaks and you have to figure out what side effect caused it. Heck, typing 'align' into WebStorm shows me a bazillion possible completions. Why are there 50 different ways to align things in CSS?
The beauty of HTML is that you don't have to use a new paradigm if you don't like it. You can use any of them, and just like with Perl, there is more than one way to do it.
Did you read the whole article? One of the desired attributes is “Developer-friendly, grandma-unfriendly.” In other words, the goal is not to help people who don’t know HTML. It’s to let people who do know HTML work faster and more visually. Which is especially helpful when you want to fine-the styling, something that was hardly even possible in 1999-2003 (unless your entire site was made of images).
> the goal is not to help people who don’t know HTML. It’s to let people who do know HTML work faster and more visually
I can’t help but think that this would run into the inner platform effect sooner or later.
I can’t help but think that this would run into the inner platform effect sooner or later.
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.
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.
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.
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.
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.
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.
> CSS is a full on programming language
I don't like this insistence on calling non programming languages like CSS/HTML programming languages. What we call programming languages are general programming languages. CSS and HTML are DSLs (In specific presentation and markup languages)
People push back against this criticism because they think it comes from elitism, but the fact is that they're valuable because they're not programming languages, and in the web they're as important as programming languages, so it's not that. Not all computer languages are programming languages, and a DSL doesn't suddenly become a GPL because it's complex.
I don't like this insistence on calling non programming languages like CSS/HTML programming languages. What we call programming languages are general programming languages. CSS and HTML are DSLs (In specific presentation and markup languages)
People push back against this criticism because they think it comes from elitism, but the fact is that they're valuable because they're not programming languages, and in the web they're as important as programming languages, so it's not that. Not all computer languages are programming languages, and a DSL doesn't suddenly become a GPL because it's complex.
100% agree. "It's not a real programming language" has become construed as an attack against anyone who makes a career in tech writing DSLs, now everyone labels anything technical as "programming". Laypeople probably think JSON is programming.
DSLs hardly mean "not a real programmer". SQL is a DSL, and I'd wager some people make more money writing SQL than other mainstream languages.
DSLs hardly mean "not a real programmer". SQL is a DSL, and I'd wager some people make more money writing SQL than other mainstream languages.
You can make all sorts of dynamic stuff with CSS alone, see most Tor websites. Granted it has to be generated, but it works.
> 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.
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.
The problem with something like this is that it's a moving target.
People in 2000 were saying visual editors couldn't match hand-written code, and were right at the time. But I would happily use today's visual editors instead of hand-writing 2000s websites, using only the tools available in 2000, if all I wanted was a 2000-level website.
But so far, every time we've made things more powerful - even if it makes it easier to have a good visual editor - it's also pushed the frontier of what a bespoke experience can give you.
People in 2000 were saying visual editors couldn't match hand-written code, and were right at the time. But I would happily use today's visual editors instead of hand-writing 2000s websites, using only the tools available in 2000, if all I wanted was a 2000-level website.
But so far, every time we've made things more powerful - even if it makes it easier to have a good visual editor - it's also pushed the frontier of what a bespoke experience can give you.
And this is true in many sub-domains as well.
Even things like CSS frameworks.
If you’re doing something trivial, or solving a couple of specific use cases, then a framework full of CSS classes that give you Twitter-looking cards or a no code solution that helps you send an email every time a user clicks a “subscribe” button IS helpful.
But the problem is, once you’ve used the tool for that initial problem, you’re stuck with it. And inevitably, if your thing is successful at all, you will outgrow that tool quickly and need to start making bespoke things to keep up.
I say this not out of gate keeping either - I say this as an overworked full stack software developer who would LOVE to be able to provide a CSS framework or a visual editor to my co-workers and have them produce long term solutions.
But as soon as they find some tool and ask me to help adopt it, it works for them for a couple use cases, and then guess who’s stuck trying to make it work with all the fancy new things we need that then requires extending the tool or working around it entirely?
Even things like CSS frameworks.
If you’re doing something trivial, or solving a couple of specific use cases, then a framework full of CSS classes that give you Twitter-looking cards or a no code solution that helps you send an email every time a user clicks a “subscribe” button IS helpful.
But the problem is, once you’ve used the tool for that initial problem, you’re stuck with it. And inevitably, if your thing is successful at all, you will outgrow that tool quickly and need to start making bespoke things to keep up.
I say this not out of gate keeping either - I say this as an overworked full stack software developer who would LOVE to be able to provide a CSS framework or a visual editor to my co-workers and have them produce long term solutions.
But as soon as they find some tool and ask me to help adopt it, it works for them for a couple use cases, and then guess who’s stuck trying to make it work with all the fancy new things we need that then requires extending the tool or working around it entirely?
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.
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.
Most of the solutions fall into one of three categories
- they don't give users the amount of control they want because fundamentally, HTML and CSS together couple content and layout in a very programmer way... This is been a huge advantage for them as a user interface language because they create user interfaces that can work on many screen and window dimensions, but if you don't wrap your head around the layout algorithm, you're going to end up surprised.
- they try to give users the level of control over content and layout that users want, and the end result is extremely buggy
- they try to give users the level of control over content and layout that users want, and the end result is incredibly verbose and basically illegible HTML and CSS. This tends to cause problems down the road because it doesn't couple well with other tools and tends to cause problems later if somebody has to debug by hand or they want to move away from the tool used to originally create the page.
It's an extremely non-trivial problem to solve.
- they don't give users the amount of control they want because fundamentally, HTML and CSS together couple content and layout in a very programmer way... This is been a huge advantage for them as a user interface language because they create user interfaces that can work on many screen and window dimensions, but if you don't wrap your head around the layout algorithm, you're going to end up surprised.
- they try to give users the level of control over content and layout that users want, and the end result is extremely buggy
- they try to give users the level of control over content and layout that users want, and the end result is incredibly verbose and basically illegible HTML and CSS. This tends to cause problems down the road because it doesn't couple well with other tools and tends to cause problems later if somebody has to debug by hand or they want to move away from the tool used to originally create the page.
It's an extremely non-trivial problem to solve.
I agree with the parent comment, but I also see your point that there is room for innovation. For example, the article mentions flexboxes. Flexboxes have many possible behaviors that a tool could help visualize and decide between.
When someone equals the Web programming with innane CSS knowledge I want to facepalm so hard.
CSS is just a way to present things. 99% of the things you do could be equally solved with a basic HTML4 POST form and no one would be hurt except the guys who desperately needs the round corners to show a three paragraphs of text.
CSS is just a way to present things. 99% of the things you do could be equally solved with a basic HTML4 POST form and no one would be hurt except the guys who desperately needs the round corners to show a three paragraphs of text.
This is true on some level, but not true on another. The reality is that as web products change over time, they bring on new customer expectations. For instance, when searching for something with a finite set of possible results, the users' expectation is that they will see a dropdown with auto-complete suggestions. And on top of that, they expect to be able to navigate up and down the list with their up/down arrow keys. That, as well as a mountain of other examples, cannot be done with CSS.
You can achieve many effects with js/dom although yes emulating CSS is in general absurd goal (slower, more complex). And not everything can be programmatically emulated (except with canvas/webGL/webGPU/SVG/PDF but that is cheating)
99% of the things you do could be equally solved with email.
But it would be a worse user experience.
But it would be a worse user experience.
In fairness, flash used to be a thing, and it was probably 80% of the way there. There's also a fair bit of accidental complexity in CSS. (e.g. position: relative and overflow: hidden having weird-if-youre-not-used-to-them side effects)
I think Wix, Squarespace, etc suit a lot of people's needs pretty well, and they have visual editors. There are businesses that run on those platforms that never had to touch code at all to get their work done.
The idea of a visual editor that replaces code tends to dominate, but I really want better tools to augment it. Firebug and all the descendants of Firebug like Chrome's inspector are a good start, but those tools help you view and make minor edits to your markup tree rather than build it.
I think the problem is that HTML and CSS are so fiddly and so big. Seemingly okay things don't work properly. You end up with an editor that only works on a subset, and then you're back to replacing rather than augmenting.
I think the problem is that HTML and CSS are so fiddly and so big. Seemingly okay things don't work properly. You end up with an editor that only works on a subset, and then you're back to replacing rather than augmenting.
There are things like Qt Designer and Glade for GTK; I don't see why that can't exist for the web. The layout system for most toolkits are less complex than HTML/CSS though, and since CSS isn't that difficult it's just a poor effort/benefit trade-off.
Meanwhile, there are plenty of "website building tools" that don't offer all features but more than enough for most normal non-programmers looking to create a site, and these go back a long time (e.g. Geocities).
Meanwhile, there are plenty of "website building tools" that don't offer all features but more than enough for most normal non-programmers looking to create a site, and these go back a long time (e.g. Geocities).
The comparison to desktop native is interesting because you could also just not style everything to hell with css and...there you are, you are native styled with the web
The default style for the web kind of sucks though, so that's a bit of an issue. It also doesn't include a rich set of "widgets" that you get with Qt and GTK, so you often need to provide your own.
Also both Qt and GTK support styling with CSS by the way.
Also both Qt and GTK support styling with CSS by the way.
> Also both Qt and GTK support styling with CSS by the way.
Except they support what, 20% of the CSS rules?
The same goes for react native btw.
One big difference between websites/webapps and native apps is that your app is also often your sales page - or at least made with the same technology.
You could dress up the box and the press kit for your system-toolkit-using desktop app, but now all that is done on the web, and everyone still wants to stand out. The late-stage desktop app era even saw this creep into those, after all: MS Office's ribbon, Apple's brushed metal, etc.
You could dress up the box and the press kit for your system-toolkit-using desktop app, but now all that is done on the web, and everyone still wants to stand out. The late-stage desktop app era even saw this creep into those, after all: MS Office's ribbon, Apple's brushed metal, etc.
"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,"
The wrong bit there is the word "programmer".
I'm 52 and own an IT consultancy. I've used Wordperfect 4 onwards, Wordstar, manual typewriters, MS Word from 2.0 onwards, Quark Express, Word Star, Open Office, Libre Office and many many many more. I'm very familiar with the notions of leading where you put lead shims in between words to pretty things up and avoid widows and orphans and kerning for a similar reason but between letters (or is it vv, can't remember - don't care) I also run a fair few Mediawikis and I note you picked on the phrase "Visual Editor".
The content should be king, the way you display it should always be second but it should be fairly decent. In my opinion.
FWIW: VE on mediawikis, in my opinion, is quite an enabler.
The wrong bit there is the word "programmer".
I'm 52 and own an IT consultancy. I've used Wordperfect 4 onwards, Wordstar, manual typewriters, MS Word from 2.0 onwards, Quark Express, Word Star, Open Office, Libre Office and many many many more. I'm very familiar with the notions of leading where you put lead shims in between words to pretty things up and avoid widows and orphans and kerning for a similar reason but between letters (or is it vv, can't remember - don't care) I also run a fair few Mediawikis and I note you picked on the phrase "Visual Editor".
The content should be king, the way you display it should always be second but it should be fairly decent. In my opinion.
FWIW: VE on mediawikis, in my opinion, is quite an enabler.
I think the next generation of tools like Figma (i.e. Figma 2.0) may end up being polished and able enough for a semi-technical user to visually build out a whole (bespoke, custom) website and with the click of a button publish/host it.
I know there are extensions available for Figma that allow that right now, but from what I could see they weren't as polished as one would want.
I know there are extensions available for Figma that allow that right now, but from what I could see they weren't as polished as one would want.
Wasn't that possible in software like dreamweaver many years (10+) ago? What's changed?
May have been, but from the little I've seen/read about DW it didn't seem like it was used to create custom-to-the-nth-degree, production-ready websites that interfaced with APIs etc. I definitely could be wrong on that though.
As a teen I tinkered around a bit with Flash animations and Dreamweaver stuff seemed to be related but just web-focused.
As a teen I tinkered around a bit with Flash animations and Dreamweaver stuff seemed to be related but just web-focused.
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.
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.
I always wonder if modern React/Angular/Vue/Svelte developers never learned about the incredible timesaver known as Emmet :) https://emmet.io/
People don't use emmet anymore? It does work with React and Vue wonderfully well.
I am not a modern react/angular/vue developer, but this is still new to me. Thanks!
Oh man it's the best. Everyone should give it a go.
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
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.
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.
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
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
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.
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.
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.
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.
Yep. No-code and ERP consultants charge more than Sr. devs. On paper it’s a deal: 100X productivity for 1.5X the price.
Not to mention security, hacking them is easier than ever. Eg POLA nah
BTW, I’m developing a no-code, no-graphic design platform for prototyping technical apps. So I’m convinced it’s possible to make something useful for them. But not if they are database-first, like of all the no code platforms I’ve seen (MS Access, or query browser like)
Not to mention security, hacking them is easier than ever. Eg POLA nah
BTW, I’m developing a no-code, no-graphic design platform for prototyping technical apps. So I’m convinced it’s possible to make something useful for them. But not if they are database-first, like of all the no code platforms I’ve seen (MS Access, or query browser like)
> 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.
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.
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.
> ... 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.
The only flaw of the article id that it fails to mention devtools workspaces
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.
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.
Flutter is terrible for different reasons.
Except it's not elegant nor expressive, it induce much higher complexity and coupling. A major failure.
like winforms?
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/
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.
Thanks, I needed to be reminded of this game changer!
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.
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.
> 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.
Well, I stopped here. You are a programmer. Typing things into an IDE or terminal or whatever is what you do. Personally I find it enjoyable. If you find typing to be slow and boring, maybe you should go through a speed typing course to learn to type faster.
If 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.
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.
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
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
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?
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?
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.
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.
I'll add this: I don't know how to design and I don't have a designer.
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.
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)
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)
I feel like the author is describing the thought process that brought about Dreamweaver - which made the gap between code and design much smaller.
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?
Why don't we have browser dev tools that are worthy of the name, that are really development tools, not just debug tools?
Is this post asking for Dreamweaver?
Somewhat accurate. I was almost thinking the same.
Or the HTML editor built into Netscape Navigator.
Yes, it appears so. Or maybe Front Page.
I have a personal blog that I occasionally update to write up projects I do.
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.
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.
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.
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.
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 "see my example" %]
to
<a class="article-link" href="https://example.com" rel="noopener noreferrer">see my example</a>
I feel that HTML grew way out of control to be used directly - it's absolutely unreadable and refactoring quickly becomes a huge danger zone even with brilliant existing tools. With IDE watcher tools you can easily setup automated previews to be rendered along side the files you're working on which imho is the way to go when directly working with HTML these days.
1 - https://github.com/Granitosaurus/shortcoder
[%url https://example.com "see my example" %]
to
<a class="article-link" href="https://example.com" rel="noopener noreferrer">see my example</a>
I feel that HTML grew way out of control to be used directly - it's absolutely unreadable and refactoring quickly becomes a huge danger zone even with brilliant existing tools. With IDE watcher tools you can easily setup automated previews to be rendered along side the files you're working on which imho is the way to go when directly working with HTML these days.
1 - https://github.com/Granitosaurus/shortcoder
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.
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.
Great comment
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.
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.
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.
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.
>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.
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.
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.
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.
The commercial Pinegrow editor comes pretty close to what the author wants: https://pinegrow.com
On the opposite side: https://beefree.io/bee-plugin/
Kind of described 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.
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.
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.
Low-code is more realistic than no-code.
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.
Then I remember the immesurable amount of shitty code around the web and I get over it.
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.
> Whatever isn't run by <table> is run by Flash.
C'mon. It's 2012. We call that Flex now . . .
C'mon. It's 2012. We call that Flex now . . .
> 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.
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.
Just write Pug lol
https://pugjs.org/api/getting-started.html
https://pugjs.org/api/getting-started.html
"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.
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.
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/
Blog post explainer: https://efn.kr/b/sync#new-playground (demoing our programmable embeds)
Multi-device sync: https://www.youtube.com/watch?v=s7WlIcYAm-s
the 0-wait, 0-reload, 2-way sync web playground!
Sync𝗛𝗧𝗠𝗟.io
Try our open beta at: https://SyncHTML.io/y/
Blog post explainer: https://efn.kr/b/sync#new-playground (demoing our programmable embeds)
Multi-device sync: https://www.youtube.com/watch?v=s7WlIcYAm-s
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!
It's almost exactly what the author is describing to want!
no it doesn't. i was there for Geocities, angelfire, tripod, myspace. once you know how to copy and paste
html is fine. grids and components suck.
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.