What are your plan to replace RequireJS that has reached End Of Life

[ericmorand]

Summary (*)

RequireJS has been in End of Life status for months (maybe even years), as confirmed by its status at the OpenJS Foundation or by the maintainer itself: https://github.com/requirejs/requirejs/issues/1816

Its archaic design makes executing script after it unreliable and unpredictable (see https://github.com/requirejs/requirejs/issues/947 but also the thousand of discussions about this problem here and on Magento 2 community message boards) and it polutes the global scope so it is a very good thing that it is at last abandoned for good.

But it puts Magento 2 in a very delicate situation: the fundamental JavaScript base of all the Magento 2 modules provided by the core and the community is heavily tied to RequireJS, both at the frontend and the adminhtml scopes, and it makes Magento 2 tied to its weaknesses as well.

I'm sure you have been planning the migration from RequireJS to another JavaScript "loader" technology for months (note that I'm convinced it should have been part of Magento 2 to begin with) and we need to know your plans about it.

Proposed solution

Please share your plan to get rid of RequireJS. Professional users need to know where you are headed and at what pace. It's even more important because you propose some paid flavors and our clients shouldn't have to pay for something that is based on an archaic technology that creates issues right now and may fail totally in the near future.

[m2-assistant[bot]]

Hi @ericmorand. Thank you for your report. To help us process this issue please make sure that you provided the following information:

• Summary of the issue
• Information on your environment
• Steps to reproduce
• Expected and actual results

Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:

@magento give me 2.4-develop instance - upcoming 2.4.x release

For more details, please, review the Magento Contributor Assistant documentation.

Please, add a comment to assign the issue: @magento I am working on this

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

  :warning: According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.

:clock10: You can find the schedule on the Magento Community Calendar page.

:telephone_receiver: The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, please join the Community Contributions Triage session to discuss the appropriate ticket.

:movie_camera: You can find the recording of the previous Community Contributions Triage on the Magento Youtube Channel

:pencil2: Feel free to post questions/proposals/feedback related to the Community Contributions Triage process to the corresponding Slack Channel

[lbajsarowicz]

@krzksz ideas? :-)

[victortodoran]

IMO there are not going to be any major changes to Luma. RequireJS EOL or not. These are the several factors I'm basing my statement:

1. All the attention is concentrated on PWA and Venia.
2. All partner extensions depend on the current implementation of Luma.
3. There are several instances of Magento2 many of which just invested a ton of money to migrate to M2 from M1. Telling them they need to change all their frontend customizations is simply not a viable option.

[hostep]

@ericmorand: you might be interested in Hyvä: https://youtu.be/kGRkAQNzL1c?t=21752 (but it's not available yet)

[ericmorand]

@victortodoran , Luma is not at cause. RequireJS is the only JavaScript loader that is supported by Magento framework and core modules. PWA won't solve the issue, except if they also replace adminhtml area by a PWA.

But the issue remains even with themes that are not based on Luma. Luma is not the one that is making use of RequireJS. Every module out there depends on RequireJS for its frontend behavior needs.

Anyway, we need to know their plan: when will adminhtml be replaced by a PWA, for example.

[mrtuvn]

From backend i don't think will have update soon. Store owner will focus on functionality instead look and feel From frontend This is my thought the are plenty way and always have room for improve or decoupling depend on requireJS

1 you can build storefront theme from blank (or even luma) but need a lot effort for maintain and make your site fast. Try to minimal as much js request as possible. Partially loose depends on components/js. The more depend remove the more request will reduce

2 another option throw away unneccessary parts like Hyva theme did (No RequireJs KnockoutJS No Jquery No Less styles use native css by tailwind) No theme extend inherritance from core. Only reused javascript modules or core js modules from magento @wigman will know this best

(Note hyva just born in few months current in early stage. Still missing some part need a lot of work and update)

3 you can start storefront with pwa like pwastudio did

4 none of above way

build storefront from scratch no-depending no-bullshit-heavily-load. But you will have to do all stuff. Noone can backup you

At my thought Magento/Adobe will follow first approach

Hope you guys have a great day Happy coding!

[Eddcapone]

IMO there are not going to be any major changes to Luma. RequireJS EOL or not. These are the several factors I'm basing my statement:

1. All the attention is concentrated on PWA and Venia.
2. All partner extensions depend on the current implementation of Luma.
3. There are several instances of Magento2 many of which just invested a ton of money to migrate to M2 from M1. Telling them they need to change all their frontend customizations is simply not a viable option.

3. They could leave the requirejs technology still there for backwards compatibility, implement the new technology and then completly remove it in Magento 3

[ihor-sviziev]

From @maghamed in Slack in the #appdesign channel:

Dev Guild will consider this question in the upcoming future and get back with results

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 14 days if no further activity occurs. Thank you for your contributions.

[mrtuvn]

Can we discuss more on this

[ihor-sviziev]

@sidolov @sivaschenko @gabrieldagama do you have anything to share with us?

[sivaschenko]

We have discussed this issue internally and came to the following conclusion:

