How should I render templates (Handlebars)


#1

Hi all, first post here. I’m new to Electron, but have been using Atom for a while now. I got out of the web development game about 12 years ago now and am mainly a low-level systems programmer…but I need an interface for an application I’m writing and I like the concept of using HTML/Javascript/CSS/etc. for interfaces. Clearly a lot has changed since I last did any serious web-like development.

Anyways, I’m interested in using Handlebars to render parts of my interface, such as dynamically populated repeated page elements and text that is run through i18n. From what I gather, this could be done in the main process using Data URI and passing it to loadURL, or it could be done in the Renderer process. Is there any general consensus at to which way is preferred? Or am I missing the point of Electron entirely and don’t need a template engine at all?


#2

The browser process should be used to access the filesystem, to do background processing, to do the windows management, etc.
The renderer process… is where the rendering happens.
So, although you can theoretically pre-render the page in the browser process and pass the html to the renderer process to display, it doesn’t really make sense.
Also, the communication between browser and renderer processes is not super fast and should be used sparingly.


#3

Thanks, that helps and confirms what I had suspected.


#4

Hey guys,

Just wanted to add my 2 cents. I’ve been thinking about this thread a lot for the past few days, and I don’t agree that the renderer process is where all rendering should happen.

Let’s say you have a class you add to the body if the user toggles some setting. You animate the properties that the class changes when the user toggles the setting, but you don’t want it to animate those properties the next time the user opens the app (being that they didn’t do anything… they just opened the app). You could do a bunch of class switching that turns off transitions. But you’d still see some FOUC.

The same goes for form elements that get filled in with the user’s previous selections (checkboxes, dropdowns, etc.). If you render everything on the renderer process, the user will always see the page initially with their settings unset while the javascript renders everything. It’s a bad experience. So I don’t think “all rendering should happen on the renderer process” is really the end-all-be-all answer here.

Just wanted to add an apposing view point. :slight_smile:


#5

I’m using handlebars and i18n in the renderer process. So far it seems to work OK. I posted source code for a minimal example in this forum a weekend ago, “Internationalization setup - i18n”.

I have also tried to do this from the main process with loading a data uri. There seems to be some problems with this approach, however. I couldn’t get linked css and javascript files to work properly.


#6

We do a lot of prerendering of renderers and use show hide of BrowserWindows to make app snappy. At the same time we are using electron-view-renderer package to utilize render side template rendering. It has ejs as the template renderer right now but allows you to extend it with any renderer you want.

The package is still in its infancy (I just added it to npm) and is primarily being used on a fairly small sized app. Meaning I am not quite sure what the performance is like on a large, process intensive application, but works on a small to medium sized application so far.

The package is called electron-view-renderer https://www.npmjs.com/package/electron-view-renderer

Hopefully this can help someone like it did our team. It is in its infancy, so all comments and contributions welcome