The most over-engineered blog that I know of is Casey Muratori's at <a href="http://mollyrocket.com/casey/" rel="nofollow">http://mollyrocket.com/casey/</a> . "View source" and you'll see a long list of auto-generated variables and function calls, unlike anything else you've probably seen for any website.<p>Casey attempts to explain what he did in a podcast[1]. Apparently, he was frustrated enough with CSS's margins that he built a layout engine in C that calculates offsets for every piece of text in the page, then generates hundreds of lines of Javascript that apply fixed positioning to arrange the text.<p>[1] transcript: <a href="http://mollyrocket.com/jacs/jacs_0004_0010.html" rel="nofollow">http://mollyrocket.com/jacs/jacs_0004_0010.html</a>
It might be worth turning your GitHub links in the article into permalinks (hit 'y' in the GH interface once you've targeted the file and line) so they don't fall out of date.<p>Nice work!
Great stuff!<p>You're correct about it being sort of awkward at first when you are figuring out how to structure an isomorphic applications. It gets even weirder when you only use JavaScript as a compilation target.<p>I created an example isomorphic Clojure and ClojureScript application (<a href="https://github.com/domkm/omelette" rel="nofollow">https://github.com/domkm/omelette</a>) and wrote about how it works (<a href="http://domkm.com/posts/2014-06-15-isomorphic-clojure-1/" rel="nofollow">http://domkm.com/posts/2014-06-15-isomorphic-clojure-1/</a>). It was an interesting experience. I wouldn't recommend it for production quite yet but I'm looking forward (and working toward) the day when we can easily deploy isomorphic applications that are not written in JavaScript.
I'm also experimenting with isomorphic React apps. I'll be presenting some of my work at React Conf at the end of the month (so this isn't yet as well documented as it should be), but here's what I'm trying to handle async data with ReactRouter:<p>- Have the data your view depends on expressed as a named parameter in routes.jsx: <a href="https://github.com/appsforartists/ambidex-example--bike-index/blob/master/application/routes.jsx" rel="nofollow">https://github.com/appsforartists/ambidex-example--bike-inde...</a><p>- Use those named parameters to resolve which stores need to be populated before rendering: <a href="https://github.com/appsforartists/ambidex-example--bike-index/blob/master/application/bike-index/reflux/actionsForRouterState.js" rel="nofollow">https://github.com/appsforartists/ambidex-example--bike-inde...</a><p>- Don't render the page on the server until those routes are populated: <a href="https://github.com/appsforartists/Ambidex/blob/master/src/callActionsForRouterState.js" rel="nofollow">https://github.com/appsforartists/Ambidex/blob/master/src/ca...</a><p>In that example, the editBike view depends on bikeID. actionsForRouterState makes sure that the viewBike action is called to populate the CurrentBike store before any route that includes bikeID is rendered.
More over-engineered than <a href="http://ponyfoo.com" rel="nofollow">http://ponyfoo.com</a>?<p><a href="https://github.com/ponyfoo/ponyfoo" rel="nofollow">https://github.com/ponyfoo/ponyfoo</a> has over 2k commits
Would this make it possible to have the whole page in <noscript> tags to make it crawlable by all bots and browsable in Links, Lynx, Dillo, w3m and offByOne?
I've been doing something similar using Backbone and Ezel[1] (I first started using Rendr[2], but couldn't get into it): As the OP says, it can be a bit confusing to get your mind around. Particularly the routing; part of my intention was to use the "isomorphic" technique -- btw, as a mathematician, I <i>really</i> hate that this term is used...but I digress -- to create a SPA that falls back to a traditional multipage site if/when JavaScript is disabled. It was a bit of a hurdle, but ultimately proved possible.<p>I might give React a closer look, having read this.<p>[1] <a href="http://ezeljs.com/" rel="nofollow">http://ezeljs.com/</a><p>[2] <a href="https://github.com/rendrjs/rendr" rel="nofollow">https://github.com/rendrjs/rendr</a>
I'm also experimenting with "isomorphic" apps. I wrote a router with an expressjs/hapijs like API (middlewares included). The main point is handling the state <i>before</i> choosing the view. The concept is general enough to avoid being tied to React although React makes things easier. Once you have such a router, handling nested views (a la react-router) is a trivial particular case.<p>Here's my lab <a href="https://github.com/gcanti/tom" rel="nofollow">https://github.com/gcanti/tom</a>
Nice writeup. I can definitely see "isomorphic" or client/server frameworks (React and Ember especially) being the go-to choice for new sites.<p>I guess an exception would be richer "experiential" type of apps and toys, where some DOM might be replaced with Canvas/WebGL, and transitions/animations/etc take precedence over SEO and initial load time. I haven't seen much innovation in terms of MVCs or frameworks that target these types of sites.
Great job! Also love the write up you gave and that you shared the code. I tried doing something similar a while back but never got around to finishing it, so I'll definitely dig through this source for some inspiration. I'm very curious how you'll develop the integration between webpack and gulp (or whatever you plan on using) as I tried doing something similar with Grunt but eventually gave up. Having only one build step would be awesome.
Yes, yes, yes. At my company we've been switching everything over to React for both client/server rendering using our own ExecJS rendering engine for Ruby on Rails. It certainly adds a bunch of complexity to the stack, but every improvement we make provides new benefits in terms of the ease with which we can keep the API stack we like while cranking out rich UI while worrying much less about the client/server distinction.<p>Needless to say, I am a React fan.<p>That said, here are some things you will run into as you build more complex applications with this architecture. Some are related to shared browser/server JavaScript and some are React in general:<p>* You will find that some JavaScript libraries you want to use should not be loaded into the server context.<p>* On occasion, you will need to add server-vs-browser conditionals. And creating components to deal with browser-focused JS libraries (think Google Maps) will require some liberal and sometimes awkward use of React component lifecycle methods.<p>* Until there's a nice, agreed-upon open-source layering library for React out there, or you make your own, things like click-based (not hover-based, which can work with just CSS) dropdowns and non-modal dialogs are weirder to get to dismiss (when clicking outside of them) than they should be. Just because of the way React events happen and are bound.<p>* Also because of the way events are bound, it's awkward to write nice reusable form components. Without some trickery, you can only bind events from the component you're writing to its descendents. You can't bind events from one descendent to another. You end up writing a new component for each form every time, which isn't necessarily terrible until you want to make a fancy form builder like Rails provides in ERB. I've tried every which way around this, and I've had some success, but the solution always feels wrong and ugly no matter how I do it.<p>* This is really more of a good thing, but it's so enabling that you'll never really be done adding convenience features. There are just so many "Wouldn't it be nice if ____ just worked?" scenarios that get you thinking about the next reusable tool you want. I spend a LOT of time trying to create the "perfect" browser-side data store abstraction and the "perfect" lazy loader/renderer component for not-yet-fetched models.<p>The tradeoffs thus far have been worth it, but we haven't yet found or built the holy grail. So many things are so much easier than the old ways, but sometimes they're harder.
This is awesome. I've played around with React's server-side rendering [1] and was really impressed once I'd hooked it all up. To see React hook up the event handlers and render nothing at all was really satisfying.<p>I haven't had a chance to use react-router, but it's great to hear that they've put in the work to make server-side rendering a reality. I only hear positive things. Kudos.<p>[1] <a href="http://www.crmarsh.com/react-ssr/" rel="nofollow">http://www.crmarsh.com/react-ssr/</a>
Very cool, I haven't ready looked into react. I have just started with meteor and it's been fun and a big learning experience. My previous background was all with php and traditional client/server nteractions. It's quite hard overcoming that way of thinking. Not really sure if it's relevant but my first meteor app was completely built with calla & methods rather than realising the client/server boundary isn't what it used to be...
Awesome stuff James :) I've been having a lot of those weird client vs. server realizations myself. Still getting used to thinking about stuff that renders in both places.<p>I'm particularly interested in hearing about your ansible + docker setup. I've been using both a lot lately, and trying to figure out the best way to use them together.
Cool stuff. Was planning to do something similar but never got around to implementing the client-side rendering bit (<a href="http://www.jbernier.com" rel="nofollow">http://www.jbernier.com</a>). The codebase I work on at work is also isomorphic JS with React. Sharing client/server code is definitely the way to go.
Yes it is over-engineered. Heck, even WordPress is engineered. Blogs are essentially static pages with the comments as a moving part (i.e. dynamic). Most blogs can happily leave on a static web folder if bound to something like Disqus or whatever you decide to use.
This is very nice! A question though: it does need a knowledge of client state right? How big is that data per session? Is it viable to keep the data on client and send with each request via a cookie so that you don't need more server resources?
Wow, JavaScript is approaching science fiction levels of sophistication! Love the idea of moving functionality from client to server or reverse. Knew about Docker but not Ansible, thanks for that. Now we need some Sweet Macros to help too.
> Unfortunately, full client-side apps (or "single page apps") suffer from slow startup time and lack of discoverability from search engines.<p>This is simply not true. Google announced that they can crawl single page apps just fine nearly a year ago (<a href="http://googlewebmastercentral.blogspot.com/2014/05/understanding-web-pages-better.html" rel="nofollow">http://googlewebmastercentral.blogspot.com/2014/05/understan...</a>) and although Bing hasn't announced anything they are likely working on the same thing if it's not already rolled out.<p>Google does this already; it works. Rendering on the server has little actual value in 2015 but it some how became a critical feature all of the JS frameworks are fighting for without proper explanation of its benefit.<p>EDIT: It's fine if you disagree and I don't even mind being downvoted, but please do explain.
In addition to server-rendered blogs and this isomorphic blog, I wrote a client-side blog called "Jr" (<a href="https://github.com/Xeoncross/jr" rel="nofollow">https://github.com/Xeoncross/jr</a>)
My god so many incredible links of crazy blogs here...<p>I took a certain pleasure in the opposite recently, by writing on a few simple .html files on an Apache server with headers in <h\d> and content in either <p> or <ul>
I've been doing this for a private project, and a LOT of my time is sunk into thinking how my app should be structured. It's an absolute nightmare, but also great fun!
this is a really cool idea, however I can see how some people would try to abuse the app playing pranks on other people and the like.. I don't have an iphone so I can't check if there are some ways that the users are verified (basically a test to see if they are really blind) seems extreme but this might be better to help grow a more 'healthy' community