loading...
Cover image for No more HTML coding, please. Let's make layout to HTML real

No more HTML coding, please. Let's make layout to HTML real

pashaigood profile image Pavel ・7 min read

Do you ever think that handwrote HTML code is expensive, long, redundant and outdated?
I think about it every day, when I create another GUI component or system element. This article is my attempt to overview the current state of the industry, its problems and share the results of my research.

Before we start

Wanna try it right now? Here is the proof of concept.
It shows the concept, it's missing implementation however I think the concept is proven. Details below.

This is my first English publication, please be lenient. Any fix suggestions are welcome.

Glossary

I use "HTML code" and what I mean by this is:

  1. As a HTML development process.
  2. As artifacts obtained after HTML development  -  HTML, CSS, JS, etc.

Intro

About 8 years ago, I expressed the idea that manual HTML coding is outdated and automation will replace it. From that moment, I have been intently searching for solutions to resolve this issue. We already have such tools as Workflow, Bootstrap Studio, inVision, Framer, Supernova, React Studio and many other direct or indirect solutions.
And we also have amazing research on this topic using neural networks, via pix2code or sketch2code.

Unfortunately, I can't find a tool that can be fully integrated into my development process.

So what I do I want? I want to get a layout from the layout designer, break it into components, correct the HTML code, where necessary, add logic, get a library of components and return it all to the designer for future interactions. I understand that it surpasses even the most advanced capabilities of the industry, but this is my dream…

Like Confucius said, the long journey begins with the first step, so I decided to figure out where to start. This is what this article will be about.

The Problem

Before all we should to determine the difference between HTML code and interface:

HTML code - is a semi-finished product, roughly speaking, the result of converting a graphic format to HTML, CSS and other files, intended for further conversion to a graphic interface.

Interface - a product ready artifact of the system with which users will interact.

At the 2020, manual HTML coding is still the main way to create web interfaces, which is quite interesting in itself. This goes against the trends of parallel stacks, such as native and desktop applications, where visual interface design tools are the standard for its creation.

We may argue for a long time why this is so, but as I think, the main conclusions are:

  1. high requirements for the final code and
  2. the need for low-level control

I propose to leave the "HTML coders lobby" outside the brackets :).

HTML coding is complex, requires the use of special techniques and tools to manage, minimize errors and support up to date.

Animations are other big question. Creating of complex animation can be impossible task for many companies because it's very laborious.

HTML coding is expensive, on average it's from 25% of the cost of the entire system for SPA and up to 75% for landing pages.

There is no generally accepted HTML coding theory as such.
The W3C standard is very wide and each developer / team is guided by their own rules and standards.

My solution

First We must to formalize the HTML coding process, define the entities, algorithm and rules. Of course, the topic itself is quite extensive, and its full disclosure is not the goal of this article. Based on this, we consider only the part that is currently interest.

Template

Let's try to define process of template creation.

Step 1

Visually divide into a high-level block tree.
Find the rows and columns of the layout.

Step 2

Semantic analysis, we define the main blocks:

  1. Header
  2. Body
  3. Side bar
  4. Footer
  5. Etc…

Here we immediately encounter an interesting phenomenon, a layout is not always enough to build a full-fledged structure, so the interface designer should clarify the behavior of the blocks. Which suggests the idea that semantic analysis is also not always enough.

And for now, this is enough for us. Here we can divide our task into two large groups:

  1. Technical and
  2. Semantic.

Let's set aside the semantic group for future research and focus on the technical one.

Despite the fact that the HTML code of a picture by a neural network is a very interesting task, in my opinion, it's redundant.
It is hard to imagine a situation when, in a normal workflow, an interface designer will send a layout in the format of a bitmap image.

Most often we have formats created in tools such as Figma, Sketch or Adobe Photoshop, which already contain almost exhaustive information about the layout, the most important thing:

  1. Elements position;
  2. Elements type;
  3. Elements styles;

Obtaining an HTML document based on this information is already a solved problem, as engineers from Figma have already shared their conversion implementation and research results, and services such as Anima are directly built on the synchronization of layouts and interface.

But why didn't such decisions lead to the effect of an exploding bomb and after 2 years there is nothing better than the good old hand-made HTML code?
Here I repeat my opinion the reason for this is two factors:

  1. High quality requirements
  2. Need for control

Control is undoubtedly a necessary thing, but without satisfying the first requirement, it does not really make sense. It will be easier to immediately implement and manage a high-quality HTML code than to try to fix a poor-quality one.

Thus, the first requirement is paramount. But what makes a code to be quality?
If we remove official quality indicators such as LTR, Accessibility and the like so, we will remain with important quality indicators for developers:

  1. Correct tree;
  2. Semantics;
  3. Non-redundancy;
  4. Readability and edibility;
  5. Using of blocks taken out of the stream only where it is needed.

