A Proposed New Language as an Alternative to HTML, CSS, and JavaScript

Introduction

The languages HTML, CSS, and JavaScript have served well for many years. But do these languages have to be the only choice forever? How about an alternative language to serve a special use case of web development. Sometimes a web developer wants to create a web site or web application in the quickest, easiest possible way. In order to serve that use case, I propose a new language as an alternative to HTML/CSS/JS. Here I describe my thoughts in designing the new language. For information about the proposed new language, please visit http://www.alternativetohtml.info/ .

Automation of Layout and Style

When using HTML and CSS, the web developer must control layout and style in detail. Let us try to automate layout and style. The browser, not the web developer, will determine all aspects of layout and style. The web developer writes XML code that defines the content items and logical relations among these items. Using an advanced algorithm, the browser should be able to render a reasonable layout and style.

Automation of Responsive Web Design

Now that the browser automates the layout, it also automates responsive web design. Using the new language, the developer writes the web page code without regard to the user’s device, which may be a smart phone, tablet, desktop, or even TV. The browser knows its viewport dimensions and renders a suitable layout on the user’s device.

One Language Instead of Three

Web development is simpler using a single, unified, XML-based language rather than multiple languages like HTML/CSS/JS. As style and layout are now automatic, there is no need to use CSS with the new language. We also would like to eliminate the need to use JavaScript. A procedural programming language like JavaScript is too complex for the non-technical users. The most important JavaScript functionalities, including AJAX, can be supported by XML elements in the new language.

Farewell to the Scrollbar

Browsers render HTML content downward in the viewport, allowing the user to scroll down to bring more content into view. Scrolling is not really the optimal user experience. With the new language, if the content on a page does not all fit within the viewport, then the browser divides the content into multiple screens. Instead of scrolling, the user shifts between consecutive screens.

Conclusion

The new language will allow people to create web sites or web applications very easily. Layout, style, and responsive web design are automatic and require no effort by the web developer.

Replacements to the HTML/CSS/JS trinity aren’t realistic. HCJ is used on over a trillion web pages; a majority of the world’s text is written in it. It’s not great, but it’s sufficient, and combined with its terrific momentum, that’s good enough to prevent anything new from cropping up.

To have any chance of succeeding, a replacement needs to be significantly better than what exists, preferably to as many stakeholders as possible. It’s not clear to me that this proposal is better for almost anyone. The lack of styling capabilities makes it extremely unattractive to companies and web developers; they can’t make a page look the way they want. The lack of JS means you can’t do anything non-trivial in it; this can only be used for static documents. (Any tricks you enable via declarative markup can at best address a tiny subset of functionality.)

The only group that this seems to be better for are people producing relatively simple documents, and targeting a lot of different devices. These people already have the ability to solve their problems; responsive design isn’t easy, but neither is it very difficult. This would just make that particular use-case simpler, assuming your document is simple enough to be addressed by whatever declarative relationships you define. It’s nice to make this use-case simpler for non-technical people, but it can be done with today’s tools - see, for example, Medium’s GUI allowing non-technical people to produce articles with high-quality layout.

Additionally, almost all of the proposed functionality reproduces existing HTML elements, just with more verbose names.

To be frank, this has absolutely no chance of going anywhere in its current form. To have even a remote chance of changing anything, it needs to be broken down into individual additions, such as the declarative ajax functionality. (This has been suggested in the past.) The layout algorithm can instead just be a browser “reader mode” that can be used on simpler document, as much of the semantics you express already exist in HTML.

The only one positive I could see initially was the paged based rendering instead of scroll. However this already has been suggested as an addition to CSS as part of the CSS round and various other specifications (I’m aware it’s no small task, however it is far more likely than wheel reinvention).

Layout and style will get complicated or simplified by introduction of CSS grids. Automation isn’t a very good idea when you need to present data in a certain way.

Separation of concerns is very important. As a screen users I bump into problems with JavaScript based pages because I can’t read them. Now that the designer is almost useless, who will make sure that the page is at least somewhat accessible? Developer who relies on advanced algorithm that the page is generated as they want it? I don’t think so. Semantics, styles and additional functionality are separated for very good reason.

