Hacker News new | ask | show | jobs
by nigel182 3663 days ago
This looks pretty damn good. I'm a little wary though because it makes me remember unfondly the leaky abstractions and blurred line between client and server in ASP.NET webforms. Granted, there is no generated client code here (not counting what webpack compiles from JSX) but I'm suspicious of things that claim to bridge the client/server gap.
1 comments

As I have mentioned to others here and is mentioned in the Rill README the goal of Rill is provide a bare minimum of abstractions over the browser to encourage code sharing and code reuse with isomorphic JavaScript. Even with this goal Rill is great because you can use it "server only" or "client only" or shared, it's up to you, it gets out of the way. The huge benefit is that when you want to be able to share code it's extremely easy and when you don't just use "if (process.browser)" type stuff to clean up the edge cases.

Ultimately I found that when writing isomorphic SPA's the amount of code you "CAN" share is much more than what is unsharable, personally I am often able to share 90% or more of the front end code and just have to throw in a few "if (!process.browser)"'s to hide some mission critical stuff from the client.

With many isomorphic examples you will find you end up jumping through hoops to share code. Rill makes this part easy but that doesn't mean that absolutely everything can or should be shared.