Thus, the main task for automation will be compliance with these criteria.

Let's try to prove that this is possible by building a tree of blocks. Again, to do this, we need to formalize the process and introduce the necessary concepts. Leave a number of extreme cases for future research.

Rows and Columns

Rows

If the position of one element falls into the height segment of another, then they form one row.

Columns

Similarly, if the position of one element falls into a segment of the width of another, then they form one column.

Element Relations

Relative layout

Elements are positioned relative to each other, relying on the flow.
The tree is completed if necessary.

Overlapping layout

Overlapping elements break out of the flow, are positioned absolutely, do not affect the positioning of other elements.

The process of building a blocks tree

Step 1

Define all rows.

Step 2

Find margins of each rows.

Step 3

Select a row for work and determine the type of layout:

  1. Single-column;
  2. Multi-column;

Step 4

For multi-column, determine the type of columns:

  1. Floating;
  2. Grid;

Depending on the type, find indent between the columns.

Step 5

Determine the type of column by the number of elements in it:

  1. Single;
  2. Multiple.

If the type is single, position the element relative to the column, go to the next.

Step 6

For the column type "multiple" we find all the rows.
Rows types are similar to column types:

  1. Floating;
  2. Grid;

Find the margins.
We repeat the entire algorithm while there is at least one raw block.

And now we implement the obtained statements into the code.
Simplification:

  1. Fast implementation covering only ~ 20% of cases;
  2. Positioning errors are expected;
  3. One-level structure of source blocks;
  4. Styles are written to the style attribute;

You can see and play with the proof of the concept here.

Conclusion

Automation of high-quality HTML code is possible without involving weakly controlled machine learning algorithms. This will significantly reduce the cost of creating products and increase their quality. It is also important that this will simplify the work of developers and make its more intuitive and enjoyable.

But further research is needed, and the problem itself requires closer attention of the community to implement a fully functional model and tools based on it.

What's next?

I think the next important step is the confirmation of the concept of controllability. The main factor here will be converting the code to the layout. When the code is changed, the layout will also be updated - creating a two-way binding between the design tool and the HTML code.

It will be great to see any constructive criticism and the discussion. Peace!

Discussion

markdown guide
 

Hi Pavel. There is a lot of good stuff in your post to talk about, thank you very much. For now, let me focus on the first thing that came to (my) mind.

You state: "HTML coding is complex" and "... expensive". In itself these statements don't make much sense (hear me out, not criticism on your article!). In how far is HTML coding complex and expensive? As compared to what other solution? I think this is a central point. We don't really have anything to compare it with. HTML/web standards are the only thing (as far as I can say, any suggestions to the contrary?) that works on ALL platforms (MacOS, Win, Linux, iOS, Android, Chrome OS, WebOS, ...) and devices (desktop, smartphone, smart TV, ...). So, if we truly want to compare web development and its conplexityp/cost with any other technology, we should limit our scope to that technology, to receive truly comparable figures.

In my experience, web development requirements are usually prone to an unreasonable (and unrealistic) scope just because there are potentially so many clients and runtime environments. Any web solution tends to be expected to run on any device. That can't work, and that is necessarily an expensive endeavor.

 

Sebastian, thank you for good question. It's very interesting topic.
Maybe this is not clear from the post, but i compare web stack with native, desktop and gamedev where we have some design tools. Or maybe do you remember Adobe Flash? :).
I will definitely look at this question more closely to formulate closer and better example from the web industry.

 

Now I believe I understand fully where you're coming from. Thanks for the clarification.

In terms of UI editing support ("WYSIWYG") for creating web apps and HTML layouts, I agree that current tools lack sophistication.

We have to draw a strict line between the editors that allow you to create code and the technology behind such code. For example, WinForms and WPF have rich design editors, which help you create code that makes use of the technology behind them (Win32 GDI for WinForms, and the WPF presentation layer making use of DirectX).

I believe the lack of sophistication for current HTML5 design editors has a lot to do with the fact that the tools you compare HTML to (e.g. WinForms, WPF, Java Swing, ...) have basically grown alongside their dedicated technologies. These technologies are kind of DSLs specifically meant to build GUI-based applications with.

HTML5 it is different. First of all, HTML has grown (and keeps growing) independent of any design editors and tools. As such, those tools always lack behind the development of HTML and its use "in the wild". This is unfortunate for those tools as they cannot dictate the "proper" use of HTML. Instead, the users and clients of HTML dictate how it is used and, consequently, how it evolves.

Second, HTML has never been a DSL for web apps. It has always been a markup describing hypertext documents. Consequently, the semantics of HTML has nothing to do with UI technology. That's why, I believe, it leaves so much room for interpretation and hence so much room for possible solutions (many different ways to reach the same goal).

