Front-End or Back-End? EJS Does Both in Viking CMS

We decided early on to use EJS as a rending engine; it is incredibly fast. It can be used on the front-end, and it is tiny. It is a REGEX-based engine. Developers can use EJS in their designs directly, if they learn how, but they don't need to because we prefer to build them for you. You really won't need very many, maybe a dozen or two at most. Once they are built, you can use them to display any of our data feeds. They organize the content visually, outputting HTML with it's related CSS.

The other cool thing, is that your designers can be copy/pasting EJS views into their "pages" in any way they want. They are free to change them, write their own CSS around them. They can also change the data feed they point at, perhaps change the category of stories they refer to, etc. There may be various attributes they can add or change: "title", "lazy-load", "startingIndex", "portrait", "landscape", are common. The point is we design the views for you, instead of just demanding that you use those from a common list that we have already built. Here is an example of what an <%-include %> of an EJS template looks like on our current home page, for example:

It's simple. Have I mentioned how much I like simplicity? Just plain text, that's all. No fancy WYWYG editor, no complicated boxes within boxes within boxes, nothing important to adjust or fiddle with, just the thing, with no more extra attributes than are required for the purpose it was built for! If you are in the market for a CMS, and you have staff designers, please show them this article. I think they will instantly see how much simpler this makes their page-design! They like writing HTML, and we prefer to work with them not against them.

I'll also add that our page designer is literally built to easily accept AI-generated HTML. The image above, of the <%-include%> statement can easily be copy/pasted into any AI generated HTML as well.

The important thing about our choice of EJS as a rendering engine, is that it is used both on the back-end (on the server) and on the front-end (on the client). Most of the time the content is just sent directly from the server, but in many cases where there is a need for user interaction, the view is sent along with the content so it can be re-rendered in response to user interaction. One good example would be elections. The user may want to be able to search, order, or re-classify races on their end. We can easily add those sorts of features as needed, and we have found the EJS is a really simple and reliable way to pass the view back and forth expeditiously. Forecasts are another good example, this is high quality SEO data (fresh and authoritative) but of course varies from place to place. Many features may require some knowledge of the user's locations, so we built that in. We natively save the users zip code if they offer it at any point, in order to be able to target content for that location, especially forecasts!

The possibilities are endless what you can do when you have a dedicated developer who wants to work with you to show your content in the most interesting and engaging way, and we like the flexibility to be able to render that content on the front-end, back-end, or both, depending on the exact application. That's the best way to reduce software overhead!