Live data from Hacker News

Isomorphic JavaScript, let’s make it easier

medium.com

11–20 of 39 posts

Re: Isomorphic JavaScript, let’s make it easier

#11
post #9

Earlier quoted context omitted.

The JS community switched from the term "isomorphic" to "universal" around a year ago. Seems not everyone is on the same page yet.

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.

THANK YOU.

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.

Re: Isomorphic JavaScript, let’s make it easier

#12

"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. Kthxbai!

You don't understand isomorphism outside of a very very very narrow usage of the term. Especially how it is applied here.

kthxbai!

Re: Isomorphic JavaScript, let’s make it easier

#13
post #9

Earlier quoted context omitted.

The JS community switched from the term "isomorphic" to "universal" around a year ago. Seems not everyone is on the same page yet.

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.

Re: Isomorphic JavaScript, let’s make it easier

#14
post #9

Earlier quoted context omitted.

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

> It really is a very wrong use of "isomorphic", though

It's really not.

> Two things can be isomorphic to each other but one thing cannot called "isomorphic" without specifying what other thing it is isomorphic to.

Good thing we're talking about the relationship of client and server code then so we're not doing that then isn't it?

> isomorphism is about those two things having the same conceptual structure, despite being different things.

Yup, still perfectly on topic here with Client vs Server...

> In math...

Ah well, there's your problem. It's nothing to do with the mathematical definition of the term.

Re: Isomorphic JavaScript, let’s make it easier

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

Re: Isomorphic JavaScript, let’s make it easier

#17
post #9

Earlier quoted context omitted.

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

[deleted]

Re: Isomorphic JavaScript, let’s make it easier

#18

"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. Kthxbai!

The JS community switched from the term "isomorphic" to "universal" around a year ago. Seems not everyone is on the same page yet.

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)

Re: Isomorphic JavaScript, let’s make it easier

#19

Earlier quoted context omitted.

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

> It really is a very wrong use of "isomorphic", though It's really not. > Two things can be isomorphic to each other but one thing cannot called "isomorphic" without specifying what other thing it is isomorphic to. Good thing we're talking about the relationship of client and server code then so we're not doing that then isn't it? > isomorphism is about those two things having the same conceptual structure, despite…

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

Re: Isomorphic JavaScript, let’s make it easier

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

Post reply on HN