This is what makes the entire process of mapping HTML code to user interface-related concepts very difficult. And this is also why design editors for HTML apps and web pages lack in sophistication.

Sebastian thank you for your attention to the post and the problem!

Definitely, you are right. The main problem is "it happened so historically". I also thought why it happened and came to similar conclusions. Moreover it i'm convinced if tomorrow we will get a finished solution many developers will not use it and that's fine.
But i don't see any barriers to try to change it at least for myself. Maybe that will not cover all possible ways but that isn't my goal for now.

In any case, I hope to see more of your thoughts, this is interesting and suggestive.

 

I think I understand what you mean. Where in most other application development suites, we have some kind of wysiwyg editor, that is used fairly directly, and rarely needs source code "tweaking."
Compare with the wysiwyg editors for html. While I lack experience with current potential solutions, my prior experience is that they are... pedantic, and can be bloatful.

It would at least be nice to have an editor that could understand layout vs component and produce sematic html. Something with the goal of producing html code that the designers don't have to touch, and the coding team doesn't have to cringe over

Agree with you. I sow many interesting solutions like plyoro.com where designer don't have to touch the code. But i did't see a solution where coding team doesn't have to cringe over.
That's why i defined "important quality indicators for developers".I am not saying that the list is complete and absolute right but as start point this is something to work with to produce cringless code.

 

Pavel, I have l10n 🤏 some of your article. 🤷‍♂️ Where cannot understand. Please 👀 review and use if you want. Anyone want to carry on.

PS. What language do you natively speak Pavel?


Do you ever think that handwrote HTML code is expensive, long, redundant and outdated?
I think about it every day, when I create another GUI component or system element. This article is my attempt to overview the current state of the industry, its problems and share the results of my research.

Before we start
Wanna try it right now? Here is the proof of concept.
It shows the concept, it's missing implimentation however I think the concept is proven. Details below.

This is my first English publication, please be lenient. Any fix suggestions are welcome.

Glossary
I use "HTML code" and what I mean by this is:

As a developer's working with HTML, process.

Pavel - 🤷‍♂️ I'm sorry no idea what this means.


Intro
About 8 years ago, I expressed the idea that manual HTML coding is outdated and automation will replace it. From that moment, I have been intently searching for solutions to resolve this issue. We already have such tools; Workflow, Bootstrap Studio, inVision, Framer, Supernova, React Studio and many other direct or indirect solutions.
And we also have amazing research on this topic using 🤷‍♂️ (neural networks?), via pix2code or sketch2code.

Unfortunately, I can't find a tool that can be fully integrated into my development process.

So what I do I want? I want to get a layout from the layout designer, break it into components, correct the HTML code, where necessary, add logic, get a library of components and return it all to the designer for future interactions. I understand that it surpasses even the most advanced capabilities of the industry, but this is my dream…

Like Confucius said, the long journey begins with the first step, so I decided to figure out where to start. This is what this article will be about.

 

Adam, this is exactly what I need. Thank you very much!
I made changes based on your suggestions. My native language is Russian. As you can see, I have some problems translating my thoughts, but I hope this is not an obstacle to communication.

 

Your welcome. 👍

I have the same problem with my open source library, I'm looking for translators.

 

Excellent article. this is indeed the elephant in the room in Web development. I come from such a world like Delphi, where you have the nice WYSIWYG designer and built forms and such and integrate with code. Times did change and all that became obsolete; it all became modular and open, and it's great, but also very time consuming. You mention one tool i love, Bootstrap Studio, I bought it and use it, but yeah the problem is when you GET BACK to make changes. For my PHP/JS dynamic sites you create a "template" and then you can't get back. My partner in development is a designer, he'll use Mobirise or similar, and once he sends me the template we can only fix it by hand, since i've embedded the template/dynamic elements into it.

 

Charly, a very accurate metaphor!
Right, almost no one sees the elephant in the room.
As I recall, Bootstrap Studio is one of the first solutions of the "new wave" of HTML WYSIWYG-editor.
I didn’t like the way they solve the drag&drop problem. Sometimes it’s very annoying :). I think industry can do it better.

 

I think it can definitely do better! I learned quite a few things from their produced code though (which is surprisingly clean in general). The problem in general is standardization; the editor builds its premise by being tied to Bootstrap (which I love but sometimes you might change libraries). The general open nature of HTML/CSS/JS coding (and even worse when you include PHP) makes it really complicated to build a drag & drop solution to cover all/most cases. But I think it can be done, specially if the big ones pay attention (Microsoft!)

 

Шаг 4

