According to you guys, was the term isomorphic app born from the ability to run JS on the server (and client) and so it’s something unique to JavaScript… Or was this concept around before and isomorphic apps can also be built with PHP and JS?
I am of the latter opinion, so I believe I’m building isomorphic apps, which are SPAs and MPAs at the same time, with PHP and JS…
I tried to voice my opinion at work and that sparked quite of a debate… I think the concept is more important rather than the technologies used but I might be wrong…
Another question that sparks from the JS client and server environment is: are people still approaching progressive enhancement as before?
An isometric web app is a website that shares the same code on both the client and server with minimal replication. The technology is important because the only thing that will run on the client and the server is JavaScript. You could have a web service / api that is written in another language but the front-end would need to be all JavaScript.
Thanks @ZooKeeper, although you could use XHRs to request server code (nevermind the tech) and then update a particular section of the page with the response text… Is this still considered isomorphic according to you?
I would argue that the terminology is irrelevant. The more important aspect is the problem that is being solved. In the case of isomorphic websites / apps that problem seems to be focus on SEO and maximum code reuse across different devices. Building an isomorphic product is more cost effective than creating separate mobile, desktop, android, ios, etc. presences given a means to compile / run the same code on each system. New terms pop up every day. Its important to know the terms only to be able to find / research solutions to problems.
My personal take to isomorphic apps is that you serve a basic functioning page, progressively enhanced with JavaScript so that it behaves like an single page application, while retaining all the accessibility features of a multiple page application. So I could still send you a link to a very particular section of the app however once having landed, client side JavaScript wold take over all subsequent server side requests via XHR, and update different sections of the page accordingly. Those XHR requests would be sent to the server with special parameters that would instruct it through a router to make the pertinent shortcuts in order to return the requested content. In this way we optimise all requests and only work through what’s needed. So basically this is an HTML API to request HTML components, which could be written in any language.
I found this interesting article linked at the bottom of this post, talking about how many times when building SPAs developers break accessibility and basic web mechanisms in favour of an application that is totally reliant in client side JavaScript. There are cases where this is absolutely alright i.e. smart TV applications built with JavaScript… but in general I would not recommend this way to build an application… The main reason being is that when you break progressive enhancement and fail to serve a basic functioning page, developing the application starts to be a nightmare due to the very broken accessibility… that article explains how JavaScript is pretty weak when it fails, and when you start to be unable to navigate through the application while you have to debug it, frustration and lack of productivity sets in.
I don’t know why this sounds to me more like responsive websites rather than isomorphic apps. To me isomorphic would be much less overhead on the server, faster websites that only update what’s needed, that can be rendered via client and server, retaining all the basic web accessibility features… but not necessarily more cost effective…
I’m open to being corrected in any assumptions I have made or anything I said that was not correct. Please enlighten me
I picked up Building Isomorphic JavaScript Apps a couple of weeks back out of curiosity. I’ve only read a few pages so far, so not at all well versed on the subject as yet. Their definition runs as follows though:
##Defining Isomorphic JavaScript
Isomorphic JavaScript applications are simply applications that share the same JavaScript code between the browser client and the web applications server. Such applications are isomorphic in the sense that they take on equal (iso) form or shape (morphosis) regardless of which environment they are running on, be it the client or the server.
I’m not sure whether that’s of any help in answering your question at the moment. I may be able to add more once I’ve found time to do a little more reading.
Thanks @chrisofarabia, that is a book I should read too.
As for the definition it makes I’m probably still unconvinced that it is a land exclusive to JavaScript. We have to bear in mind he’s defining ‘JavaScript isomorphic application’:
Isomorphic JavaScript applications are simply applications that share the same JavaScript code between the browser client and the web applications server.
If you take away the word JavaScript in that sentence and make note of what I mentioned earlier about having an HTML API that could be used to render both via server (through a normal full webpage HTTP request) and client (through an XHR request which requests a specific component to that API), no matter in which language the API was wrote in, then the rest of the definition also fits if the app is both an SPA and an MPA:
Such applications are isomorphic in the sense that they take on equal (iso) form or shape (morphosis) regardless of which environment they are running on, be it the client or the server.
