Question on server rendering

[Scott Ellis]

I'm in a situation where I have developed some reporting widgets using jquery and requirejs, and everything looks great on a desktop browser, but our intended platform is ios, and in that environment the application is considerably slower. The problem is the time spent during initialization, churning through Dom elements and dynamic creation of content. I see that zest offers server-side rendering, and that could really be a nice answer to the problem, completely offloading rendering from the device that has a fraction of the processing speed.

However, part of the initialization process involves measurement of text strings within sections of the document taking account all of the applied styles. I need to know if the zest server component is capable of this level of sophistication.

Thanks,

Scott

[Guy Bedford]

Hi Scott,

Could you clarify what you mean by:

part of the initialization process involves measurement of text strings within sections of the document taking account all of the applied styles

In terms of performance for your app, the first thing to do is to ensure you are rendering directly from HTML strings and touching the DOM as little as possible in the process. Ideally the entire app can use a single or just a handful of el.innerHTML = ... calls.

Guy

 

--
You received this message because you are subscribed to the Google Groups "zestjs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zestjs+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Scott Ellis]

Guy,

What I'm doing is creating a responsive data grid that contains a lot of data—and by a lot, I mean there are a great many (around 10K) dom nodes.  I have no control over that, and paging these data grids id not an option as per the big boss man.  In order to exert some control over the grid, I am collecting metrics on the text width of the largest text string in each column  by temporarily wrapping it with a span and taking the position information from that and storing it away, then removing the span.  The reason for this is that I cannot rely on the td width to give me this information (text is not necessarily flush with the border), and sometimes I have a headers that span multiple columns and I need for the header text to be centered between the leftmost text position of the left column and the rightmost text position of the right column.  I will create a jsfiddle if you would like since none of that probably made any sense…

The bottom line is however, that using chrome and using my responsive table widget, I'm able to see the data grid in a fairly short amount of time.  There are optimizations I could make, but on the iPad Mini, the intended end-client for this particular grid, shocked me by being so slow to render this.  I learned the hard way that it's Safari browser, as with all iOS devices, is not optimized for javascript.  So, when I read about zestjs and its ability to render on the server, I became hopeful that I could put this process of rendering on the server where it would hopefully be faster and simply serve the iOS device with a static page with minimal interaction with javascript.  

Thanks,

Scott

[Guy Bedford]

Scott,

Unfortunately this doesn't sound like the best use case for ZestJS. ZestJS uses server rendering to share template code when pages can be rendered either dynamically or on first load (consider a popup as the canonical example of this, but it applies to any app). The benefit is that you can write that dynamic popup once, and then have it work for server and client rendering. The primary benefit here being SEO (otherwise you can always render client side).

In terms of your problem, the best I can think of would be looking into setting up PhantomJS on your server. You could then run your widget and get the measurements on the server, and associate those readings with your initial data. Then when loading on the client, you wouldn't need to make these measurements as they would have been made already on the server.

All the best,

Guy

[Scott Ellis]

Guy,

Thanks for your attention to my issue.  I'll take a look and see if PhantomJS is indeed a potential solution for me.  You saved me a lot of time, which is in short supply right now.