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

21–30 of 39 posts

Re: Isomorphic JavaScript, let’s make it easier

#21

Post by abritinthebay »

madeofpalk wrote: post #19
abritinthebay wrote: post #14

Earlier quoted context omitted.

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

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.

Re: Isomorphic JavaScript, let’s make it easier

#22

Post by chvid »

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.

Re: Isomorphic JavaScript, let’s make it easier

#24

Post by tluyben2 »

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, clientserver, 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?

Re: Isomorphic JavaScript, let’s make it easier

#25

Post by gtf21 »

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

Re: Isomorphic JavaScript, let’s make it easier

#27

Post by empthought »

abritinthebay wrote: post #12
biocomputation wrote: post #4

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

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

Re: Isomorphic JavaScript, let’s make it easier

#28

Post by empthought »

abritinthebay wrote: post #10
mikemikemike wrote: post #8

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.

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

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.

Re: Isomorphic JavaScript, let’s make it easier

#29

Post by piercey4 »

gtf21 wrote: post #25

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…

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.

Re: Isomorphic JavaScript, let’s make it easier

#30

Post by abritinthebay »

empthought wrote: post #28
abritinthebay wrote: post #10

Earlier quoted context omitted.

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

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.
Post reply on HN