Do you have any ideas on creating a “universal version” of Enonic XP, where you combine backend and frontend template engines - so that you can do backend and frontend rendering with the same rendering technology, ie Angular Universal or React similar?
You have done a good job on allowing for frontend tech server side, the next step for me seems to be to allow for more frontend tech applied on server side, ie. Angular or React.
To me it seems a bit strange to still do backend in Java (thymeleaf), when everything else in frontend is javascript. Wouldn’t it be great to do front end and backend template stuff in a common template system?
Perhaps you would like to share some ideas for the future, next version of Enonic?
I am not sure whether you ask about why Enonic XP use Java at all, or just for the rendering. I believe having Java available, even though I hardly consider that it is there most of the time, is one of the strengths of the system. However, you don’t have to use it other than the fact that the code will run on Nashorn.
How you do rendering is up to you, really. There are multiple renderers available, like Thymeleaf, Mustache, XSLT and Markdown. Though all of these are run by Java, you call it from JavaScript, so I see no reason why you couldn’t use a JavaScript library instead.
You need a small polyfill to make it work, according to the post (I haven’t tested it myself), but I don’t see any reason it wouldn’t work. You could also probably skip most of the actual Nashorn-specific code, as XP has done that for you…
What you are asking for is generally known as isomorphic code - code that can be execute on both server and client without modification. As XP runs serverside javascript it is well positioned to do this out of the box!
Mustache: We already support a template language that works on both server and client. It’s called Mustache. It is available throught “lib-mustache”. Currently this is even bundled with the XP release.
GraphQL: XP has always supported server-side rendering. Lately we have worked to facilitate development of “client side” apps using XP as the back-end. Our recommended approach for this is using GraphQL to expose your application API, and use your favourite front-end framework - from Angular and React to DIY or even native clients.
CMS projects: We are also working on a “Headless CMS” application/library that will automatically expose your content types and all other relevant data through a GraphQL API. This enables you to easily use XP as a CMS back-end with a minimal amount of coding for just about any client.
PWA: We are building starter kits for Progressive Web Apps that will facilitate the essential things you need to build progressive web apps using a DIY approach in terms of framework. We believe PWA will be the next big thing as developers move away from proprietary platforms and native code.
Framework starter kits. Finally, we are building starter kits for the most popular front-end frameworks out there so developers can quickly get started with their in a best-practice XP wrapping.
Java vs Javascript. I would also like to point out that you refer to Thymeleaf as a Java thing, but for XP Javascript developers, the fact that this library uses Java is invisible and irrelevant. XP enables execution of Java code if/when needed, and developers may encapsulate and expose Java driven functionality to Javascript developers through libraries if this serves their purpose. As such, the Thymeleaf library might just as well have been written in Javascript without making a difference to the developers using it. That is both the beauty and powerful potential of XP.
When it comes down to enabling a tighter coupling between front-end frameworks and server-side rendering the answer is that this will depend heavily on each specific framework, how it works and what can be done on server and not. Remember frameworks like Angular are much more than just templating, they are full MVC frameworks that also rely heavily on browser capabilities. The Angular Universal approach is new to me and looks interesting and most likely can be done with XP too.
Our focus is to enable developers to use their favourite tools, and simplify development and deployment of their applicaitons, sites and data. As frameworks and application development strategies and requirements change we will do our best to facilitate this as mentioned above. That said, XP is an open platform and developers are already free to build, adapt and use any framework they like today!
To be a bit more precise I’m doing some research on a node project using Angular Universal (Angular 4, but I think it has been available since version 2). This is Isomorphic web app if you like, depending on which term you like better. The goal for me would be to have a smaller technology footprint, in the same way as you don’t need to know Java for creating great web apps, we now can create services in Javascript which I think is great!
In an Enonic XP project a smaller technology footprint would be to scrap thymeleaf and do Angular server side rendering (Angular Universal), combined with Angular frontend rendering on top.
I have just scraped the surface on Angular Universal, so how this could be applied to Enonic XP is something I havn’t started thinking of yet. Also Angular 2 doesn’t seem to have that many followers yet, maybe because it’s a bit more difficult to get starting with I guess. Well the technology seems to be getting a bit more mature, and I have decided to give it a change, well to understand it better, and to check out how useful it could be on larger applications and portals - also to compare it with React isomorphic applications.
In a node/express project it’s quite easy to replace the view engine, and there are calls for saying that I would like these files to be rendered by this view engine. I believe this feature is missing or undocumented in XP still - well, I apologize for my ignorance in that case
Anyhow, I beleive many would think that to have a cms where you could decide if you would like to use xsl, thymeleaf, or all the other javascript frontend libs as backend rendering tech, even combining the same libs on backend and frontend would have a great market approval.
Us frontend developers doesn’t really like thymeleaf you know, we use it because it seems as the most easy path, given the current design of Enonic XP, it is really thread over our heads
I think you have misunderstood Enonic XP a bit if you think Thymeleaf is thread over your head. As mentioned above, there are several libraries available to choose from, and there is nothing keeping you from using another rendering library than those provided. A React or Angular library haven’t been made (yet), but I don’t see any reason you can’t use the same ones you would on a Node server, as long as you add a polyfill. Replacing the view engine is as easy as not adding the dependency to the Thymeleaf library in the first place and instead adding whatever you want to use.
Specifically, what Enonic XP assumes, is that the controller returns an object with the body and contenttype specified. How you create the body is up to you, and it just so happens that the examples use Thymeleaf. For example, most of my services return JSON, and in some cases I have not bothered using a renderer in my parts, as I did not need to make changes to the template server-side. I just loaded the file and returned its contents or even just added the html inline in the controller in some extreme cases.
In the return, render the view using you frontend-tech instead.
TL;DR
What you seem to be wanting is already supported. I recommend creating an app without Thymeleaf (just remove the dependency if it is created in the starter you use) and using whatever you want to try instead. You might have to add a polyfill as it is not running in a browser. Try googling “[the name of the framework you want to use] on Nashorn”. I get plenty of hits for both React and Angular Universal, and both seem to require a small polyfill.
As Vegard states, Thymeleaf is completely optional. Hey, you can even skip templating engines entirely just running DYI Javascript code.
To get the Angular4 running I assume essentially you need to “port” the server components running on NodeJS to XP. I have not research how much job this is, but I assume you would need to create a mapping that routes traffic to this script and then make sure it runs smoothly on XP as well! Looking forward to hear how this works out for you? Also, I see the universal approach even supports statically compiled views which you should be able to get going without running any server-side code apparently?
Personally, I think you need to have a solid use-case for applying isomorphic code rather than simply using GraphQL in combination with Angular. For most use-cases this will provide the ultimate solution for one-pager apps and front-end rendered.
Hey, Thymeleaf is really thread over our heads Vegard! It really is! We open the package and there you have it thymeleaf all over - it is stamped on every page in the documentation ok, just kidding. Point is that Enonic would have much greater marked potential if they listen to the user base, and follow development in the marked. As I said, the marked potential for Enonic would be greater in my opinion if React or Angular templates was out of the box, and not some strange not heard of thymleaf template engine (exagaration implied). Well, I for sure can live with it, but if I could choose …
Anyways, I’m sure many with me would find it difficult to apply other template engines server side when most is based on node and not Nashorn. I’m sure it might be achievable but for most projects I think it is to expensive - we don’t have time and are not payed to experiment with client money unfortunately!
If there are server side polyfills for nashhorn that seems very interesting, and is the most valuebal information for me so far. Again, I appologize for not being to deep tech wize on this, but I will try to look into it some more when time allows.
Notes taken on your comments Thomas, I agree! Way to go, but as I alluded to it may or may not be successful, might be expensive, might not have a fancy result, and might even be a total failure. Somehow us pity developers very seldom have time to experiment, well not too much.
My suggestion would be for you to put an investigation like this on your RND budget. This is a market idea to improve your product even more, free of charge! If you could add this bling to your product it will have great marked approval is my guess!
