Once terminology gets momentum it's hard to change it, it's usually not totally semantically meaningful (socket?!), but it's nice to have a convention. I think isomorphic JS is a ridiculous term, but at least there's a word for it.
I've been using capitalization to denote the difference, just like Agile vs agile: Facebook's Flux or an implementation of the Flux architecture, versus a flux architecture.
I've read Michael Jackson's article and I didn't interpret it as saying that people using the term isomorphic are outright wrong. Some people are making this assertion and that is what I am trying to refute here.
I disagree with Michael's statement that two things that are the same cannot be isomorphic. The very definition he cites does not exclude the possibly of those things being the same!
"Corresponding or in similar form or relations"
(Even in mathematics the identity function is an isomorphism, it follows from its definition. However, we are not trying to prove a mathematical property here.)
But even then the assertion that the server and client side are exactly identical is not correct. Typically such code bases will have slightly different entry points for server and client. Additionally, React 0.14 beta is now splitting the DOM and String renders.
For some 'Universal' is attractive, because they want to use Javascript everywhere. I get that. If you like that, please go ahead and call it 'Universal'.
However, what matters equally is having an abstraction which allows pure functions to declaratively describe the form of components based on immutable data, no matter what the computational model of the target. It is arguably the abstraction that is the isomorphism and code that uses it could be called isomorphic. That could be stretching the term as per the above definition, but that doesn't mean that people who use it are wrong.
I think React provides the necessary abstraction. I have total respect for what the React core team and the community have achieved. I understand that Michael Jackson and Ryan Florence are motivated by wanting to get more people using React. This is a very good thing.
However, other people may be more interested in promoting the ideas behind React rather than React or Javascript specifically. It is these people I am trying to defend.
The term "isomorphic JavaScript" also sounds strange to my ears. I think it’s because in traditional use (in mathematics, linguistics, biology, etc.) you don't say "X is isomorphic", you say that "X and Y are isomorphic".
Grammatically, it’s kind of like the word "similar". I would feel silly saying "JavaScript is a similar language", and I feel equally silly saying "JavaScript is an isomorphic language". Similar/isomorphic to what?
Hello DougBTX. Could you post an issue on the repository describing what you would need for this library to work nicely with TypeScript so we can see whether things can be improved?
This is an interesting point. I created an issue on the github repository concerning this matter. Maybe you'd like to comment on it about your use case so we can improve the tool?
Backend and frontend scraping just don't attend the same needs. Running backend monsters to scrape small to medium amount of data only once is such a drag when frontend scraping can take less than half an hour to perform the same task. Plus you can see the results of your code live while browsing the DOM comfortably. Finally, nobody prevents you from using artoo backend when you execute javascript.
jquery is injected carefully by artoo so it does not break anything on the host page. However, CSP override is not default on artoo and you have to install the chrome extension to perform this. But this extension has solely to be activated when scraping and only developers should use them while knowing its effects.
