This is something I always wanted to talk about.
In nutshell, isomorphic apps are great in concept. But they’ll lead us to a very scary point if we followed that path. I’m not saying optimizing our apps for Mobile is bad, but building mobiles apps based on our usual app is a bad idea.
I’m not sure everyone will agree on this. But, I assume you’ll find this article useful.
Give it a Read: Say No to Isomorphic Apps.
I’m a bit confused by your opinion. Let’s say I built an isomorphic application, and deploy it for the web. What’s stopping me from building mobile apps for a number of platforms by utilizing, say a DDP client as a part of this mobile application? My web application is still benefitting from my isomorphic codebase in terms of latency compensation, and I still get to target mobile users with native features, by developing them separately and connecting them.
I don’t see how isomorphism is stopping me from attaining mobile native features, as these client apps can be developed separately and connected with a client API. Am I making false assumptions?
I think this is exactly what he’s advocating. It sounded to me like he was saying that you shouldn’t use your Meteor code base for mobile apps, but that you should develop them separately like you pointed out.
Ah - I see now 
thanks for pointing this out.
but that means Isomorphism is great, just not in mobile apps 
I’m getting it now, but I do think the title is misleading, as isomorphism is great if you don’t mix it with mobile IMO.
Ya isomorphism is a moving target. I’m not sure anyone knows what it actually means haha. In practice, I don’t think there is such a thing as REAL isomorphism. My big meteor apps definitely have defined server/client code so the two ends aren’t really sharing all that much. Meteor just provides the glue for making the experience seamless (e.g. no manually wiring up API endpoints and connecting on the frontend).
Yup! Right on. In addition, I don’t think it’s possible to use the same Meteor code base for mobile apps. I seem to have to write a lot of extra code to make an app work on mobile which makes me think that I should probably just build the app separately and connect to the API server. I think @arunoda is right on in his recommendation
I wholeheartedly agree - Meteor client code in native apps, be it mobile or even a windows app, seems like a bad path to follow. All native platforms have web-browsers anyways, so why utilitze native integration in my codebase anyways? Cordova has been criticized plenty already, so won’t add to it here. I think React native will sink into the ocean aswell, but what do I know…
my concern is the lack of differentiation between native apps and browser apps, when saying that we should say no to isomorphism. I felt like I was being encouraged to stop utilizing isomorphism for my browser applications I found it quite misleading, in spite of the good points if you keep in mind the conversation is about native apps.
Personally, I don’t care much for native apps - I love the web browser, and could probably get rid of 80% of everything on my machine, and still have access to most of what I actually need through the web browser
Interesting point of view here. But, I think you are assuming that the playing field is even. For me, as a sole developer working on several projects I don’t have the luxury to support separate code bases and isomorphic is a godsend. I would certainly agree that it can become a trap, but overtime it has been getting better and better. With the added value of react - I’m able to export my components to react native. Which is a very exciting proposition as its cutting my development time and BUGS by 20%.
I agree, in my opinion it’s a fallacy to think that you can build one app and deploy to several places (desktop, ios, android).
It might be ‘slightly’ faster than building 3 separate apps once you deal with all the edge cases… assuming you can write all 3 without learning more. If you can learn once build many, I think you’re in for a better product and smoother workflow.
Building a less monolithic app will help you build several ‘targets’ with relative ease. You can have a main ‘data’ server that apps login to and subscribe to and then you can have an iOS, Android, Desktop app consume this data server.
This also lends to being more flexible for unforeseen changes in the future.
btw: https://medium.com/@mjackson/universal-javascript-4761051b7ae9 
‘isomorphic’ is not trendy anymore
While I agree mobile needs special attention and can’t just be the desktop version squeezed in a smaller screen, I think the blog post tries to be a bit too prophetic: Predictions about the future, what your users will say if you do A or B…
Most apps don’t do/need very fancy UI stuff, so I can imagine in the future web apps will be more than fast enough to deliver a UX experience that is on par with the native one.
Sorry, Arunoda, but going to have to disagree with you on this. This is just FUD. Plus, I suspect you’re using ‘isomorphism’ differently than other people, and have shifted its definition.
For folks with clear industry use-cases, single-codebase applications are very achievable and can make lots of business sense. The issue is that the industry hasn’t settled on a cross-device design standard. But we can look at projects like Metro, Parallax, Material, and the templates at WrapBootstrap to see where things are going.
But for what it’s worth, I do agree that there is a long-tail with Android devices, which makes it very difficult to design for all configurations and features. Getting good cross-device design with a single codebase requires knowing your industry really well, and saying ‘not going to support this browser; not going to support those devices; not going to support these operating systems’. That requires market strategy and design authority; which aren’t always readily available.
Hmm… I agree and disagree at the same time. 
To elaborate:
On one hand, I can see the value of building a Meteor app and rolling it out simultaneously for web, iOS, and Android. Yes, the mobile apps won’t feel 100% native, but some clients don’t care. They just want a presence in the AppStore/Google Play Store.
On the other hand, I’m working on a mobile app now using Meteor/Cordova, and there are definitely some frustrations involved. I have to come up with hacks to make it feel more native, such as gestures that people are used to (swipe from left edge = go back). Or even the work involved in having a page/card that slides onto the screen when you drill down into item detail just feels like too much work. On top of that, even though it’s a mobile app, it still needs to connect to a Meteor server for reasons that I feel are totally unnecessary (e.g. Facebook OAuth), so you have to have the server counterpart running somewhere. For mobile apps that are only fetching data from a REST API and not storing data in a database, it doesn’t make a lot of sense to me.
I’ve started to get into React Native, and am super impressed so far. It’s pretty refreshing to not have to think about grid columns, and instead use flexbox for everything.
Absolutely agree, but the title threw me because when I think “isomorphic” I think same code between client and server (AKA “universal” https://medium.com/@mjackson/universal-javascript-4761051b7ae9#.ex2okb6lc), not same code across multiple clients. Regardless, 
Agreed. The use of ‘isomorphic’ in the article is different than what was originally popularized by MDG. I suspect there are some ideas in this article getting lost in translation.
Hey, yeah I agree. It seems like Isomorphic is bit confusing here. As suggested Universal is a much better name. So, I renamed. But the core idea of the article is the same.
Ahhh sorry, I should’ve been more specific. To me, “isomorphic” and “universal” are both ways of saying the code runs on the server & client (let’s see what everyone else thinks though).
I think a better word might be “hybrid” or “hybrid cross-platform app” to signify that multiple devices share the same client codebase. But after the first sentence it’s clear what you mean
JS naming semantics are a mess right now…
For me (and I am sure this is more and more popular these days) the applications I am developing are meant to be consumed on mobile. The fact that Meteor allows me to easily make it available on the desktop is just a bonus!!
I don’t see why I would bother with a native app for Android and iOS when the mobile webapp experience has been tailored to suit mobile from the get go.
I just wish that there were some better hooks and integrations available across all platforms for the webapp.
Some things are still buggy, like display:fixed elements jumping around when the keyboard pops up etc… I am happy to work through those issues.
Yep! We have responsive CSS that makes the app fit nicely into mobile devices and being able to just generate working mobile apps is a godsend.
Will it be as performant as a native solution? No.
Will this work until we get seed money? Absolutely!
I’m saying after Seed or validated your idea
@arunoda I agree with you. And the point is, that if Meteor tries to cover every platform from a single code base, it will not be able to survive in long term.
The most of the apps don’t really need real-time features… but if so, Meteor should provide a simple way to include the meteor-api into any platform instead of trying to include any platform into meteor.
So to stay with Meteor, the MDG should provide an universal meteor-api-client and improve serverside capabilities.