If I may ask, what made you settle on the double dash to disambiguate content from tags? Like is it some sort of nod to SGML from way back when? It seems like an odd choice to me at first glance, but I bet it was thought about long and hard so I’d love to hear some background about what alternatives you considered.
Caching can easily be shared, @rill/loader works perfectly for my needs. For everything else you are more or less correct. However like i've mentioned Rill works perfectly fine as a standalone server side framework or a standalone browser framework.
Everything you mentioned is achievable with Rill. I have found two simple ways to Isolate server only code in Rill.
1) Have two Rill servers, one with shared code and one without. Where the shared code server interacts with the isolated secure api from the other server.
2) Have one server that calls itself through http(s) requests where the api bits of the server and everything else you mention is hidden behind a "if (!process.browser)" statement. With browserify and other build tools you can have it automatically parse out any server side code. This is my preferred approach because I get to bundle all of the important parts of my app together while still having granular control over where things run.
If there's "server only" code, then "isomorphic" is a terminologically incorrect characterization of the architectural style. The code on the server and the code on the client have different structures.
Then your preferred use of "isomorphic" is vacuous. All of programming is "isomorphic" to all other programming. There are a few mathematical proofs regarding that, I believe.
There are some other interesting frameworks that have come up while I was developing Rill such as https://github.com/catberry/catberry but I think (like many have said in this thread) that there is a fine balance to be had with isomorphic JavaScript. For example I really dislike meteor because I feel like I have little control. I like Rill because it is a perfectly capable backend framework, a perfectly capable front end framework and it all meshes together pretty well.
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.
The way that I typically setup my apps is to have two parts of the server. Typically something like:
```
if (!process.browser) app.use(require('./api'))
```
Where the api is your typical REST based api with JWT auth tokens. Then the shared client side part of the api communicates with the secure part through "fetch" which works isomorphically (in the browser it is an ajax request, in the server it is a local http request to itself) you should checkout @rill/fetcher for what I currently use. In Rill there is no issue with having "client only" or "server only" routes, the main benefit is that the api is the same no matter where you are working. Take for example "@rill/progress" which is a progress bar that only does work in the browser, or "@rill/compress" which only does anything on the server or "@rill/logger" which works on both (although with completely different implementations). The goal is certainly to encourage code sharing where possible but to also not get in the way. You can use Rill as a standalone server only app if you want, or even just as an in browser framework, it doesn't really matter.
As for my example with emails it is certainly not real world and I don't recommend having public access to an email api but the point was merely to demonstrate that all of the code could be abstracted to work in either place (even without rill).
What I use to handle state transfer from the server to the client is @rill/session along side @rill/loader. Check them out and feel free to ask me any questions (here or in the gitter!)
I agree with you 100%. You can take this hammer and use it like a axe. But that's not the goal.
My personal setup has been to still separate my api (although still written in Rill) from all of this) which runs as an independent server. Then I have an isomorphic Rill instance communicate with that API. This way I still keep the important things separate.
I use both but personally prefer Isomorphic because in most cases the code isn't actually universal, it has to be translated (shimmed, transpired, etc) between environments.
If there is one thing you can do to annoy programmers though is to use the wrong terminology :p.
It really is a very wrong use of "isomorphic", though:
First, "isomorphic" is a word that denotes a symmetric, relative relation between two separate things; Two things can be isomorphic to each other but one thing cannot be called "isomorphic" without specifying what other thing it is isomorphic to. That simply doesn't make sense.
Second, isomorphism is about those two things having the same conceptual structure, despite being different things. In math, this means that you can define a lossless two-way conversion between the things (you can start with an A, turn it into a B, and go back to an A, and you'll get the same A). In biology, the field the author took his definition from, isomorphic means that the things have a different ancestry but the same structure. This is literally the opposite of taking code and shimming or compiling it to allow it to run in multiple environments, as it would be taking a single common ancestor codebase and lossily changing its structure to allow it to run in multiple environments.
edit: Just realized you are the author. Now I feel silly for referring to you in the third person. In any case, I do want to say that despite any squabbling over terminology, you seem to be doing great work in putting out rill. Developing a full-blown application framework like this mostly on your own is no mean feat. My squabbling stands, though.
_Technically_, it would be more accurate to say that your client is isomorphic to your server. In that regard, the term 'isomorphic javascript' doesn't really make sense as there's nothing to compare it to.
However, everyone knows what you're talking about when you say 'isomorphic javascript', so the pedantry doesn't really matter.
Well indeed, and "isomorphic javascript" is really just dropping the heavily implied "application" at the end.
At it’s core Isomorphic JavaScript describes the relationship between the application that runs on the server and the one it serves to the client to run.
It's perfectly correct - because it's not describing the code it's describing the application(s) and the approach they take.
Sometimes I feel like I'm taking crazy pills because "universal" isn't and "isomorphic" is not only technically correct - it's absolutely accurate for the relationship between client and server side code.
