How can Ecommerce Web Development be made easier?

The following is soul searching, reflecting debates I have been having with myself over recent months. What is the right way to build an ecommerce web frontend? The challenge is there are continual new techniques coming out that deliver improved web performance. Great! The user experience is better! But at what cost? Do we have to train developers up on “yet another technique to make a fast site”?

This is all shooting the breeze. I have no plans to build any of this. I am more curious as it feels current approaches are not ideal. But what is ideal? Feel free to leave an opinion in the comments below.

Why is web development so hard?

There are many complexities to web development:

  • CSS
  • JavaScript libraries (the sheer number of them)
  • Cross browser compatibility
  • Server side rendering and page hydration
  • Collecting analytics and A/B testing
  • React/Vue/Angular/Svelte/… (insert your favorite framework)

Frankly, if you are a web developer I don’t think I need to convince you that development on the web is not “easy”, especially if you try to get into the latest techniques.

Some tools are definitely better than others. I have really enjoyed playing with tools like React/Next.js that give great turnaround time (make a change, see the result). But they still operate at the leaf level of web technologies.

So what have I seen that I like?

Blocks and Layout Hierarchies

One thing I liked about Magento is the layout hierarchy. It is not perfect, but I think it is good to think of a page in terms of higher level concepts, “blocks”. (This concept is of course not unique to Magento.)

Blocks in Magento are still defined in terms of HTML templates and you still have to understand web technologies in terms of flow of control, URLs, how to pass around context etc. I would prefer to get as much of that as possible out of the definition of pages, to allow the implementation to change without the page structure definition needing to change.

My head scratcher however is whether to also use blocks as the extension points. In Magento extensions could insert additional blocks before/after existing blocks, replace existing blocks, and so on. This meant that blocks needed to be relatively fine grain. I am not sure I like that block granularity is influenced by extension points. I wonder if a better approach might be to allow blocks to define extension points somehow so extensions plug into blocks rather than manipulate the layout tree. (Let extension developers request where they would like to hook in, then release a new version of the block that supports it.)

Components and Styling

I really like the idea of components (web components or React/Vue/etc components). I like the concept of being able to have experts build building blocks that others can then use without understanding the plumbing inside. I want to get all the HTML/CSS/JS magic down into a leaf level technology and out of my face.

Note that a block would be built from components, probably using a templating language. React uses JavaScript to give powerful flexibility. There is some merit to this, but it ties higher level definition to a particular technology choice (and I am trying to abstract away from that). So I am more tempted to use Mustache or a similar templating language for iteration etc.

Maybe a theme is a different set of component implementations obeying the same API. That way a block references components, but can be themed. Extension points may also be related to assembling components into a block, rather than at the page layout layer.

In terms of CSS, I would rather not have to learn CSS. I don’t mind the presentation formatting which is relatively straightforward, but the structural controls can get ugly. Maybe just use grids and bad flex? Not sure. There is the question of stylesheets and themes that come into the picture. I do want to have abstracted out the font to use on a site (which could be as simple as CSS variables). My main dislike of not using CSS not being able to leverage all of the cool CSS authoring tool support.

Higher Level Page Assembly

What I then want to be able to do is define my site in terms of higher level concepts (like blocks) without any CSS or HTML in sight. I don’t want to know about server side rendering, hydration, caching, bundling, CSS minification, etc. (Okay, I do want to know enough to debug things when they go wrong!)

I want the platform to worry about all of those pesky details for me. If a new smarter optimization technique comes along, great. The platform can translate my higher level page descriptions to use the appropriate technology under the hood.

That way it can generate a PWA, SPA, MPA, or whatever. My page definition should not have to change. I want the benefits of new technologies without the pain of having to learn them! Let an expert worry about how to convert my higher level page language into optimal HTML, CSS, and JavaScript. Changing SPA to MPA might require components to change, but ideally not blocks or layouts.


Dreaming is easy. I have no plans to build any of the above. But it does not “feel right” to me to build ecommerce pages in terms of low level technologies such as JavaScript. The frontend technology stack best practices changes too rapidly. As such, some way to define the interface in a higher level language is required which can support concepts such as extensions, and map down to multiple implementation strategies allowing the user experience to be optimized without knowledge of developers.

The risk in introducing levels of abstraction is that performant sites could be harder to build, as the developer is at the mercy of the quality of the tool.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: