Technology stack evolution for Reader UI

[jardakotesovec]

Hi Everyone,
please join me in this interesting exploratory topic on how to shape our technology stack (or maybe stick with our lovely Smarty templating system forever). This will be solely focused discussion on the templating+interactivity part. Leaving styling aside, as thats good topic to explore separately.

As we all know, we adopted Vue.js on editorial side to build new UI couple years ago. Its well justified there to be able to create more bespoke and interactive UI. But on reader side we still heavily rely on the Smarty templating system with some jQuery on top of it.

We are exploring opportunities to at some point work on next generation default theme, we are also looking whether that might be opportunity to modernise underlying technology stack.

Requirements

• SSR (server-side rendering) - I have been challenging this requirement for long time on various projects, because its not easy to do SSR well. There is associated cost and infrastructure challenges to actually render things fast. There is still argument that its beneficial for SEO - thats what internet keep saying. And there will be probably some truth in that. But I don't think its essential for main stream search engines.
• Approachable. Todays web applications are getting more powerful, and that comes with cost of complexity. So its actually difficult to not increase complexity when adopting some more modern technology stack. But there are for sure worse and better options
• Extensible - We will need mechanics for plugins to inject additional UI
• Interactivity - Our current reader pages are quite simple and basic, but that might also evolve with new features, like public commenting. So we ideally want something to also handle more complex interactivity in the browser.
• Accessibility - In last years lots of headless component libraries emerged. Usually framework dependent. These are handling accessibility and interactivity, but with lots of styling flexibility. Being able to rely on these without reimplementing these patterns would be preferred.

Please challenge this topic. And ask hard questions. Also provide your suggestions. In this first part I focused quite a lot on the SSR requirement. But happy to follow on the other requirements in details as well, but did not want to make it too long.

Options

Blade + ?

Blade is default Laravel templating framework. With modern and clean syntax. But its running on the server and does not help with any interactive elements. Common solutions is to use htmx or alpine.js or livewire libraries on top of it to handle the interactivity. Works great for simple use cases. But would not want to build more complex features, like public commenting. Alpine.js has also some basic headless components, but the docs are behind paywall.

Therefore we would be likely looking into mixing Blade and Vue.js. We already have mixed experience with that approach from mixing Smarty and Vue.js on editorial side. Its possible and very useful for gradual migration, but needs to be done carefully and it requires developers switching between two distinct frameworks, which have very big overlap. There is lots of decision making between what to render with Blade and what in Vuejs.

Vue.js

Vue.js can do everything - not just generate html, but also handle any complex UI interactivity. "Only" challenge is the SSR with PHP server :-).

Running Node.js process in addition to PHP is obviously concern. It needs handle some load. It needs to be properly configured. So thats for sure possible (https://inertiajs.com/server-side-rendering), but its significant operational burden.

As @jonasraoni reminded me, that even in PHP constantly keep rendering all the reader facing pages is not optimal. I realised, that maybe we could use Node.js in a way so its not that big of the operational burden and generate pretty much all the content (articles, issues, static pages) as html pages on the background. And php server can just serve html pages, where vue.js would handle both the pre-rendering but also the interactivity in browser once its loaded.

Here are some point which hopefully helps you to imagine how it would work:

• When the article is published/updated, background job would use node.js CLI to render new html page from it. These pages would be coded using Vue.js. It would require some logic what content to regenerate when.
• To get the data - it would be interacting with API. That would require to improve existing API to be useful for such use case, but thats aligned with what we would like to provide for 3rd parties anyway.
• Once its loaded in the browser and user navigates to next page. It can either just serve another html file or it can directly use API to get data and render it in the browser
• Nuxt framework was historically solving some challenges with SSR of first page and than everything else happen in the browser. Now it also have plenty of options for pre-rendering (and generating html pages), so it does not require have node.js server responding in real time. So that what we would likely leveraged.
• Without Node.js CLI on the server, it still can work, but it would just render the content client side. So it would be loosing that SSR requirement.
• Content which is dynamic (like user is logged in) would be rendered only on client side, which should not be concern as its not something to be indexed anyway.

So basically if we would be willing to accept Node.js as requirement for next generation theme and keep current themes as fallback for users which have limitations on that, we could use Vue.js across the whole OxS ecosystem, without mixing in bunch of other things.

My understanding of the hosting ecosystem is limited. So I asked chatGPT to search the node.js support across different hostings. And its conclusion after couple of minutes was:

Ultimately, deploying a PHP+Node application is becoming more common, and hosting providers are adapting. It’s still not as ubiquitous as LAMP-only hosting, but globally there’s a clear trend towards supporting Node.js due to demand.

With this overview:

Provider	Type	Node.js Support	Geographic Presence	Pros	Cons
Bluehost	Shared / VPS	✅ Yes – via cPanel Node.js App on shared (all plans). VPS/Dedicated for higher performance.	Global (US-based, serves worldwide)	Easy cPanel setup, beginner-friendly; offers one-click Node app deployment.	Shared plans have low resources (2 GB RAM limit) for Node; primarily US servers.
Namecheap	Shared	✅ Yes – Node.js on shared via “Setup Node.js App” (supports Node v6–v22).	US & EU datacenters	Very affordable; up-to-date Node versions available; good for small projects.	Performance constrained on cheap plans; no root access (must use provided Node environment).
A2 Hosting	Shared / Reseller	✅ Yes – Node.js on shared (cPanel/CloudLinux). Persistent Node apps supported via Passenger.	US (Michigan, Arizona), Europe (Amsterdam), Asia (Singapore)	Developer-centric features; allows PHP and Node together easily; global server options.	Shared Node processes subject to limits (no custom daemons); higher cost for “Turbo” plans with more resources.
InMotion	Shared / VPS	✅ Yes – on “Hosting Plus” shared plans (Node, Python enabled); also supported on VPS/Dedicated.	North America (primarily)	Business shared hosting can run Node and PHP concurrently; strong support.	Data centers mostly in US only; basic shared plan (no “Plus”) doesn’t support Node.
FastComet	Shared / Cloud	✅ Yes – Node.js on shared hosting (via cPanel); also offers managed cloud VPS with Node.	Worldwide(11 global locations)	Many regional server choices; Node, PHP, Python all supported on one account.	Shared plans suitable only for moderate traffic; may need cloud upgrade for heavy SSR.
HostGator	Shared / VPS	❌ No Node on shared or basic cloud plans. Must use VPS or dedicated for Node.js.	Global (US-focused)	Large well-known host; good for standard PHP sites.	Not SSR-friendly on shared– no Node runtime at all on shared; requires server upgrade for Node.
OVHcloud	Shared / PaaS	✅ Partial: Standard plans mostly PHP; Node.js supported via special hosting (Web PaaS) or cloud servers.	Europe, North America (multiple countries)	European privacy and performance; offers Platform.sh PaaS for easy Node+PHP deployments.	The integrated Node hosting is a premium service; standard shared hosting isn’t Node-enabled by default.
DigitalOcean	VPS (Droplet)	✅ Yes – install any version of Node.js and PHP manually (root access). One-click images available.	Global (US, Europe, Asia)	Full control of software stack; great community documentation; pay-as-you-go pricing.	Unmanaged – user responsible for setup and maintenance; requires sysadmin skills for security and updates.
AWS Lightsail/EC2	Cloud VM	✅ Yes – full OS control (can run Apache/PHP & Node). Lightsail templates for LAMP available.	Global (regions on every continent)	Highly scalable; many region choices; can split roles across instances if needed.	Management overhead is higher; costs can accumulate (no fixed price on EC2). Lightsail simpler but limited compared to EC2.
Heroku	PaaS (Cloud)	✅ Yes – supports PHP and Node via buildpacks (though not in one dyno by default). Often deployed as separate apps (Node SSR service + PHP API).	US & EU regions (for hosting)	Extremely developer-friendly deployment (git push); free tier for prototyping; no server management.	Free tier not sufficient for production SSR (sleeping dynos); costs can be high for constant processes; may require splitting backend and frontend into two apps.

Is there other compelling option I missed?

[jonasraoni]

Requirements

• SSR: I think this is still very relevant, we can't generate content just for JavaScript enabled browsers. In a not so distant future everything might be consumed by AI (there are companies already creating AI tailored content and we should follow suit, at least our documentation should be friendly to AI), but then we won't even need to worry with a reader UI.
• Approachable: IF there's a lot of side-development in OJS, I mean, people writing customizations/plugins/etc, which I'm not completely sure... Then I think we've already been making the life of such users pretty hard, with all the code instability and half-baked implementations (e.g. N ways to make something). So, in my opinion before introducing new breaking changes, we should first get rid of something ancient (e.g. jQuery?!), to keep a balance.
• Extensible: As long as we offer the user a way to add middlewares to intercept requests/responses, anything can be done (e.g. locate/replace strings or nodes, instead of being limited to adding customizations to specific places through hooks?!).
• Interactivity: As far as I can see, we don't need a lot of interactivity, the reader interface is very simple and could be almost entirely static. In my mind users just access the site, read some stuff, download articles, get citations and go away, most of the time must be spent reading instead of interacting with the UI, then the "comments" feature is mostly an exception IMHO. I don't have anything against making everything interactive and avoiding page reloads, unless our SSR approach brings a lot of extra complexity/reasoning.
• Accessibility: This comment isn't exactly about accessibility, but as you've mentioned using 3rd-party stuff... I'm all for it! Including replacing our "design system" and the ui-library by ready components. The same reasoning for adopting Laravel, even if it's not a perfect fit, the benefits are great (e.g. I didn't test now, but I guess our UI still doesn't work well with mobiles). Then we can worry more about the UX and building some lego with the basic elements.

[jonasraoni]

Is there other compelling option I missed?

The other option I see is to completely disengage the front end from the back end, which would require a GraphQL API. Then we would have PHP as a base requirement, but the front end/themes could be built in different ways. Of course we don't have enough resources to provide many cool options, but that's nice. I know https://www.ubiquitypress.com is kind of using OJS this way, our frontend is completely discarded.

[jardakotesovec]

Can you explain more why the Node.js CLI would you consider as no-go? Just noticed that also on our VMs we are using internally is node.js available. Without asking. To me it seems like such a common web build tool. Basically these days any asset (js,css,images) usually are processed with some node.js based tooling, before being statically served. So having that available on web server, even if its setup as php hosting, is not that kind of common thing to have there these days? What Am I missing?

[jardakotesovec]

Yes, ubiquity they have Next.js frontend with their custom API endpoint additions for the data fetching.

What I am proposing is very close to it, . Only difference is to deal with SSR with prerendering. But it could easily be operated in very much the same way and serving on the fly as well. Nuxt is pretty versatile on that.

I don't think we would need to go full-on graphql (given its not laravel first class citizen). Probably just couple of well designed rest API endpoints with couple of options for include query parameter for non-essential data. And than just flexibility to extend/add more endpoints should make it powerful enough.

I think that could become quite flexible and powerful platform that could be leveraged in different ways in the community.

[jonasraoni]

Can you explain more why the Node.js CLI would you consider as no-go?

A bunch of installations out there do not use Git/Composer/Node, they just download a ready package (e.g. https://pkp.sfu.ca/software/ojs/download), I mean, there are still some shared hosts which block basic features such as SSH access, limit PHP features (e.g. running shell commands) and so on, it's already complex for some people just to make simple moves like going from PHP 7 to 8 (their shared server might be used with other applications, e.g. Wordpress). From this point of view, I think this can be seen as a no-go, but that's just my guess, I'm not deciding anything 😁

It would be interesting to extend the Beacon in a way to understand such things. Who has a Node.js executable, who installed the software as a package (we can have a rough idea by watching at web log statistics), software versions, etc.

Another good place to take insights (feasibility of using a different stack) would be by getting in touch with similar open-source projects, that use different stuff:
https://github.com/CenterForOpenScience/osf.io (Python)
https://github.com/openlibhums/janeway (Python)
https://gitlab.coko.foundation/kotahi (JS)

[marcbria]

To extend the list, the folks at pubpub (MIT) are right now refactoring their platform from scratch:

• https://www.knowledgefutures.org/pubpub/ (Python)
• https://github.com/pubpub/platform

[jonasraoni]

Hmm, I should have separated my comment in pieces to avoid cluttering the UI haha

Only difference is to deal with SSR with prerendering. But it could easily be operated in very much the same way and serving on the fly as well

I understand, I don't have anything against it, it's just needed to ensure the community is ready for it. I've created a document with a bunch of ideas in ~2020 and this was one of the ideas:

Replace Smarty by Vue everywhere: the flexibility of delegating the data gathering to the client (Vue) through APIs is interesting... A pain point is that server side rendering Vue components with PHP is risky/limited (V8 extension for PHP, spinning up a Node instance, emulation), which isn’t great for SEO... So, how well are search engines at handling dynamic content these days, given that we also could feed JSON-LD/metadata content while the client is “building” the interface?

I don't have anything more to comment, I'll wait for comments from others 😁

[mpbraendle]

Just to remind that node.js is single-threaded and therefore the main bottleneck for SSR (see also, https://inertiajs.com/server-side-rendering , chapter Clustering - I'm not sure if that would be a virtual clustering or a clustering based on the available CPU cores). SSR is a topic which also bytes DSpace repository installations which have to face huge traffic from AI bots. Usually, you would need a multicore cpu and a process manager such as PM2 to run several node.js processes. Not all existing installations would have such a setup and you would limit upgradability to institutions that can afford such an environment.

With regards to custom themes. Maintaining custom themes (even if derived from the Default theme) between upgrades is a major task for institutions that host multiple journals having their own branding. Separation of content rendering (templates) and representation (Less, CSS) should stay as is - but of course the two are connected via the general layout of a page and through its CSS classes. So, if you replace the template engine (and the templates), don't break the current layout (structure of HTML) and CSS classes! Introduce changes only slowly and iteratively, i.e. when changing the major version.

My general recommendation would be that you carry out a survey among PKP users on the following topics

• what they currently use as hosting environment
• what environment they could afford for such a change
• which themes they are using and how much customization is involved

This would give you a better picture for planning such changes. For me it is essentially about not leaving a majority of installations behind.

[jardakotesovec]

Thanks for the feedback. Because of the operational challenges you are mentioning, I was proposing preprendering as solution for SSR, where just plain html is served. All these operational challenges are significantly reduced by this approach, don't you think?

Challenge that remains is to have reliable way to re-render these html files in the right moment (article published, metadata updated etc). But thats kind of logic that needs to be think about when dealing with any caching strategy also - to basically have clear information when something changed and need to be refreshed.

Regarding html structure/styling and impact of that. I think this will be much more dictated by how much the next generation theme will be different to current one. Basic idea behind this discussion is that if we would be introducing next generation theme, we might use it as opportunity to update underlying tech stack, because just the new theme itself is likely to be big breaking change. Just replacing underlying stack for existing themes would be big disruption with hard to justify benefits IMO.

[marcbria]

Jarda, I am glad that you have raised a debate with such deep implications because you made me think that everything is possible... and at the same time, listening to you, my legs are shaking :-P

First thoughts in telegram style until I have time to sort out ideas:

• Introduce node.js on the server side? I don't see it, because of the arguments that Jonas and Martin have argued, because it will have a huge impact in our community... but I think it's a good idea to launch a poll to see what the community responds to see what needs we have.
• Get rid of smarty? I'm in (a while ago:-P). I don't have a preference but as Jonas says, Blade seems the most natural choice in Laravel.
• UI/UX needs? As was said, the needs we have in the public frontend are nothing to write home about, so it seems like a very big effort for a very small benefit.
• Decoupling OJS? I think it would be a good idea, not so much because of the widespread use but because of the door it opens to organizations with more resources (ie: ubiquiti).
• Is now the time to introduce major changes? I think that right now there are too many fronts to tackle something so big and I think that the objective should be to consolidate rather than expand... but maybe I have become too conservative.

In short: I see many possible projects (JATS-centric-workflow, telemetry, API, SEO, translation management, caching, issues with reverse-proxies,...) that I think are more necessary for our community than changing our stack to improve the UI/UX. I'm also afraid of the implications of changing our stack (in terms o IT teams), so my suggestion would consolidate our upgrade tooling first, expand with community requested features, and then refactor if we still think is required.

[jardakotesovec]

Hi Marc,
just let me preface it with saying, that this exploratory discussion is driven by the increased pressure for more modern / redesigned default theme. Which on its own is likely to require significant effort for anyone who would be migrating from any other customised theme. Regardless if we do any changes on the tech stack side. So its not coming from place of lack of other work, but it seems to me reasonable to consider any potential technical stack updates with introducing new default theme. Rather than frustrate people with these two things happen independently. Imagine like we build new theme in Smarty, and two years later we will annoy people with migrating it to blade or vue.

I would hope at least for little bit of enthusiasm about idea of prerendering the article/issue pages, and serving them as html files. This actually make the server requirements to go down. And you don't have to deal with any additional caching layers in your setup. Also ideal for SEO.

I am little bit confused about, that changing from Smarty to Blade is considered as obvious thing to do, while using vue.js triggers panic mode.

I would think that biggest cost and difficulty is to migrate any customisations to the new theme. But that burden will be mostly caused by the introducing new theme itself. And that work needs to happen regardless if we stick with smarty or we code it in blade/vue (can be argued that sticking with smarty would be easiest, but blade/vue are about the same).

And than the second part is whether the hosting requirements would change. Which of course is also important, but I would think its smaller deal. Even if you are on the hosting that does not let you use node.js CLI, you can still stick with existing themes for long time (until the Age of Ultron). Or don't use pre-rendering with new theme. But if you tweak your hosting with node.js - your bills actually can go down when serving mostly just html files (and other static files).

I am well aware of what it takes running big cluster of Node.js server side rendering nodes, I have seen it first hand. Thats also why I am proposing pre-rendering approach. Which is key point in the whole proposal and seems to be overlooked in the responses to the degree I wonder how carefully it was read through.

[marcbria]

I think Alec's answers most of your questions in his post below, but please let me know if something is not clear.

In any case, let me make it clear that I do not question the technical feasibility of the proposal or even its suitability, but at the same time, I cannot stop thinking about our park and the profile of our people who manage it... there are still people licking their wounds from the transition from 2.x to 3.x and that makes me very cautious when considering major changes.

As long as the transition is gradual, we will maintain our position as the de facto standard.
If there is an abrupt change, I am not so sure.

[asmecher]

Thanks, all, for the excellent commentary. I do think we'll find server-side NodeJS to be too scarce and problematic for our community at large, though I don't have solid facts to back up that superstition. (I do have a few commodity accounts on a2hosting, for what it's worth, and they don't include NodeJS.) @jardakotesovec, if you're convinced that this is the best technical approach, we could consider a survey or something more reliable than my suspicion.

I think the hard parts of server-side rendering are mostly related to performance, and I don't find that a compelling technological driver for us. Most OJS/OMP/OPS users are not performance sensitive because they run relatively small collections, and for those who are, basic optimization work (as we're doing with submission lists in 3.5) will still give us the best bang for our buck before we start getting exotic. Even then, we can practice good citizenship with headers and HEAD responses and rely on a Squid cache or similar for an easy lift in performance with low technical complexity. This would allow us to continue to maintain and run OJS/OMP/OPS as simple applications, but allow for users with higher requirements to satisfy them without needing some kind of parallel implementation.

Replacing Smarty motivates me. Smarty is an increasing tech risk, and never had fantastic community uptake. Almost nobody working with OJS theming has ever had to use Smarty before or ever will again. Moving to Blade further unifies us within the Laravel ecosystem, which we've invested heavily into adopting. I suppose Laravel use doesn't preclude us using SSR tools -- e.g. Spatie's SSR library, which has a Laravel bridge -- but that feels exotic and a big dependency risk.

As the Spatie SSR project says well,

As a final disclaimer, judging by the amount—well, lack—of people blogging about rendering JavaScript applications in PHP, this whole setup is uncharted territory. There may be more unknown caveats lurking around the corner.

We're PHP and increasingly Laravel, for better or for worse, and I'm not convinced we have a compelling need to break the front end out of that mold.

ETA: Linking #11336 to this discussion, as it's relevant particularly to the caching headers / squid part of the above.

[marcbria]

I have a feeling that custom themes from 3.0 and 3.1 (released 2019 or so) could be moved to 3.2 and 3.3 with no or minimal changes.
I understand that for default based themes, the 3.5 change will also be quite peaceful.

If we are talking about adding blade in 3.6 and 3.7... with the 3-5 years of the next LTS-3.5, the current stack will have been there for more than 10 years... so I don't think it's an abuse (and I think it's even advisable) to ask people to spend some time to redo their themes.

Even if it is accompanied by new frontend components, some documentation and webinars, can be a good way to dynamize the community, letting them spread their graphical image.

[nils-stefan-weiher]

Wouldn't the same approach that was used in the backend with Smarty and Vue.js work also with Blade and Vue.js?
The initial state is rendered in the HTML using the template manager. The template engine shouldn't interfere with that.

Why introduce one more technology only for the reader facing frontend? Also any plugin that is sophisticated will also probably introduce their one JS stack. We definitely do this for our OJS/OMP plugins in the frontend, because we have JS libraries/modules that are shared between many websites.

[jardakotesovec]

@nils-stefan-weiher I agree, in my original post (Blade + ? section) thats what I concluded - if we go with Blade - that we would endup mixing it with Vue.js. There are some drawbacks of that approach as well, but from the available options it makes most sense.

The other option I was exploring was using just Vue.js.

[jardakotesovec]

Note, that on editorial side where are just gradually phasing out smarty. We don't intend to introduce Blade there. There is no point.

[asmecher]

Not a compelling way to tip the discussion one way or the other, but converting existing themes from Smarty over to Blade might be one of those cases that's a good application of AI. I'm pretty sure that if we were starting a Laravel application from scratch, I'd recommend that we choose Blade for theming; if that's broadly acceptable, and the impediment is getting us over the fence from our current toolset, it's not an impossible task.

[withanage]

Why introduce one more technology only for the reader facing frontend?

Totally agree with this question from @nils-stefan-weiher . In addition to maintainable burden, double SSR, SEO issues, complexity for community plugin and theme developers, this adds also the problem of refreshing the content.

There may be arguments, that pre-rendering can be archived, but for that, I think that can be a institutional choice and the Server-Side generated sites can be still archived easily using simple technologies.

May be I missed that, is there any requirement list publicly available, where the necessity for vuejs for reader ui. I have not seen so much requirements for interactivity in reader. Therfore , I would prefer a Balde+PHP and tailwind css based solution a lot better than having VuesJS and all other related vueJS libraries like piniastore.