Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Isomorphic JavaScript, let’s make it easier

medium.com

Post reply on HN
Print view View original

31–39 of 39 posts

Re: Isomorphic JavaScript, let’s make it easier

#31

Post by piercey4 »

madeofpalk wrote: post #20

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 d…

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!)

Re: Isomorphic JavaScript, let’s make it easier

#32

Post by piercey4 »

chvid wrote: post #22

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).

Re: Isomorphic JavaScript, let’s make it easier

#33

Post by piercey4 »

nigel182 wrote: post #16

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.

Re: Isomorphic JavaScript, let’s make it easier

#34

Post by piercey4 »

mshenfield wrote: post #15

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?

I mention my inspiration here: https://github.com/rill-js/rill/issues/12.

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.

Re: Isomorphic JavaScript, let’s make it easier

#35

Post by empthought »

abritinthebay wrote: post #30
empthought wrote: post #28

Earlier quoted context omitted.

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, comp…

Clearly you've never written an isomorphic app because your first paragraph is just outright wrong.

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.

Re: Isomorphic JavaScript, let’s make it easier

#36

Post by piercey4 »

empthought wrote: post #35
abritinthebay wrote: post #30

Earlier quoted context omitted.

Clearly you've never written an isomorphic app because your first paragraph is just outright wrong.

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.

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.

Re: Isomorphic JavaScript, let’s make it easier

#37

Post by empthought »

piercey4 wrote: post #36
empthought wrote: post #35

Earlier quoted context omitted.

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.

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…

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.

That's all I'm trying to say here.

Re: Isomorphic JavaScript, let’s make it easier

#38

Post by abritinthebay »

empthought wrote: post #37
piercey4 wrote: post #36

Earlier quoted context omitted.

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…

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. That's all I'm trying to say here.

And you'd still be wrong because isomorphism only implies similar structures and forms/practices.

Re: Isomorphic JavaScript, let’s make it easier

#39

Post by empthought »

abritinthebay wrote: post #38
empthought wrote: post #37

Earlier quoted context omitted.

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. That's all I'm trying to say here.

And you'd still be wrong because isomorphism only implies similar structures and forms/practices.

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.

Call it what it really is: monolingual.

Post reply on HN