New modern and lightweight frontend theme experiment

[fballiano]

I've had this idea for more than a year, but I couldn't make it really work. I dedicated a bit more time to it lately and I'd like to share my idea and the results with you now.

What we have now: RWD

I think RWD is still great today, but there could still be areas of improvements to make it more modern, but changing it means breaking all derivatives so... we'll probably never touch it.

My idea

I called this project-experiment "Lanzarote", as the beautiful island I live on.

I wanted to use a 2023 stack, so I chose:

• CSS framework: TailwindCSS + DaisyUI
• package manager: Bun

At the moment this new theme inherits RWD templates, but my original aim would be inherit base instead, which are less opinionated.

The idea is to write less phtml possible and less CSS code possible and rely as much as possible on tailwind's @apply functionality as shown in Lanzarote's main styles.css file.

Screenshot of the first pre-alpha version, category page

Pros

• modern stack
• lightweight
• highly customizable

Cons

If you use it "the old way" (adding your custom CSS file inheriting the theme) I'd say there's no con.
But if you want to customize it "the proper way", then:

• learning curve for tailwind/daisyUI
• you need a javascript runtime (Bun) to compile the CSS

Project status

mega-pre-alpha-prototype

Feedback

What do you think about this experiment?

[addison74]

Anything tasteful other than Magento flavor is well received. I touched a little on the subject here #1825. Meanwhile, Alpine JS became very popular for different tasks and it has a paid version with a lot of features.

I spent a lot of time with both Bootstrap (more than a decade) and Tailwind frameworks. Both have advantages and disadvantages. I am using more Bootstrap 5.3 at this moment and I could migrate pretty fast a lot of website from version 3 & 4. In the case of Tailwind, you have to make your own rules, to use each class in a logical order to be easy to find. When the number of used classes is large, it is increasingly difficult to follow the source code and it becomes tiring, this is in my opinion a disadvantage of Tailwind. The problem gets even more complicated when you want to change the behavior of an element on the size of the screen.

[fballiano]

I didn't remember #1825 at all :-)

I also like and worked with bootstrap, but it is a bit too opinionated (which makes it easier) while I was looking for something more generic.

But most of all, with bootstrap, AFAIK, you'd have to rewrite all phtml files in order to inject the class names, while with tailwind I can use the @apply, as shown here in order to apply the funcionality of a css class to an element that doesn't have that class, gamechanger in this case, IMHO.

Also, DaisyUI do (for tailwind) what bootstrap does ;-) adding the pre-styled components

PS: I wouldn't use js frameworks like alpine or any other, since we don't have an API first approach

[empiricompany]

Interesting approach, I hope to find the time to take a look at it. Personally, I prefer an approach with Gulp and Sass without any framework, but leveraging the power of modern CSS rules.

IMHO Tailwind isn't meant to be used through @apply; in this way, it becomes harder to debug. I've tried it myself but found that its use is indeed better when applied directly in HTML using utility classes.

For a new modern theme, I was contemplating something completely indipendent that includes all the necessary blocks and css classes but isn't built on top of RWD cause base and rwd theme include smore not necessary html elements or should be restructured

[fballiano]

I wouldn't use sass or gulp cause modern css at the end of the day do almost everything already.

My idea was to start from "blank", not "rwd", but for sure I wouldn't have to have another 100 phtml files to maintain and debug, that for me is a total turn off .-)

[empiricompany]

I find Gulp useful because through its plugins, I can optimize various things. For example, I can clean up unused CSS or switch between development mode with sourcemaps and production mode with minified files. Anyway, good job its an interesting approach! I want to try it out and see what advantages and disadvantages it may have.

[pquerner]

What is the goal of this project?
Show how a theme should be built in OM in 2023?
Having theme files less bloated and more split up in smaller parts (think of subparts from twig and so on)

To be used for new vendors?

[fballiano]

the goal is to:

