Hi @chronixSC,
thanks for your positive feed-back 
To your questions:
I did not start with a particular boilerplate. The app is mainly based on good ol` Bootstrap and SCSS, peppered with selected elements from Materialize, SemanticUI and some jQuery components. Yes, that’s a quite strange mix, as it may sound more sensible to use only one of them. But in the end, I always came back to Bootstrap as the main UI framework, because it just did what it supposed to do, without any weird quirks (like in Materialize). I also tried frameworks that are better tailored to mobile devices (like Ionic and F7), but struggled to make them work properly, and in the end my dev progress was already too far to make a complete switch. I also wanted to address th browser as well, and the Bootstrap / SCSS combination just allowed me to do this. Maybe if I start another app from scratch again (and have a mobile-only approach), I will consider using a mobile-first boilerplate first.
Yes, you are right, Guzz is Blaze-only. I tried Angular before I came to Meteor. And I was quite confused by its over-complicated syntax / concepts. Between Angular and Meteor, I also tried Aurelia and loved its simplicity. But it was in an early stage back then, the performance was lousy and Meteor allowed me to go for a full-stack approach (Aurelia is UI only), so I switched to it. But I heard that Aurelia is quite usable now, and some Meteor folks are using it in combination with Meteor.
Regarding Angular 2: I had a brief look at it but have to agree with the founder of Aurelia that the syntax is just weird. They’re trying to nearly re-invent everything, including using Typescript as their preferred language. Though I am in favor of typed languages in general (JS is definitely missing this) and I see the benefits of IDE integration, the risk is too high for me that you get stuck in a one-way road. And the syntax, … just weird IMHO, already mentioned it.
Regarding React: I clearly see the benefits of React, and if I’d start a new app today, I’d probably try to go this way. But Meteor 1.2 came up when I was in the midst of implementing the app. In this stage, many community packages were not ready for React yet, and many people were struggling with implementing authentication or i18n on top of it. I am not the type of developer who loves experimenting with the latest stuff in a productive app, I rather wanted to keep up the great dev speed I got with Meteor and Blaze. So, although I knew that the community is turning towards React and even MDG was suggesting this (for good reasons), I stuck to Blaze. Another reason was that you cannot easily use jQuery components in combination with React. If you start from scratch, this might not be a problem, as the React community components got a lot of traction, too. But I did not want to waste any time finding replacements for the components I was already using and that worked fine. For Guzz, I will probably follow a slow transition path, i.e. start by peppering in some React when developing new functionality, but for the time being, I am still focusing on getting “business value” quick.
To be honest, I don’t have a real “feeling” about how far React has actually come in Meteor by now. I heard of many people who are really content with it, so it must work now. But what still concerns me is how good community package support is, e.g. for useraccounts, i18n and such. I guess I will have to try it out myself. But I would still recommend trying the React way first, since it seems to be the go-forward approach now. And I trust those community members who are actually way better developers than me, like @arunoda or @SkinnyGeek1010 for instance I am just a front-end guy who tries to keep up with the tech.
Yes, nearly all of the code is shared. The only exception are interfaces to native Cordova plugins, like push notifications (based on raix:push) and WebRTC. So, from a technical point of view, I’d say this is quite optimal, since it avoids double-work. From a UI designer’s point of view, however, this approach causes quite some headaches, because it turned out to be quite challenging having the same UI for both browser and mobile app. The screen-sizes differ so much, so you either have to find some clever solutions to support both or you have to compromise. And I struggled a lot with the different capabilities of the devices. For instance, I had implemented some quite fancy UI elements like slide-out menus and such. But then I tried them out on my (quite old) iPad 3 and the performance was just lousy. So I refactored and made the UI much less fancy. This would be a lot easier if you implemented everything on top of a proven, performance-optimized mobile framework like F7, but then you have the problem to deal with the browser as an additional (non-mobile) platform separately.
Everything is in one project. But nearly all of the code is separated into custom packages. The main Meteor folders (like /client, /server) only include top-level code, like heavily re-used templates or the core SCSS styles. I can strongly recommend to follow a “package-first” approach, since this makes your app much more maintainable. Plus, you have a quite fine-grained control of which code goes into the mobile app and which into the browser app. You can even create packages that are mobile-only. Nowadays, I would even move my core templates into their own packages, because it helps a lot to keep an overview of your code base. And it allows you to easily share components between projects, using the global package folder Meteor supports. Not sure if all of this will survive the transition to NPM, since I did not delve into the new 1.3 world yet.
The biggest roadblocks were:
-
Transition from Meteor 1.1 to 1.2. This nearly made me despair, and I needed several attempts to do the transition. The main reason was that I found a quite “creative” approach to mix SCSS and Bower components into my app. This approach worked fine in 1.1, but was completely broken by the changes MDG made to path handling in 1.2. Eventually, the solution I found now is much better (and helped me to better modularize my code), but the transition was (too) hard. I really hope that the transition to 1.3 will be smoother. I also have to say that many other devs had no problems at all transforming their apps from 1.1 to 1.2. Maybe it was just me and my “creative” approach.
-
Internationalization: I wanted Guzz to become a global service from the beginning, so i18n was key to me. But at the moment, Meteor lacks really good i18n support (or I did not find the right package yet). I am using tap:i18n, which works quite well, but problems come up once you want to support both mobile and browser. The reason is: If there’s no network connection, the UI always falls back to the default language (which is English im my case). This makes a bad user experience, if you start the app on a mobile device without network. There’s a solution for this available now from the tap team, but I could not make this work yet (and did not have time yet to try out their latest fixes). Plus, for whatever reason, tap:i18n turned out to be quite unreliable when the number of text files exceeds a certain limit. I am facing weird behaviours, like some texts showing up in English instead of German. The only workaround is a meteor:reset of the project. Maybe this is also due to some strange bug I introduced by myself, but I did not find out the root cause yet.
-
Performance on mobile devices. As described above, I had to make many compromises between usability (i.e. fancy animations and such) and performance, since I wanted to make Guzz run smoothly on at least an iPad 3. Besides this, performance on older Android 4.x devices is often much poorer than on new devices. This can be fixed by adding Crosswalk now (which brings its own Chrome component under the hood), but this was not compatible to other plugins I was using, so I am still using the default webview. But I will try to get rid of this as soon as I find the time to do so. React Native might be a game changer here, but as it forces you to tailor your code to specific platforms, this also breaks the one-code-for-everything approach, at least to some extent (you can still re-use a lot of code, of course).
-
User authentication (sort of): I can warmly recommend the useracounts package, but still it seems as if it was mainly designed for browser use. For mobile devices, I had some trouble to make things work as expected, and I still have to find a way to really integrate social network logins. It might be me being too dumb, but the straightforward approaches did not work as I would expect and so I postponed this.
-
Lack of built-in SCSS support. Meteor focuses on Less and leaves SCSS up to the community. The team behind fourseven:scss are doing great work, but it took some time until I could use SCSS again in 1.2, since MDG had introduced some breaking changes in this release. It’s fixed now, but I would love to see SCSS to be supported per default (and sashko already gave a clue that this might change).
-
My own inexperience with Meteor when I started the project 
But despite these “roadblocks”, I want to stress that my app would have never ever been possible without Meteor! I really love this framework, and still don’t see any alternative on the market that I could use. As I already said, I am not the “core dev” type of guy, and I would have never dreamed of being capable of building such a full-stack app before I came to know Meteor. And the best thing is that the community (including MDG guys like @sashko and @martijnwalraven) is really, really supportive. In most cases when I asked a question on these forums (or on Github), I got an answer in only a couple of hours, if not minutes. This is just amazing.
