4 ms·

Is it possible to support functionality where I can have my components and pages written in javascript but be rendered as server-side only? I like client-side

Is it possible to support functionality where I can have my components and pages written in javascript but be rendered as server-side only? I like client-side rendering for certain things; however, I don't really want it for every component/view within a javascript framework. What I want is the flexibility to write declarative components with localized state but only introduce client side rendering when I want to introduce it. I feel like the universal approach can be a bit heavy handed in that everything is getting rendered both on the server and the client. I would love to have something like Angular 1.* but with more structure and server side rendering.

tropshop 8y ago
You might be interested in https://markojs.com https://markojs.com I used it a few years ago and one of my favorite aspects was using primarily for generating templates server side, and only upgrading to a client component when things became more complex. Out-of-order async rendering was pretty nifty too.
- rajangdavis 8y ago
  This is very promising! Thanks for the share!
- gitgud 8y ago
  Wow that looks cool, their benchmark's blow react and vuejs out of the water too!
rich_harris 8y ago
One of the advantages of the Svelte approach is that you can theoretically make those determinations at compile time - if there's no interactivity on a page, don't serve any JavaScript. We're not quite there yet but it's very much on our radar. You should be able to use a consistent programming model whether you're building an app that makes most sense as a purely server-rendered app, an SPA, or something in between - especially since your requirements can change unexpectedly - and if the framework is designed correctly, it shouldn't even require configuration.
- rajangdavis 8y ago
  I was definitely looking at Svelte, Vue, and React for this. I played around with Nuxt and couldn't get it to work in a way where I could avoid rendering on the client. It's not a bad framework, but it doesn't work for the purposes that I am looking for. What I am doing today is using Ruby and Sinatra for the back end. I have figured out a way to build out a light weight component system where this is an html view, some vanilla js for interactivity, and CSS for styling. The problem is that it is really difficult to localize the scope of the js and I have to work with the DOM to add interactivity. Scoping the CSS isn't necessary but would be nice. I don't dislike doing things in Ruby, but I am very much attracted to the idea that I can use one language for the server and client logic and avoid having to tap into the DOM for managing state.
seangates 8y ago
+1 for Marko. Suits my needs very well.

tropshop 8y ago

You might be interested in https://markojs.com https://markojs.com I used it a few years ago and one of my favorite aspects was using primarily for generating templates server side, and only upgrading to a client component when things became more complex. Out-of-order async rendering was pretty nifty too.

rajangdavis 8y ago
This is very promising! Thanks for the share!
gitgud 8y ago
Wow that looks cool, their benchmark's blow react and vuejs out of the water too!

rich_harris 8y ago

One of the advantages of the Svelte approach is that you can theoretically make those determinations at compile time - if there's no interactivity on a page, don't serve any JavaScript. We're not quite there yet but it's very much on our radar. You should be able to use a consistent programming model whether you're building an app that makes most sense as a purely server-rendered app, an SPA, or something in between - especially since your requirements can change unexpectedly - and if the framework is designed correctly, it shouldn't even require configuration.

rajangdavis 8y ago
I was definitely looking at Svelte, Vue, and React for this. I played around with Nuxt and couldn't get it to work in a way where I could avoid rendering on the client. It's not a bad framework, but it doesn't work for the purposes that I am looking for. What I am doing today is using Ruby and Sinatra for the back end. I have figured out a way to build out a light weight component system where this is an html view, some vanilla js for interactivity, and CSS for styling. The problem is that it is really difficult to localize the scope of the js and I have to work with the DOM to add interactivity. Scoping the CSS isn't necessary but would be nice. I don't dislike doing things in Ruby, but I am very much attracted to the idea that I can use one language for the server and client logic and avoid having to tap into the DOM for managing state.

seangates 8y ago

+1 for Marko. Suits my needs very well.