It’s been awhile since I’ve had a chance to clarify both our current status as well as our future direction, so I wanted to do that here.
This blog post will be mainly a high level overview of what's new and different in Liferay 7, but over the coming weeks, different folks from our team will publish blog posts going into detail about the different areas regarding Liferay's front-end engineering).
Where we are currently at in Liferay Portal
The first thing I'd like to mention is an update to my last post about AlloyUI in Liferay 7. If you remember, our plan was to release AlloyUI 4 and base it upon jQuery.
We ended up deciding that this would lead to a very confusing situation for people building on top of Liferay, as it would be breaking an existing API dramatically, but still having it under the same namespace (which would also break for anyone wanting to use the version based on YUI).
So rather than causing developers unnecessary grief, we've upgraded AlloyUI to version 3 (which brings with it an update to Bootstrap 3 and other bug fixes), but we've also decided to sunset AlloyUI and are deprecating it as of Liferay 7.
It's still included by default, and your existing AlloyUI based code will still continue to work (and we'll also still continue to support it for our EE and DXP customers as well).
Of course, the next question might be "What should we use for our code going forward?"
Before answering that, I need to introduce a new library that we've created.
Metal.js is a small and fast library for creating and managing stateful components that is templating-language agnostic, and also supports server-side rendering.
It uses Google's incremental-dom to ensure incredibly fast rendering, as well as an easy to use API that makes creating and reusing components incredibly easy.
What should we use for our code going forward?
We're making of a bit of a strategy change in how we both leverage JS libraries as well as how we advise their use in Liferay.
The direction we're heading in is one in which people have full control over the frontend libraries that are loaded onto the page, as well as making the individual components more reusable and modular.
This means that if you're really into React, Angular or Ember/Vue/etc, and your entire team has been trained on it, then not only can you use that library within the portal (which you can already do), but if you need to reuse an existing Liferay component from your library of choice, then you should be able to import it there as well.
So while we do recommend using Metal.js for your development, as we have found that it solves many of our needs, we want people to feel comfortable using any library they like.
Part of that will involve changing our modules to have minimal dependencies while still maintaining a focus on performance.
The coming blog posts will also touch on some of the highlights of frontend engineering in Liferay 7, such as compiling of ES6 2015, how we're leveraging Senna to progressively enhance existing portlet applications to support single page applications, as well as architectural details and how you can leverage all of these new features in your development.
CSS and Themes
There have been a lot of changes with regard to Theming and CSS in general in Liferay 7, and I'll touch on the big ones.
As I mentioned above, we've upgraded to Bootstrap 3 for Liferay 7. We didn't upgrade to Bootstrap 4, because as of the Liferay 7 release (April of 2016) and as of this writing (August 2016), Bootstrap 4 is still in alpha.
When it is released, if the API changes are still minimal, we should be able to provide a compatibility layer for people to easily upgrade.
Also in Liferay 7, we've introduced our new design language for creating applications, called Lexicon.
Our implementation of Lexicon consists of two parts: a set of components and extensions to Bootstrap and a visual skin that styles it.
These are all still managed by your theme, so you can extend and customize it on a per-site basis.
Sass and SCSS parsing
One change we've made for Liferay 7 that has gotten quite the positive response is that we have removed runtime compilation of Sass/SCSS.
Related to that change, we've also renamed all of our files from using the .css extension to the .scss extension to ensure that IDEs and editors can properly display the right syntax highlighting, and also to prevent any confusion for newcomers.
Lastly, we've also enhanced our build-time Sass parser to use libsass, which means that we will only use jRuby for Sass parsing if your system doesn't support running the libsass parser.
How much of an improvement is this?
One set of SCSS files that we had would often take around 50 seconds to over a minute with jRuby.
With libsass, that time cut down to roughly 3-5 seconds (not an exaggeration).
New and Enhanced Theme Concepts
We've added two new concepts for themes, which are Themelets and Theme Contributors.
Let's say that some of your themes all share very similar functionality or styling. Maybe some parallax scrolling effect, or a dynamic CSS animation. Instead of having to duplicate your code across every theme, you can publish them to the NPM registry, and other developers can reuse them as well.
While you could achieve similar results by extending a theme, this approach allows for maximum modularity.
This is useful in cases where you have some element(s) that exist on the page no matter what site you're on and whatever theme is selected, and you wish for it to be consistently styled.
The most commonly styled elements are the Product Menu, Control Menu, Simulation Menu, etc, but it really could be anything.
Lastly, we also enhanced how themes can be extended. With the new theme tools (which I'll cover in the next section), themes can be easily extended from some other theme, but the tools also allow you to extend from any themes that developers may publish on NPM.
This opens the door for community members to create their own base theme layer, as well as many other possibilities.
New Theme Tools
As some of you maybe have heard, we have a new set of tools designed for theme developers.
One pain-point we've wanted to improve was that for many modern front-end developers, the old plugins SDK model of using Java based tools didn't fit their preferred workflow.
This led us to examine ways we could really improve theme building experience. These new tools, which leverage Node.js and the NPM ecosystem, provide developers with a way to create themes, layout templates, themelets as well as importing themes into the new structure.
We also provide quick tasks for watching your theme for changes and instantly deploying, quickly kickstarting a new theme, and extending from other themes.
More blog posts will be coming soon that go into detail about new theming features from the Bootstrap and Lexicon side, as well as exploring the new tooling in depth.
Again, this is all very high level, specifically because if I tried to go into detail about all of the great stuff in Liferay 7, this blog post would be quite a bear to read.
Look out for the follow up blog posts coming soon, but in the meantime, please feel free to ask any questions you have in the comments.