Since it is NOT officially announced that the library is in End of Life status we are not required to do any changes. Even the author of the library mentioned that he is still fixing issues. But, to be prepared before End of Life we will proceed with Fork proposed implementation to prevent BiC and react fastly in short term. In the meantime, we are investigating a replacement solution.

Internal ticket: https://jira.corp.magento.com/browse/MC-40156

Please let us know if you'd like to help with alternatives investigation and propose the solutions.

[barryvdh]

So we're a few months further and so far the only viable options seem to be:

• Pretend like everything is fine and keep using Luma with RequireJS, loading tons of libraries without needing them
• Let Luma/RequireJS die and ignore it, just move to Venia PWA. But Magento developers don't actually want to write just Javascript..
• Kill all the javascript loaders and use 'inline' scripting like AlpineJS to handle simple things like toggles (eg. like Hyva)

I'm not really sure how everything got to where it is now, but on a fresh 2.4.2-p1 install, just and empty homepage loads 167 javascript files (out of 191 total requests), which makes up about 600kb of data (out of 800)

I mean, that can't be normal right? jQuery, KnockoutJS, Jquery UI, underscoreJS, datepickers, timepickers, colorpickers etc all just get required like it's nothing, not sure what for. So probably just getting called down the chain by RequireJS

As far as I'm seeing, only Hyva is currently stilling getting good Pagespeed scores, with the Venia example getting around 40 on Mobile..

[mrtuvn]

From my observe frontend performant improved a lot when compare to previous version. Magento core team already migrating jquery 3.6.0 internally (maybe @sivaschenko will know this). Maybe it's time for us to review/recheck and remove unnecessary stuff. Clean up jquery ui for minimal used. Loose tight-coupling with 3rd party libs (example: requirejs will take time and much more efforts) Imho i don't think magento will get rid of requirejs at the moment.

Other better way are improve old function and also import new lib for improve performance such as lazyload, lazysizes .v.v https://github.com/requirejs/alameda

since jQuery UI modules are now divided into separate files as of https://github.com/magento/magento2/commit/a5c67831e0b6d8974700e7cb134c054c6e9f3131. Upgrade jquery will need rework with much efforts too

Example below ticket/PR for example efforts improvement old functions color-picker by @krzksz improved condition load date-picker (merged)

30647 (authentication-popup.js) (In progress) not available GA (not merged)

28400 (spectrum.js, tinycolor.js) (In progress) not available GA (not merged)

Load draggable and resizable jquery-ui by @martasiewierska https://github.com/magento/magento2/pull/32802 (merged) resizable jquery-ui https://github.com/magento/magento2/pull/32756 (merged)

Eliminate MutationObserver.js (merged) https://github.com/magento/magento2/pull/33384 Eliminate es6-collections.js (merged) https://github.com/magento/magento2/pull/33385 jump gallery fix cls layout shift by @ihor-sviziev https://github.com/magento/magento2/pull/32316 (not merged) captchajs (not merged) https://github.com/magento/magento2/pull/33200

calendar.js (merged) If we can wrap all above in one i thing we can get even better results and perform screenshot js load at 30 june 2021 vanilla base (my own local with all patch, no fancy customises modules 3rd-party)

Current i have found file Magento_Ui/js/lib/logger/console-logger.js load with quite lot dependencies but used in multiple files

We can reduce number of requests by use bundle such as magepack https://github.com/magesuite/magepack

[Leland]

I frankly don't see an easy resolution to this problem. This looks like something that would require a re-architecture of the JS loading system that M2 employs – and I'm not sure Adobe has the appetite to both take on PWA and this at the same time. Perhaps I'm just pessimistic ;)

I'm not really sure how everything got to where it is now, but on a fresh 2.4.2-p1 install, just and empty homepage loads 167 javascript files (out of 191 total requests), which makes up about 600kb of data (out of 800)

For what it's worth, it's kind of always been like this.

We can reduce number of requests by use bundle such as magepack https://github.com/magesuite/magepack

Alas, Magepack appears to be abandoned at this point. It hasn't seen development in what is fast approaching a full year. My team tried it out recently on a v2.4.2 build and found it had significant issues preventing us from using it. The approach @integer-net came up with is way more fiddly (you have to manually browse with a Chrome extension) but works at least.

I really, really wish Baler was still seeing development.

[sivamind]

New Adobe commerce with old outdated ORM, deprecated zend1 ,Knockout js,requirejs etc. Adobe need to think to create new software with same Magento commerce features. for example laravel or nodejs as backend ,frontend vuejs or react etc.

[Leland]

Keep in mind that "old" is not necessarily a justification to change things. If we want Adobe to make substantial architecture changes, we'd want to show what benefit would come from it.

Implementing a better JS loading system that can bundle on the server-side would mean vastly improved P90 load times. Require JS' lazyloading means that slow devices experience incommensurately worse performance.*

Meanwhile, replacing Knockout with {insert library here} would definitely mean better DX. Knockout's documentation is woeful – and there's very little left of its community that can still answer questions online. Only a dozen KO questions were posted on StackOverflow in August, for example, and nearly half of them got no responses (and none of them more than 1). We're not setting devs up for success here.

