I mean that if you want to build a UI in the manner described in the article—where you essentially use a JS UI framework to render the application server-side, and subsequently make it interactive on the client side—then doing so without the server being Javascript is more complex.
I have direct experience of doing this – I built a complex web application that used this approach from within Rails. Essentially this replaced Rails built-in template renderer with a JS environment running in V8. It was pretty cool, in that it meant writing templates once and having them server-side rendered but also interactive on the client side – but it added a huge amount of complexity.
Is there something I was babbling about that I missed?
why? What does the server being javascript do for you that no other server can do to reduce the complexity?
The options if you are not using javascript on the server are less appealing - calling out to a JS interpreter to do your templating, or building duplicate templates for server and client side, or trying to sprinkle interactive client magic on the page after it’s been loaded.
They’re all possible, but they are more complex than “one set of templates rendered everywhere” - what people were calling “isomorphic” I suppose, though it’s a silly term.
Have I clarified? You seem unusually upset about what I thought was a relatively minor aspect of my initial post.
Your initial post sounded like nonsense to me - like you were arbitrarily elevating javascript for no particular reason. But now that you've explained that you're talking in context SSR I understand. Maybe that was inferred and I just missed it - even if thats what this whole HN thread is about. I know I was thinking in terms of JSON responses and couldn't understand why one would be so much better than the other.
So, you're right. you do have to do additional work, when JS isn't your server, when your pages are rendered with JS and you want to pre-render pages.
But I wonder - is it worth it to move your entire backend into JS just to do that for SSR? Would not calling out to a JS interpreter be the more... SOA approach, or even the more pragmatic one? Or is it exponentially more difficult to do that than to move everything into node/JS?
But there's a middle ground in practice. Public-facing website that users might hit from a search engine? Obviously render it on the server, and if required progressively enhance it. Something more akin to a web application? Server-side rendering makes everything slower and more complex without benefiting any users. If you aren't using Node on the server, it's even more complex.
I really hate that this is the case. I had this firm idea in my head – "every URL is an HTML page, and users should be able to take that URL and request it using Curl or whatever, and see the content of the page". In practice, we were developing a highly-interactive, domain-specific application that relied heavily on client-side scripting to be realistically useful for users. There were no users without JS that I was able to find. We were doing a huge amount of work to follow a rule of progressive enhancement, that in practice slowed down the experience for users and, benefited nobody, and made development ~ an order of magnitude harder.