WP Tavern › Forums › Create Topic
Peter Knight having to call back to the server to re-render is a worse UX than native JS rendering This is harmfully untrue. It is obviously true that interactions that don’t require server side interactions can be much quicker without having to interact with the server. But the notion that users will get a better UX if all the elements on the page rely on clientside render logic is laughable. Imagine if all shortcodes were converted to blocks, most authors are going to follow conventions, meaning that they are now going to double their work (and double their errors) creating javascript and php based render logic. Then this clientside logic will be loaded eagerly on every load of the editor, slowing it down and multiplying the likelihood of slow and bug ridden performance. Because the editor actually spectacularly fails at faithfully presenting the page as it would look on the front-end, you actually create even more potential problems. You can get styling issues, inconsistencies, script conflicts and inaccurate/broken content. The performance gains of clientsiding it all conjures a false mirage. If your shortcode relies on queries and/or filters, it is likely that you will be creating additional requests to the server regardless. The marginal benefits of speeding up rerendering with smaller payloads is offset by the amount of additional clientside logic that is being shuffled down preemptively on every load of the editor. Then you consider shortcode usage in context with what people spend their most time on in the editor: writing and editing words. Once a shortcode is in place and configured, you don’t need redundant components to be loading and slowing down the page. It is an extraordinary waste. I do hope shortcode authors are especially careful in how they go about this. Blindly following the dictum that clientside UI and render logic makes for better UX is fool’s gold. This is a case by case kind of thing and it even when it makes sense, its likely that plugin authors will underappreciate the potential net negative of having dozens of different shortcode authors presenting their new block logic on every page load of the editor.
Peter Knight
having to call back to the server to re-render is a worse UX than native JS rendering
This is harmfully untrue. It is obviously true that interactions that don’t require server side interactions can be much quicker without having to interact with the server. But the notion that users will get a better UX if all the elements on the page rely on clientside render logic is laughable.
Imagine if all shortcodes were converted to blocks, most authors are going to follow conventions, meaning that they are now going to double their work (and double their errors) creating javascript and php based render logic. Then this clientside logic will be loaded eagerly on every load of the editor, slowing it down and multiplying the likelihood of slow and bug ridden performance.
Because the editor actually spectacularly fails at faithfully presenting the page as it would look on the front-end, you actually create even more potential problems. You can get styling issues, inconsistencies, script conflicts and inaccurate/broken content.
The performance gains of clientsiding it all conjures a false mirage. If your shortcode relies on queries and/or filters, it is likely that you will be creating additional requests to the server regardless. The marginal benefits of speeding up rerendering with smaller payloads is offset by the amount of additional clientside logic that is being shuffled down preemptively on every load of the editor. Then you consider shortcode usage in context with what people spend their most time on in the editor: writing and editing words. Once a shortcode is in place and configured, you don’t need redundant components to be loading and slowing down the page. It is an extraordinary waste.
I do hope shortcode authors are especially careful in how they go about this. Blindly following the dictum that clientside UI and render logic makes for better UX is fool’s gold. This is a case by case kind of thing and it even when it makes sense, its likely that plugin authors will underappreciate the potential net negative of having dozens of different shortcode authors presenting their new block logic on every page load of the editor.
Name *
Email *
Website:
Topic Title (Maximum Length: 80):
Forum: — No forum —AI and WordPress Articles Blocks Showcase Discussions Events Introductions Jobs and Working in WordPress Podcast Episodes Site and Block Editor
Enter your email address to subscribe to this blog and receive notifications of new posts by email.
Email Address
Submit
Enter the destination URL
Or link to existing content