• simplify the phtml basing everything on the "base" theme (well ok it's not based on rwd ehehehe at the moment) and have zero or almost zero phtml
• use a modern technology like tailwind and generate modern css, not floats all over the place (still, rwd is beautiful, i'm not criticizing it)
• get feedback, maybe I was hoping for some "hey that's cool let's build on this" but I didn't get much positive feedback so probably it wasn't a good idea

EDIT: I still believe that OM should only have a base template, use a modern css stack that allows for us not to have dedicated css classes, decoupling the CSS logic from the phtml logic, extendable, light, fast

[pquerner]

Reason I am asking is, do we anticipate lots of new vendors joining OM or creating from start using OM and therefore the time building this is justified?

My realistic view is probably not. Therefore, although a very nice idea, I feel like its kinda a waste of resources.

All vendors sitting on OM currently, or making the switch from M1 currently, already have their themes ready. I am 99.99% sure they wont make the switch to a new theme during that transition.

I am no frontend guy however, therefore I am always very pessimistic about stuff in the frontend. So take my comments with a huge smile, if possible and dont let it disregard you.

[fballiano]

you're probably right but many themes I see are still outdated and not very performant so evaluating a new one could also contribute to enstablish OM as a real alternative for a new project instead of just a temporary solution before it dies.
as I've always said, I don't want to dedicate hundreds of hours to babysit a dieing project, I'd like to have new air into it, both backend and frontend, that's why I pushed for many big changes (sometimes incompatible) during the past couple of years :-)

[pquerner]

Well, in that case I guess its best to go the scheme "magento backend" and something else frontend. and the two only talk through a middleware. But building the fundamentals for this are also not an easy task, seeing how a OM instance can be customized that I work on.

BUT, thats how its "in front of my eyes" right now. Maybe I dont see the "no phtml files" like you do, currently and both of us mean the same thing (or same result, walking different paths).

Like for me, I've always hated phtml files. Coming from the TYPO3 world with the fluid rendering engine its like 200 steps backwards. (But thats what time does to you, and thats how PHP kinda started, so its "understandable") So maybe its exactly how you want it to be in the future: new render engine (or alternative) and build a theme on top of it.

Still, thats a very huge time investment. For basically "free".
(Maybe I could see it being a "paid" extension, where developing happens on a protected repository..?! But then again, do we have vendors interested in this or is this just to make our developer-hearts happy?)

[addison74]

Making OpenMage a desired product requires a large and financially motivated team. At this moment we are at the stage where everyone voluntarily contributes something, mainly because these people are managing OM stores. If we take a look into the PR or Discussions sections, many interesting ideas were drowned after endless discussions.

[addison74]

I recommend reading this book https://www.refactoringui.com/. It is written by the one who laid the foundations of Tailwind CSS.

[m-michalis]

Just read this discussion this morning so I'll give my insights so far:

In the last 4 years I got bored by theme vendors with the classic "include random old/outdated js/css libs in head/body-end" method. At some point I researched webpack and frontend frameworks (react, angular etc). I could not decide which framework to commit so I did not.

I created a pure js/css project using webpack:

• single entry point for each main OM route (catalog_product, catalog_category, cms_index_index, cms_page etc)
• Each entry point had a dependency on a default.js file that was loading global css styles and js libs
• not implemented routes just loaded default.js.
• Webpack output to <project_root>/dist. A custom OM block loads files (built entry points) from /dist folder depending the layout handles (ex. catalog_product.[hash].js).
• With overridden Mage_Page_Block_Html_Head i loaded css files with same logic.

I used bootstrap@latest, jQuery, swiper at start, importing only required ES6 classes. I was worried about 3rd party OM modules such as an advanced filters navigation modules, infinite scroll, ajax cart etc, but in the end it was easy to just disable these, create my own js libs/corresponding OM controller endpoints.

I happened to find arrowjs at some point and liked the idea so I created a js module that handles all OM catalog stuff (both category/search results rendering, incl navigation/filters etc).

With the above I still had to create a new theme with bootstrap css classes and handle custom megamenu/mobile menu logic.

My latest find:

• observer for controller_action_layout_generate_blocks_after
• if request isAjax() then depending on the <module>_<controller>_<action> i prepare a json response (i already have the required blocks)
• Mage::app()->getFrontController()->setNoRender(true);
• $response()->setBody(Zend_Json::encode($response))->setHeader('content-type', 'application/json');
• $request()->setDispatched(true);

There is enough custom stuff in-between the above flow like:

$controllerAction = $event->getAction();

$module = $controllerAction->getRequest()->getModuleName();
$controller = $controllerAction->getRequest()->getControllerName();
$action = $controllerAction->getRequest()->getActionName();

if($controllerAction->isAjax()) {
    $route = implode('_', [$module, $controller, $action]);
    // to create <module_dir>/Model/Catalog/Category/View.php for example
    if ($model = Mage::getModel('foo/' . $route, ['action' => $action])) {
        $model->prepareAjaxView();
    }
}

and i can expand on it for anyone interested.
With the above if you load a ex. category page with ex. X_REQUESTED_WITH=XMLHttpRequest you'll receive a json (products, filters, state etc), otherwise the default OM html output.

---

I'm just saying that a lot is possible here and there could be some features added (like my latest find) to support a 2023-2024 OM theme with nice pagespeeds and easily manageable frontend (npm update, test etc.)

[kiatng]

1. if ($model = Mage::getModel('foo/' . $route, ['action' => $action])) { why is it a model instead of block?
2. Are arrowjs pages rendered server-side? How do you serve them from OM? Does it require a nodejs server?

[m-michalis]

1. a block to extend what? Mage_Core_Block_Abstract ? could only be for the purpose of caching (which haven't done) but we can cache collection if that is something we could do.. also there is no flat_catalog compatibility here, if there should be.. Using a model can be clean.
2. arrowjs is frontend only. just handles the reactivity. makes ultra fast updates to the dom.

No need for nodejs server. its all frontend. I've created an arrowjs template for how a product should render in all places except product view (ex. category view, search results, all sliders etc). With this i can handle all events like qty,addtocart, otherstuff, from the same js class called Product. It only needs a json object (name, price (which is rendered in magento), images) to be able to render it whenever/wherever i want. On the Product class i've implemented stuff for addtocart (which is another class Cart that handles all updates, like updating the minicart, and listens for Product events).

The arrowjs reactivity also helps extremely when having to show a loading icon etc (cart loading after adding to cart, loading icon when clicked add-to-cart button). A simple example:

this.state = reactive({
    cartLoading: false
});
html`<a href="#" @click="${e=> {
         this.state.cartLoading = true;
         //addtocart logic
         this.state.cartLoading=false;
         }}">
     ${html`${() =>this.state.cartLoading ? MiniCart.loadingSpinnerHTML : feather.icons['shopping-bag'].toSvg()}`}
    <span>Add to cart</span>
</a>`

[kiatng]

In OM's MVC, the View V is rendered in blocks. And you have $model->prepareAjaxView();, which I presume output the View. Do you plan to open source your theme? I'm interested to take a dive if it is.

[m-michalis]

It'll take some time to provide a theme that is working on all cases. I have done this for 3 of my clients but each have slight different code and some parts are not working (ex. tier pricing etc).

But I can provide a base boilerplate to start developing your own theme (the javascript codebase and the backend methods i used for ajax calls that replace normal OM html logic).

Some notes:

• there is no prototype.js here (incl all of its related js libs) or any default OM js stuff. I've even blocked all js from 3rd party modules via Head.
• ALL javascript/css are generated via webpack
• There is actually too much documentation to write
• There are many missing system > configuration sections. ex. it works despite the theme you have enabled

If there is going to be a new theme for OM, I think it should be a different project (composer + npm packages) as it affects many default logic.

Regarding OM's MVC:

• Either have some logic to build a dynamic block class to generate json response (which can be used in an observer like i did)
• Create controller actions but I don't like how it currently handles output (i'm talking about Mage_Core_Model_Layout::getOutput() ). It is built for assembling HTML.

As OM does not have any builtin support for JSON output (the output of a block to be a PHP array and a flag for example to json_encode it), you have to directly set the response body and headers inside the controller action.

Currently for me its a mix of server side html generation (cms pages/blocks, main layout) and frontend html generation (render product catalog or search results). I try to keep frontend stuff as minimal as possible.

---

I really like astro.build (if you haven't checked, check it out!!) for frontend as you really can make the project headless without being restricted to a JS framework at all. The only problem i'm facing is routing.