Scrolling, required reading: http://bokardo.com/archives/scrolling-easier-clicking/ Personally I hate clicking on “next page” link

Conclusion: I am not saying that this is a very bad idea and you should feel bad. You didn’t think this through, there are big holes in it.

To get a feel for how well it covers your use-case, a compiler can be made to convert SWeb to the Web. It would, for one, clarify how the advanced algorithms you mention work in practice.

However, from a superficial look, I don’t believe I would have any interest in using SWeb, as HTML’s non-draconian error handling and default layout make writing quick-and-dirty pages easier, and I am not inconvenienced by the use of scrolling pages.

Which problem does this try to solve?

The web developer writes XML code that defines the content items and logical relations among these items.

This basically sounds like semantic (X)HTML 5, with structure indicated by (for example) nested <article>, <header>, <aside>, and so on, possibly supplemented with ARIA attributes to indicate other relationships. Additional HTML extensions, such as <template>, could cover the “declarative AJAX” request, although I am not sure what other functionality you are considerd.

So what you’re really asking for are better default browser stylesheets, that take advantage of the full HTML 5 semantics and CSS 3 media queries, to map the content to responsive layout designs. For example, automatically styling lists inside <nav> as a horizontal menu bar that switches to a drop-down on small screens, or pushing an <aside> to the side if the screen is wide enough. With the latest CSS proposals, a stylesheet could even cover paginated views as an alternative to scrolling (although this is not yet well supported in browsers).

Changing browser default styles is never going to gain support, because existing web content relies on the existing defaults. Introducing new default styles would require a reset on every page that has custom styles.

Instead, perhaps all that is needed is a good list of resources for ready-to-use stylesheets, served up by high-capacity content delivery networks, that rely on semantic HTML and ARIA without needing any special classes or scripting. The web page author would then only need to code good HTML, and add a <link> to one of these standard stylesheets.

Job interviews and other activities are keeping me too busy to respond to the replies to my proposal. But I will respond to all replies as soon as I can.

Let’s address these criticisms one by one. The first criticism says the following.

Replacements to the HTML/CSS/JS trinity aren’t realistic. HCJ is used on over a trillion web pages; a majority of the world’s text is written in it. It’s not great, but it’s sufficient, and combined with its terrific momentum, that’s good enough to prevent anything new from cropping up.

If the new language becomes a standard, then the trillion web pages in HTML/CSS/JS do not go away.
Browsers would continue to support HTML/CSS/JS while supporting the new language.
Nobody will want to convert existing web sites to the new language.
But when people create new sites, they will have a choice.
Some will choose HTML/CSS/JS in order to control layout and style so that everything looks exactly as desired.
Others will choose the new language in order to put material on the web in an extremely easy way.
Still others will code a prototype in the new language and later convert to HTML/CSS/JS.
The next criticism says the following.

To have any chance of succeeding, a replacement needs to be significantly better than what exists, preferably to as many stakeholders as possible. It’s not clear to me that this proposal is better for almost anyone.

The proposal is better for people who want to create web sites or web applications quickly and easily.
People who are not programmers will especially appreciate the ease of use.

The lack of JS means you can’t do anything non-trivial in it; this can only be used for static documents. (Any tricks you enable via declarative markup can at best address a tiny subset of functionality.)

The new language is not just for static documents but also for web applications with, for example, forms, AJAX processing, and pop-up boxes. The declarative markup can address a lot of the functionality of HTML/CSS/JS, except of course control over the layout and style produced by the browser.
I want declarative markup to take over important JavaScript functionalities as much as possible.
I realize declarative markup cannot take over all JavaScript functionalities.
JavaScript would still be enabled with the new language.

The only group that this seems to be better for are people producing relatively simple documents, and targeting a lot of different devices. These people already have the ability to solve their problems; responsive design isn’t easy, but neither is it very difficult. This would just make that particular use-case simpler, assuming your document is simple enough to be addressed by whatever declarative relationships you define. It’s nice to make this use-case simpler for non-technical people, but it can be done with today’s tools - see, for example, Medium’s GUI allowing non-technical people to produce articles with high-quality layout.

The new language is not just for simple web pages, as it allows any combination of content on a web page.
When non-technical people create web sites, they have more difficulty than we think.
Web experts know their material so well that it does not seem difficult.
Therefore, web experts underestimate the difficulties of the less technical people.
As for Medium’s GUI, that allows people to post articles on Medium’s web site.
Medium does not allow people to create their own web site, under their own control, with any desired type of content.

Additionally, almost all of the proposed functionality reproduces existing HTML elements, just with more verbose names. The layout algorithm can instead just be a browser “reader mode” that can be used on simpler document, as much of the semantics you express already exist in HTML.

The overall functionality of HTML and CSS is to identify content and specify its layout and style in detail.
The overall functionality of the new language is merely to identify content, while letting the browser determine layout and style. With the new language, the browser cannot just render mechanistically, but rather has to figure out what layout suits the content on the particular site.
Browsers will have to implement a novel and advanced layout algorithm.
This will pose an interesting and challenging research problem.

My last post addressed the remarks from tabatkins regarding the proposed new language.
Here I address the remarks from ygebi.

You raise the issue of accessibility of sites in the new language.
I understand that semantic elements lead to greater web accessibility.
All the XML elements in the new language are semantic elements.
Some accessibility functions can be automated by the browser, while others will require accessibility standards to be added to the language. I see no reason why accessibility with the new language cannot be as good or better than with HTML/CSS/JS.

You identified an article as required reading about scrolling versus clicking.
But the article is about designing a web site using current web technology, whereas I am talking about changing the web technology.
With current technology, the user believes “scrolling is a continuation; clicking is a decision”, as stated in the article.
Instead of current technology, imagine the scroll bar or scroll function is gone, while the browser presents a special control to switch between pages in memory.
Users will come to understand and get used to this new control.
Therefore, users now see this control as a “continuation”, not a decision.

In this post, I address remarks from espadrine, Michiel, and AmeliaBR.
Espadrine says the following.

To get a feel for how well it covers your use-case, a compiler can be made to convert SWeb to the Web. It would, for one, clarify how the advanced algorithms you mention work in practice.

Writing this compiler would be a large task.
I have only begun to think about how the advanced layout algorithm might work.
Michiel asked the following question about the proposed new language.

Which problem does this try to solve?

The problem is that web development is more difficult than it needs to be.
The new language makes it very simple.

Before addressing the remarks from AmeliaBR, I will say something about the new language and its rendering by the browser.
The new language includes the “ContentGroup” element which is a container for the user interface.
(Maybe the element name should be “Container” instead of “ContentGroup”.)
Containers can be nested in parent containers.
Each container contains content elements and/or child containers.
The browser will render a user interface that reflects this organization of containers.

AmeliaBR concludes that “perhaps all that is needed is a good list of resources for ready-to-use stylesheets”.
That is an interesting alternative to my proposal.
I have two concerns about this alternative.
First, will it serve the general use case of putting any combination of items on a web page and showing it in a way that reflects some logical organization of the content?
The second concern is how the web site creator, who may be a software engineer, web designer, or non-technical person, will deal with the list of ready-to-use stylesheets.
Will the creator have trouble figuring out which stylesheet to use?
Once she decides which stylesheet, will the page look reasonably good?
Will she have to modify some styles manually?
That can be troublesome to the less technical people.
I want to make everything really simple, straightforward, and predictable.

Web development isn’t supposed to be easy, it’s a skilled trade that takes years of experience and learning to become even competent in for most people. Just because anyone could build a website, doesn’t mean everyone should.

I wouldn’t want Joe Bloggs, who had just made a spice rack in an evening class, to come a build me a bespoke fitted wardrobe, and I wouldn’t want someone who claimed to be an electrician, simply because he rewired a lamp, to come a rewire my house. I wouldn’t want a web developer, who only worked with your language, to build me a website if they couldn’t get their head around HTML/CSS (JS).

