Isomorphic JavaScript Applications — the Future of the Web?



Originally published at:

One of the best known mottos around the web is Java’s Write once, run everywhere. But does this motto apply to Java only? Can we use it to describe JavaScript too? The answer is Yes.

In this article, I’ll introduce you to the concept of isomorphic JavaScript applications, describing what they are and pointing to resources that help you develop this kind of application.

How We Arrived Here

Many years ago, the web was a bunch of static pages made with HTML and CSS without much interactivity. Each user action required the server to create and serve a complete page. Thanks to JavaScript, developers started to create nice effects, but it was with the advent of Ajax that a revolution started. Web developers began to write code that could communicate with the server to send and receive data without the need to reload the page.

As the years have passed, the responsibilities of the client-side code have grown a lot, resulting in a new type of application known as the single-page application (SPA). In an SPA, all the necessary assets are retrieved with a single page load, or dynamically loaded and added to the page as necessary. Some examples of SPAs are Gmail and the StackeStackEditdit editor.

SPAs allow for better interactivity, because almost all their operations are executed on the client, keeping communications with the server to a bare minimum. Unfortunately, they also have some major problems. Let’s discuss some of them.

Continue reading this article on SitePoint


Nice article, I am just learning meteor..and it is really awesome..specially the part the it can just run on android and iPhone just with 2-3 commands..althoug I can't really see how it could replace larger applications..maybe in the future smile


Nope, not buying it.

Go to a site powered by meteor, for example their own site:

Disable javascript in the browser, and this is the kind of nifty looking webpages you get:



Good luck getting any search-ratings with site full of that stuff!

How is this "the best of the two worlds."?

At least Meteor, seems to be the exact opposite of whats described in the article.
Its like flash-only sites for the new millennium.


Good luck getting any search-ratings with site full of that stuff!

This is basically the reason why I am still hesitating to use any kind of javascript rendering for actual consumed content. Not everybody uses WordPress by default for anything that is not a webapp. Everybody has been crazy about angular and its competitors for years, making it seem like the only thing produced nowadays is applications. ._.


Maybe what we really need is an agnostic language -- you write the code, and the language decides which bits run on the server and which bits run on the client.

In the meantime -- progressive enhancement! Remember that? smile


I must admit, I thought the article was rather on the short side - isomorphic apps for a sound bite generation?


I think you didn't get the real Java's motto

"Write once, test everywhere"

This is just my opinion so please don't be offended. I hope the idea of using front-end and back-end with a single language DO NOT become immensely popular. It is popular but I don't want it to be the standard. Imagine a world where 99.99% of the web application is written using JavaScript. As a developer, we're known to get 'bored' very quickly. I don't want to write only JS for next 30 years of my career. Also, not everyone likes JS. I consider JS as a 'double edged' sword..since there are so many ways to do dumb things compared to other strongly typed languages. I prefer a language that is a 'single edged sword'. It's not as efficient as 'double edged sword' but I just feel safer. By all means, I'm not saying Node.JS is horrible or not but I feel a developer should not be afraid to learn a new programming language and not be stuck on 'Js is the best and this is the only thing I'll ever use' mentality.

Also, the code sharing for front-end and back-end have horrible use cases.
Purpose of

Front-end: Provide UI and provide visualization from back-end data
Back-end: Process business logics that usually deals with integrating with multiple datasources (database for ex.)

There is very little share code in between because they serve different purposes. They commonly use example of 'Form field validations' that is used on JS side and Server side.. Is it that much redundant code to check for field that has a value or not or doing date format check? So at the end, I'm guessing less then 5% of the code is being shared between front-end and back-end. I can be wrong and I like to be proved wrong. Using universal language to share 5% of the code doesn't make any sense to me.


there are ways to overcome website crawlers. One of them pre-rendering pages with phantom on the server, and when a robot requests a page, the server returns a static html.
check here for example


For those here who are complaining about the SEO implication of using Meteor there is a package dedicated to eliminating that disadvantage called spiderable. As for "Isomorphic" applications having spent the last few days reading about Meteor I'm both intrigued and concerned. I'm intrigued by the radical change in philosophy that directly correlates to increase of performance. Though I'm concerned that change is so radical that it will lack adoption simply for the fact that it seems before it's time and premature for building large scale, enterprise level architecture in comparison to tried and true stacks. Many of which offer a more feature rich ecosystem of libraries and tools to achieve specific business goals. Once well known content management systems begin moving to this technology I will be sold but until than I still think that this is to radical to embrace for the masses. Could this type of infrastructure become as popular as LAMP, Rails, etc. perhaps but I wouldn't think anytime soon. Definitely clever and something to watch possibly use for the right project but I would tread carefully given the incompleteness and lack historical success. If this technology is truly evolutionary perhaps it could eliminate or significantly reduce the necessity of caching layers required for many current high traffic, web based software applications. Eliminating the need for caching layers would be impressive and certainly revolutionary for out of the box code. I do find it interesting though that the concept of an isomorphic application using a framework like Meteor breaks the fundamental ideology of separation of concerns and language agnostic service based applications. The code I see looks a lot like the old days of mixing presentation with behavior using embedded and inline behavior. Yet this seems to be the new hotness.


Just reading trough the posts..I saw lots of concern about SEO..but actually this is not the can just simply tell google about your app with meta tags and the fragment attribute and now when a robot visits your site.. meteor recognizes it and you can prerender the html on the server side which can be now perfectly crowled..
I am just planing to put into production my first meteor app and I must say I am kind of easy and quick the development is and how many packages are already out there to help you..of course and don't really see it fit for long term projects just yet..but it isn't impossible smile

It is like when someone says that what 10 .net developers can do in 6 months..can 2 php developers do in 1 can just simply add to it can 1 meteor developer do in 2 weeks smile


Client side javascript I get. This, not so much...

Too much trust on the client. Even more things to go wrong client side. Which means even more validating/verifying/lack of trusting on the backend to make sure the data thats getting sent back is correct. I can write it in the same language but I now have to write more.


Not really true..I would have to do the client side stuff anyway its basic have validation and so on..the thing is that the client side doesn't really is just that it automatically connects with the back-end and it gives you real time like it does all the things you would usually do with if you have built heavy ajax apps you know how complex it can become and how hard it becomes to deal with basic things


To me this seems that they've done it wrong not that the approach is invalid. I understand that it's insane to advertise a framework of this kind and than have a website that renders nothing when JavaScript is disabled, but I still believe the concept is awesome.


Good luck getting any search-ratings with site full of that stuff!

Did you do a query on Google for "Javascript web framework"? Have a look at the result, I think it's not that bad for a "search-rating" because the first result I get from Google is a site made with Meteor.


This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.