---

* This is a problem of the platform that is rarely talked about online. FE performance on Luma can be good, but adding almost any sizable module will cause your Lighthouse (or P85 test) performance scores to fall off a cliff. That's because of chained JS dependencies (A requires B requires C), which have to be downloaded not just serially, but after execution. On fast devices, it's negligible since JS downloads and executes quickly. But on slower devices, which I've seen correlated to worse networks, those one-after-another downloads cause your TTI scores and responsiveness to explode. That has knock-on effects for CLS and LCP (which can be addressed by moving your JS to the footer, but don't do that until you've lazily loaded all below-the-fold assets).

That's why implementing things like Magepack or Baler hugely improves your P85/P90 scores – while at the same time not impacting the overall performance of median/P50 users all that much. /rant

[mrtuvn]

seem we still struggle to improve js stack of magento after near 6 years . So reduce chained JS dependencies is only hope for us I expect less js requests, ko minimal version, jquery or another cleaner, fewer widgets built-in (let customer/dev decide to use what they want) my opinions jquery: we still keep use or use cash (minimal jquery version) https://github.com/fabiospampinato/cash knockoutjs keep use but should be minimal reduce external js as much as possible replace to vanilla js alternatives instead rely on jquery https://github.com/sachinchoolur/replace-jquery

[Leland]

Can't replace jQuery, sadly. jQuery UI is everywhere on the frontend and a drop-in replacement doesn't exist. The big rewrite in v2.3.3 to use modules is about as optimized as you're gonna get there.

I'd advocate to keep the focus of this issue strictly on RequireJS since there's so much surface area on the frontend.

[RiccardoRoscilli]

I think you have to rewrite Magento 3 from scratch using laravel and vue.js and get rid of all this rubbish. I just ended a project on Magento 2 and onestly it was a nightmare. The way could be to focus the development on GraphQL and use Vue storefront as frontend.

[ihor-sviziev]

I believe the response to this question will be the following: The luma-based theme will be (or it already is?) deprecated. https://twitter.com/antonkril/status/1058402697332883457

The last time I saw any updates on this topic was 2018.

Maybe @antonkril or @ishakhsuvarov can add more details on it?

[RiccardoRoscilli]

Well I had to fight with very old guns for my last Magento 2 project: JQuery, RequireJS, Kknockout js (!!!). It seems an attempt to make as difficult as possible the frontend developer work.

[Eddcapone]

@RiccardoRoscilli yes, and they even use a very old version of jQuery.

[ihor-sviziev]

@Eddcapone in latest magento versions it's already upgraded to 3.x

[ioweb-gr]

Before trying to explore alternatives I decided to measure PWA venia as well. The results have plummeted to a score of 25 on mobile that's even worse than luma.

The slow start is really a no-go here.

The frontend needs a major overhaul and pwa studio is not that

[mrtuvn]

https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/requirejs just recognise available of this repo but i'm not sure any new feature included or fork from origin.

[wigman]

Before trying to explore alternatives I decided to measure PWA venia as well. The results have plummeted to a score of 25 on mobile that's even worse than luma.

The slow start is really a no-go here.

The frontend needs a major overhaul and pwa studio is not that

@ioweb-gr Sorry to be self-promotional here, but I gave up on Luma and built Hyvä exactly for that reason. Luma is done and PWA is not the solution for largest part of the market.

[ioweb-gr]

@wigman I understand and I've seen the metrics on Hyva however there are some practical reasons not to prefer it.

• It's not part of the Magento 2 platform. It's a third party attempt which may or may not be supported in the future. Your company may be providing support properly now, but what happens in a few years? What happens if the demand for Hyva grows too fast too sudden. Can you guarantee you can cover the demand?
• Now it costs 1000$, how about next years? What if one day you decide to make it 1000 per year? or 5000 per year? Only recently Amasty / Meetanshi / Mageplaza etc etc turned to subscription based models. For a small shop in our market this may be too much of a risk.
• Almost all third party modules provide support for Luma theme and a huge chunk for PWA studio. People are just now starting to make them compatible with Hyva, so the ecosystem is much smaller.
• Hyva's age doesn't guarantee sustainability, it's recently made and doens't have the history to back it up as a sustainable solution.
• You need to keep up with Magento's breaking changes on every version, so to upgrade Magento 2 we need to be certain your theme is already updated and compatible. In some cases with PCI compliance on the table this can be a risk too. While you may be catching up fast now, you may not in the future.

While it may be good for your needs, it doesn't mean it's the solution. Now if Adobe would acquire your company or theme and make it a part of Magento 2 like they did with the page builder, then it would be a long-term viable and sustainable solution, but currently, in my eyes it isn't. It's the same as building the theme from scratch or using a solution like MageSuite or any other PWA storefront project out there that's compatible with Magento 2 e.g. Vue Storefront

Granted, Hyva is fast. But fast is not all that a shop owner needs to choose your theme over other themes. There are comparable themes built based on Magento 2 Blank theme in themeforest with perfectly acceptable scores which provide better compatibility with modules but they suffer from long term sustainability as well as the above reasons I mentioned.