Trying to come up with a new language to make it easy to learn for the masses isn’t really solving a problem in my eyes. People have created “web apps” and interfaces, to allow people to piece together simple websites from templates and themes. In my eyes, this would just be a complicated and incredibly unlikely way to work around this same problem.

I honestly can’t see this ever being implemented, certainly not in it’s current form as others have said before me. Trying to take on the building blocks of every website on the internet, to create something simpler to use is maddening in my eyes. I wouldn’t consider it in a million years, it’s a herculean task.

I feel the barrier of entry to beginning to learn web development is already low enough. There are many websites out there created by hobbyists or people just starting out, and sometimes scarily, these people start selling their services not really knowing what they’re doing. They put out substandard websites, lowering the quality and value of our profession, which aren’t accessible or secure at the very least.

To me, this just screams of the same problem, if people start creating basic simple websites in your language. Inevitably people will find constraints with it, and try to twist it into something it’s not. Trying to get browser implementers to take on a new fundamental language, and port it out to thousands of devices and billions of users is just unfeasible.

Sorry for the negative post, but if I were you, I would want people to be honest with me on this.

In addition, trying to add a little positivity to my previous comment. If you’re that passionate about making web development available to the masses. Then why not dedicate your time to informing and educating to a level that people who couldn’t understand HTML/CSS/JS could benefit.

Teach them of services available out there to help create these kinds of websites, or even create another service yourself that people could use to make websites such as these.

Most people who aren’t technically minded, would find even your solution complicated and trying. People who are too afraid to venture into HTML/CSS, aren’t going to be relieved to see a “simpler solution” where they piece together a website with XML. It will still put them off, and scare them.

Here I respond to some of the remarks from Lietnek.
In his first post, Lietnek says the following.

Trying to come up with a new language to make it easy to learn for the masses isn’t really solving a problem in my eyes. People have created “web apps” and interfaces, to allow people to piece together simple websites from templates and themes. In my eyes, this would just be a complicated and incredibly unlikely way to work around this same problem.

I looked briefly at some of the existing tools to allow people to piece together simple websites from templates and themes. These tools either limit what one can create, or force one to tweak code manually.
My new language is better because it is always easy and handles any combination of content items.

In his second post, Lietnek says the following.

Most people who aren’t technically minded, would find even your solution complicated and trying. People who are too afraid to venture into HTML/CSS, aren’t going to be relieved to see a “simpler solution” where they piece together a website with XML. It will still put them off, and scare them.

The new language is very simple to anyone who understands XML.
The non-technical web developer already understands his content.
Using the new language, he merely describes this content in a straightforward way.
He need not handle the more difficult tasks of layout and style, as the browser automatically does these tasks.

Lietnek says at the end of his first post, “Sorry for the negative post…”.
Apology accepted, but really there is no need, as I have a thick skin.

@tstyles - perhaps you’d be interested in the new project Mavo, which has similar goals to what you were proposing.

A quote from https://www.smashingmagazine.com/2017/05/introducing-mavo/

Our vision is that JavaScript, server backends, and databases should become the “Assembly of the Web”, mainly needed for specialized or high-performance tasks. For everything else, HTML and CSS should suffice.

