11–20 of 123 posts
A great thing about the web is that a multitude of server side languages can be used. While I don't ever want to have to write the same template twice, having everything converge on nothing but Javascript doesn't seem like a very inspiring future to me.
You keep using that word. I do not think it means what you think it means. Using precisely defined mathematical words in contexts where they only make sense vaguely to a layperson ruins their original usage. Make up a new word. Repurpose a shitty English word. But leave our damn maths words alone. Old man quarterto shakes his fist at you! Get off my smooth, compact lawn!
You keep using that word. I do not think it means what you think it means. Using precisely defined mathematical words in contexts where they only make sense vaguely to a layperson ruins their original usage. Make up a new word. Repurpose a shitty English word. But leave our damn maths words alone. Old man quarterto shakes his fist at you! Get off my smooth, compact lawn!
My main concern - how does application state get handed off to the client-side code after the initial render? Sure, it's nice to have some pre-rendered templates, but at some point it needs to "transition" cleanly to the client.
However, Yahoo already released a solution for shared Express/client state: https://github.com/yahoo/express-state
You keep using that word. I do not think it means what you think it means. Using precisely defined mathematical words in contexts where they only make sense vaguely to a layperson ruins their original usage. Make up a new word. Repurpose a shitty English word. But leave our damn maths words alone. Old man quarterto shakes his fist at you! Get off my smooth, compact lawn!
In my experience, including rendering code both server-side and client-side is overkill. Just put all the rendering and templating code client-side, period.
If you want your page to appear more quickly, then instead of loading content data with AJAX afterwards, just include JSON arrays of content directly within the HTML source itself, and use JavaScript to populate the page instantly, even as it loads.
(Obviously SEO is a different case, but there are tools built for that specifically.)
It seems like CoffeeScript did this rather successfully, and with source maps, the debugging story is getting better too. Any reasons why this might not be a more compelling future than the "JS everywhere" vision?
You keep using that word. I do not think it means what you think it means. Using precisely defined mathematical words in contexts where they only make sense vaguely to a layperson ruins their original usage. Make up a new word. Repurpose a shitty English word. But leave our damn maths words alone. Old man quarterto shakes his fist at you! Get off my smooth, compact lawn!
According to M-W "isomorphic" has pre-existing definitions from medicine and chemistry that could align better with what OP is trying to say. http://www.merriam-webster.com/dictionary/isomorphic
Good day quarterto! I shall now leave to take a smooth ride in my compact car.
My main concern - how does application state get handed off to the client-side code after the initial render? Sure, it's nice to have some pre-rendered templates, but at some point it needs to "transition" cleanly to the client.
I just started hacking on Rendr last night, so I don't know if it shares state between Express on the server and the client-side app. My guess would be that Rendr does not have this built in as it's stated design goal is to stay small/modular. However, Yahoo already released a solution for shared Express/client state: https://github.com/yahoo/express-state