(Haven't found a way to emphasize it privately on dev.to, sorry.)

 
 

I have to say that having read your article, I think I place a much higher value on the quality of the markup than I think can be achieved by automatically breaking down a design into HTML blocks. HTML is intended to be machine-readable. Prior to applying styles, the content flow should resemble a text document, with all text and images in the appropriate flow. Are we saying that we should automate document creation in the same way to save people from having to determine themselves when there should be a new paragraph or a header?

I appreciate the experience of creating HTML could be streamlined. Autocompletion and WYSIWYG editors might help in this but so much of web page's meaning comes from the markup that for many use cases outright automation would be detrimental to our understanding of the page.

The case for web apps is different, but similar. If you're creating an interface with inputs, buttons etc. This information could be derived from a design. Key intentions might be lost in the act of automatically interpreting the design into HTML however for example tab flow (where the row and column distinction wasn't made clear by the designer). Responsive layouts may become awkward if the content is processed in a way that changed the order at different breakpoints, leading to duplicate or unoptimised markup.

I think you may be on to something for some use cases, but please don't overlook the true reason HTML exists, and that's to give us a machine and human readable language that gives the correct meaning and emphasis to content.

 

Riley, thank for your point of view. As you can see i have a different one and this is normal. And i'm not the only one :). In my opinion we are now entering in new era of HTML - WYSIWYG 2.0
The small list of teams that work on this issue:

  1. yotako.com
  2. relate.app
  3. studio.design
  4. plyoro.com
  5. animaapp.com
 

Yeah this post seems to me to completely misunderstand what the point of html is.

 

Hi pavel, great post,
I agree with the point everyone writes markup differently.
Automation of high-level HTML code does not seem an optimal solution. Why not create a designing tool that renders html.
Also, Development of such kind of technology where designing tool itself creates the code ( not technically ) has been around for a while now, technologies such wordpress, Drupal support many page builder (elementor, wp backery etc) which are layouting tools used to create webpages, why not create something like that?

A designing tool which will automate a standardized HTML code, it has to be created from scratch and will require lot of research on how layouting tools are created ( I would love to be a part) . this way more people from developer and designer community can use one tool for design and development purpose.

Hope this helps.

 

Hi Wahid,
Any helps are welcome! If you have ideas or thoughts or free time for research, please, contact with me in linkedin.

 

Definitely, please, can you share me your linkedin profile I tried finding but couldn't.

 

I find it interesting but I'm also thinking that you find issues where they never were.
HTML is a simple semantic static markup language to define structures and components. After trying the way you define interfaces on different platforms like windows, android iOS and so... I would prefer to keep with HTML+CSS to be honest.

From the productivity pov html has nothing to do but css does a lot. You could fight for getting a result or you could make it at first try, depending on your experience and workaround.

 

HTML is very expensive if you use it for layout, or if you use a CSS 'methodology' like BEM that requires too much from your HTML. (BEM is a technique, not a methodology, especially because BEM is actually a way to avoid CSS, not use it).

Try not doing things like that, then you might find HTML not very expensive at all.

 

Good Blog post dude!
At least you're developing on it.
Biggest problem is that people have different way of writing HTML, some use semantics, some don't.
Standardized HTML is necessary before we start developing a good automated solution for it.

 

Absolutely agree with You. Without any standards it's very hard to automate.
I see two different ways to solve it problem:
The first way is concentrate on one solution and try to promote it as the common case.
The second one is implement a simple tool for that. Where every one can define their standards.

I hope to find time to research this issue.

 

Nice article bro,
In my company we have developed a (near) zero code platform using angular, we followed the element based approach where each div/ span/ input etc are elements with certain properties
It is very helpful for developing web applications but we didn't try it for websites (landing pages/ product promotion pages)
Animations are also currently not possible for us
Based on my experience in developing this I'm thinking that it is easier build standards for web applications but not for websites

Web applications: Control Panels etc.,
Websites: Landing pages, Promotion pages w/ o animations etc.,

 

Interesting, can you share a link? Or it's not a public solution?
About websites vs web applications. It's strange, on my opinion website is more easy to automate.

 

Yeah it's not a public solution

 

I was thinking it is complex too. To much time in trying to get elements exactly where you want them. I was working on something. Kind of stopped. But it allows you to use winforms designer. Then it links to a project bridge that converts csharp to JS.

 

Great article thanks for sharing it.

 

Great! Actually I'm working on this subject, to create web site without coding, or without too much coding. Are you interested in turning your theory into code:)?

 

Thx sir! Yes, I'm currently working on the concept of 2-way binding and after that I plan to implement the model it in code.

 

Another awesome article from Dev.to for nobody's problem in real life.

 

umutakyol, thank you for your comment. It's great that anyone can share their point of view, but I have my own, and it is different.
It will be nice to see your argue opinion on the problem.