The State of Frontend Infrastructure

As we near the first GA of 7.3, one change we've managed to make was to migrate off Soy + Metal.js and fully onto React.js. The story reminded me of how far our frontend infrastructure has evolved in the past fifteen years that I’ve been a part of Liferay. While this was initially going to be a longer post, due to some user error on my part, I have decided to split this into two posts. This first one will describe where we currently stand internally, and a second one that talks about the history of our frontend.

Internally we’ve settled on the use MVCPortlet for simple UIs, because of the familiarity from developers, speed in build time, and server-side rendering performance. Increasingly though we are leveraging React.js for complex UIs, because of the excellent tooling, terrific open-source community, and the fast turnaround time from design to code. These choices were made because they were the frameworks that work best for our internal needs.

Our community though will often ask which front-end technology they should use with Liferay DXP. As with much of our product, we’ve designed Liferay DXP’s front-end to be technology agnostic. Our answer is always the same: Pick the one you are most comfortable with. Every framework has it’s pros and cons and there are no silver bullets.

If you have no idea which to choose, I've listed a few Java frameworks and JavaScript frameworks with my personal thoughts, so you can find ones you're most comfortable with or interested in.

Java Frameworks

Liferay MVCPortlet w/ Declarative Services

Liferay MVCPortlet has been a staple of Liferay’s core development for the past 10+ years. It was designed from the ground up to be fully compatible and highly extensible for all Liferay needs. The addition of OSGi DS has made it even easier to inject services. It is an easy choice for any Java developer who wants a simple framework.

Java Server Faces (JSF)

Standards-based option that is well supported via the Liferay Faces project and with a choice of a variety of component suites including PrimeFaces, RichFaces, ICEfaces, BootsFaces, ButterFaces, and Liferay Faces Alloy. If you have Java developers that hate JavaScript but want some of the same components, this is a good compromise.

PortletMVC4Spring (previously Spring Portlet MVC)

Spring Portlet MVC is probably the most popular Java portlet framework. Liferay maintains the project now as PortletMVC4SPring. Most Java developers will probably feel comfortable with this choice. While you are currently required to bundle the Spring Framework jars in WEB-INF/lib as a WAR file, we have some optimizations in our roadmap to remove the need of bundling the Spring Framework.

MVCBean (Portlet 3)

This is the latest portlet spec. I haven’t seen this in action yet but you can watch Neil’s DevCon presentation: Portlet 3.0 MVCBean and PortletMVC4Spring for additional information. It sounds quite promising.

JavaScript Frameworks

React.js

React is the most popular javascript framework in the market today and for good reasons. The documentation is excellent, great performance, and a number of components to select from. We believe it is currently the safest choice to use amongst the frameworks and began using it internally. We even provide a set of components to use within React and integration with their cli. If you don’t have a horse in the race, we recommend trying React as your first choice if you would like a JavaScript framework.

Angular.js

Angular is a very popular choice amongst enterprises. The community is robust and there are many components available. Liferay provides good integration with their cli to provide a very fluid developer experience. The library is extremely heavy though causing a noticeable first load penalty. The frequent breaking updates also makes you feel like you’re always trying to play catch up.

Vue.js

Vue.js on paper looks extremely promising. The community is passionate, the library is extremely lightweight, and it seems to fit into Liferay’s design patterns very well. The only thing holding it back is the lack of real world implementations. In time, this may turn out to be the best framework to use with Liferay.

Soy + Metal.js

Liferay has invested several years into Soy believing it was the holy grail. We believed the ability to compile closure templates would provide us the performance of JSP with the reusable components of other JavaScript frameworks. While it came close to achieving some of those goals, we never hit the performance we wanted and more importantly, it always felt like we were the only people using this technology. We’ve moved on and recommend you learn from our mistakes and stay away.

12 Comments

Please sign in to comment.

Hi David,

Thanks for your blog post, it's great to know what is Liferay frontend strategy for the next version.

I think it's great you don't push for Soy + Metal.js any more. These are very good technologies indeed, but nowadays it seems that "market adoption" is much more important for developers than any technical argument (even if very rational). I wouldn't like to end up with pushing people to use some technology they don't know and don't like, as I used to do with YUI/AUI (and finally someone always included jQuery :D ).

Please sign in to reply.

Krysztof,

Great hearing from you again,

