This looks like a really interesting model, less hacky than the current approach of 'lets take client-side react-router and somehow make it work on the server' approach.
What isn't answered here however is how it transfers this 'config' and the rest of the state and make it work in the browser. Does rill come with its own client-side router (that works nicely with React?) How does it serialise the state and send it down for the client resume?
Ultimately, the reason 'universal javascript' is hard is because everything's 'modular' so you can get more controller over each component and customise exactly how it works. While rill might be 90% for 90% of use cases, I can see something like this falling down once you start to build anything non-trivial.
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!)
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.
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.
How is authentication/authorization handled in this example?
The code hits a web api that sends out a batch of emails. Doing this from client side has an obvious set of problems, whereas had it been on server side one can assume a stricter use and thus have a simple security model.
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).
This looks like a very appealing framework, but reminds me of the horrors of using Google Web Toolkit or Meteor. There are different concerns when writing on the client (less controlled) and the server (more controlled) - chvid mentions the security model being different, and this is very true.
The use-case which I think this does seem to solve very well is between dynamic and static rendering of web apps (especially when using react). The ability to bundle up routing and rendering and have it handled by the client if possible and the server if not is a great idea. Apart from this, I am not convinced that this framework solves any major problems, but does introduce a lot more magic (which is why I disliked meteor).
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.
in the case that isomorphic javascript takes over the web for whatever reason, it will be just a matter of time people will be wanting the client/server distinction all over again. it's a sure cycle. but regardless, what OP did looks like excellent work, love the simplicity.
Is this really a problem? We don't have too many issues using currently (and older) technologies to make this work well enough for production systems. The focus on the frontend of things is nice though and we know how to make API's (fast), however, is someone fixing any of this for the data? So I want to make a React JS and after that React Native app, I want it to work (mostly) online and offline; it needs to have solid SEO for some pages and no SEO is needed at all for others (behind login). I want to store / sync data in our store and I need to call a bunch of API's and present and/or store locally and/or server the results. There are technologies enough; Parse server, Hoodie, Couch/Pouch, Meteor, Realm, REST API's, Websockets etc however they all only solve a (small) part; is anyone working on or is there something that would allow me to simply annotate connections specifying their behaviour (sync server->client, client<->server, client->server, what the sync behaviour is, how long data is valid, caching behaviour, how to resolve conflicts etc etc over different backends => our problem with picking any 'nosql' backend is that we really don't want to; we can just add a UUID in the REST api or give the synching code some 'hash' function of what 'unique' is etc) without having to do all that manually?
We can handle it fine manually but we notice we are basically doing everything all over again in a next project and putting that in libs now to be open sourced (maybe someone can use it), however that is for C# and I'm now wondering if there is something like it for JS already ; we cannot be the only ones having these deja vu's with every project?
If you like working with declarative code, checkout RxJS and specifically Cycle.js. It's totally isomorphic and lets you think of apps as streams of data.
If I had to sum this up, I would say rill is an isomorphic/universal javascript server. Are there examples of other libraries implementing a similar idea?
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.
Great question. I personally use @rill/session along side @rill/loader. Basically on the initial page load @rill/session asks the server for the current session then for the rest of the users session the browser manages the data.
"Isomorphic" Javascript? If there exists an isomorphism between the code on the client and the code on the server, then someone should be able to write a proof.
Otherwise, using the same language on the client and the server does not constitute an isomorphism.
I for one haven't. Isomorphism as a word is used not just in Maths where it has a precise meaning, but in other subjective contexts as well. At a general enough level, it denotes some kind of structural similarity between two objects, not just a clear one-to-one mapping. Web development is not mathematics and so we can have different definitions for words, and this is unfortunately the best we have to convey this particular idea. ('universal', to my taste, is too broad and confusing)
It really didn't. Universal is flat out wrong unless you're using the exact same code on both server and client.
Isomorphic is 100% correct if you use the definition from biology, crystallography, sociology... etc etc. It's more technical of a term in one single field. In every other way it's a perfect description.
* Sociology: a similarity in the processes or structure.
* Crystallography: two structures closely similar in shape, formulation, and structure.
* Biology: a similarity of form or structure between organisms
All of these more closely describe a JavaScript application that lives on the client and server - because while they will be similar the likelihood of them having the complete same code (and therefore being universal is minimal.
Aside from being a set of instructions to complete some computational task, server-side code has very little similarity of process or structure to client-side code. "Isomorphic" is a bad description no matter what intellectual discipline you pull the word "isomorphic" from.
Taken from crystallography, the JavaScript here is like the oxygen in silicon dioxide and in water. Same material, same physical properties, completely different structure and function depending on where it is.
Form validation and DOM rendering are the only things that could look the same; literally everything else (data access, concurrency, remote requests, security, caching) will be different because the runtimes and the system architecture contexts are entirely different.
Clearly you have yet to work on something that isn't just form validation and DOM rendering.
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.
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.
> In the first place, singularities-events correspond to heterogeneous series which are organized into a system which is neither stable nor unstable, but rather 'metastable', endowed with a potential energy wherein the differences between series are distributed... In the second place, singularities possess a process of auto-unification, always mobile and displaced to the extent that a paradoxical element traverses the series and makes them resonate, enveloping the corresponding singular points in a single aleatory point and all the emissions, all dice throws, in a single cast.
-- Deleuze, as quoted in Sokal and Bricmont's "Fashionable Nonsense."
Misusing technical terms in order to fake a veneer of intellectual respectability should be called out every time.
What isn't answered here however is how it transfers this 'config' and the rest of the state and make it work in the browser. Does rill come with its own client-side router (that works nicely with React?) How does it serialise the state and send it down for the client resume?
Ultimately, the reason 'universal javascript' is hard is because everything's 'modular' so you can get more controller over each component and customise exactly how it works. While rill might be 90% for 90% of use cases, I can see something like this falling down once you start to build anything non-trivial.