Okay so you do have a point that we need to teach HTML/CSS/JS and we can’t really tell people including developers and enterprises to change into a new languages (unless it is more powerful than the three combined but that seems impossible in few years because these three took years to develop and mature to the way they are now). But @tstyles is right, we need something less overwhelming and more intuitive. I’m currently studying computer science but my history with computer programming and development started way long before when I was only 12. I have had my hands on several “sub-domains” if you could call them, like game development, desktop software, app development, web development, etc… and to be honest I feel that the HCJ trio are the most messy code I have ever seen in my life. Whenever I see a an HTML page, I feel discouraged to read it or add to it. Add a few tags here and there and add some frameworks and you have a overly complicated looking HTML code. Not to mention, that to me, compared to other programming languages, JavaScript actually is a weak one and has a lot of flaws and undesired behaviors. There are always hundreds of libraries and frameworks that do similar things, and one library depends on another, and one library depends on other scripting languages like TypeScript and the cycle keeps going. I mainly agree that HCJ should be replaced with one language that do the three, or in other words, generating files that the web browser will understand from the created new language. Of course, at the end, it is just my humble opinion, you sir are the expert in web development and of course hold more knowledge about the subject than me. My position against HCJ trio is due my observation for the need of better programming language than JS and more intuitive code for developers and beginners alike. Maybe sir because you had a lot of experience in HCJ and they are the only languages used to make websites, you have a strong believe they are the best, but HTML was developed in 1990, and now we are 2019, so if you took it from a different angle you might feel that there might be a chance for something new to emerge. (Think why people are using Python while C++ is more powerful (“easier and faster to code with”)).

I admire the ambition here, @tstyles! I think your proposed alternative would work well for websites that have static content that doesn’t include anything complex. One type of website that comes to mind is a basic news site. All it does is give the user things to read and doesn’t require any dynamic capability (CSS or JS).

There is a proposal I happen to come across that classifies simple news websites like this as “Web Publications”. While that proposal isn’t what you’re proposing here, it seems to touch on your overall goal of delegating common complex functionality to browser agents (instead of developers) to make development of websites easier.

Please update us here when you get a chance. I’m curious on what your thoughts have been now that its been over 3 years since your original post.

You find this exact same problem in any language. No matter how strict or loose in typing. The only languages you won’t really find it in, are ones that aren’t widely used.

Yes, it is weakly typed. Like a lot of languages. But for the web, that’s actually super useful because you can write code in a streamlined way that handles multiple contexts. It’s all about knowing how to take advantage of the core language, not abuse it.

On the flaws point, please provide one language that has few “flaws”. Flaws in languages are primarily contextual. What is a flaw in one context is a major advantage in another.

Overall, the trinity of web languages isn’t perfect. Of course, nothing is. However, if you understand them and what browsers do, then you can write some beautiful code. The trick is, going beyond being an average developer that just complains about the languages being wrong. Instead, be the developer that understands why and how things work, and build to play to the strengths of the languages you use.

The only way a new language on the web moves forward at this point to replace the trinity, is by proving it will work. Instead of talking about how we need something else, prove it. Have a functioning engine which works with a new set of languages (1 or more) to replace what we have. Show it can be done more efficiently and in an easier to digest way. Don’t just say it can, show an actual experiment. That is what will get buy-in from developers at large and browser vendors.

@mkay581 asks me what are my thoughts on this topic now that it has been over 3 years since my original post. First, I now believe the new language should be an alternative to using HTML and CSS, rather than alternative to using HTML, CSS and JavaScript. The user of the new language may be creating a simple site with no need for JavaScript, but the user would be able to invoke JavaScript in the same way as HTML, if needed for certain advanced functionalities. These advanced functionalities are sometimes too detailed to be implemented in a simple declarative language.

Second, I believe I should describe my proposal from a different angle. The proposal is to develop and make available automation of user interfaces. Instead of the application programmers coding the UI manually, the user agent (or browser) produces the UI by an advanced algorithm. This algorithm must address layout and style. Layout is the challenging issue. The layout algorithm might have the following general strategy. Recursive or other logic examines many different potential layouts and chooses the best according to a quality score. Every layout has a total quality score that can be computed as a sum of quality factors. Each quality factor is a constant weight times a specific quality measurement.

An automated UI might not look as good as a manually crafted UI, but may serve well for specific applications, or for low budget web sites, or for prototypes of web applications.

What I’m gathering from your post is, you want browsers to become WYSIWYG editors for the front-end. Which, is not something they should be getting into. It’s very much possible to build compose-able components and allow users to build a GUI with layout without touching the declarative code. Someone has to touch the declarations though.

It’s way better to let browsers focus on doing the trinity right and giving us new features within them. Then external companies and projects can then focus on any methods needing to make it easier for users.