We've seen that even within our own internal engineering teams. It is much easier to hire experienced developers who is familiar with React.js than Soy.... and it is much easier to get a young developer to join our company knowing they will be learning React.js than Soy.

Also we gain much greater value as a product creating new features for Liferay DXP than building new dev tools (as much fun as it can be to sometimes)...

Cheers,

Dave

Please sign in to reply.

One of the barriers to front end devs with Liferay is deprecation. By the time you've understood and got something working it's gone. For that reason I tried to avoid getting tangled in anything other than Lexicon.

Choose a technology and stick with it. Stability is vastly underrated. We can't form a community of helpers if you google a Liferay problem and the solution is already deprecated!

Please sign in to reply.

Lee

You are absolutely correct. Unfortunately everything in tech has depreciation and frontend dev seems to be hit the hardest. It feels like everyday there is a new "in" framework and many of us get caught up in the hype.

Internally we are trying to switch our mindsets to determine how we can prevent our end users from getting caught up in these waves.

One new feature we are working on is the idea of a style guide instead of having to create a new theme. Where as themes are subjected to following along with the underlying tech, Bootstrap, style guides will be focused on giving total developer control without losing the value of providing proper branding, look, and feel a company.

Thanks,

Dave

Please sign in to reply.

Thanks for the excellent post, David.

I wonder if you can clarify one point, though: you start by writing "one change we've managed to make was to migrate off Soy + Metal.js and fully onto React.js" but, later, you write "Internally we’ve settled on the use MVCPortlet for simple UIs".

Can you explain what was converted to React and what wasn't?

Thanks!

Please sign in to reply.

Hi Fernando,

The answer isn't super easy to answer with words so instead I will show you an example with one of our newest applications App Builder:

https://github.com/liferay/liferay-portal/tree/master/modules/apps/app-builder/app-builder-web/src/main/resources/META-INF/resources

If you look at the different jsps, it is a standard MVCPortlet and the layout is created using JSPs. But throughout the app we sprinkle react components in areas we feel we would benefit.

I hope this helps provide a better understanding,

Dave

Please sign in to reply.

I am hot on the trail of using web components and LitElement to develop decoupled front-end js apps, while kicking the tires of Liferay's GraphQL api (very exciting). OIDC /w PKCE is taking shape too. open-wc tooling /w rollup is very useful. I am surprised there isn't more discussion on the future of web components and lit-element here in the Liferay community. I hope to share more about 'stuff' I am building (PoC currently), and you can find me lurking mostly in Slack random channel.

Please sign in to reply.

Hey Jack,

I've never heard of LitElement and will need to check it out!

As for web components, I've played with it a bit to see if we could use it for encapsulation but I think our teams have found we often need a full blown react component from their work but maybe we haven't scratched the full potential of web components.

I believe GraphQL is essential for the next generation of Liferay development so I am also very excited that we are finally providing support for it.

I've definitely seen you around in the Slack channels and look forward to interacting with you more!

Thanks,

Dave

Please sign in to reply.

Hi David

Is there any solution in liferay to improve SEO problems in Guest pages when we use React or other JS frameworks?

In pure React apps we can use SSR but in liferay SSR is not available.

And another Question is that does liferay Core portlets ,UI components and Control panel will switch to JS frameworks like React?

As you know better than me JSP and JSF is dead in java applications.

Please sign in to reply.

Hi Nader,

We are still looking at different possibilities to achieve SSR and it is on the roadmap to try and tackle this issue.

One idea I had recently was to use something like prerender.io to output something during compile time.

Another idea we had was to use either GraalVM or j2v8 to achieve SSR during runtime.

Let me know if you have attempted anything that might be viable.

Thanks,

Dave

Please sign in to reply.

Hi David,

Very information details, though wanted to understand your view on multi-instance portlet and handling of view in reach.

With recent uses of AppBuilder table view and placing two table view portlet in one page, both portlets start rendering same result if sorting/searching being performed in one. Both portlets do not have namespace specific parameters.

Please sign in to reply.

Hi Yogesh,

I'm App Builder's Product Manager and I would like to thank you for pointing out this issue to us. I have already checked with our engineers and this bug was already mapped in our backlog and we'll try fix this by the GA4 of 7.3.

Please sign in to reply.

Menu Display

Blogs

Category Filter