Yep, you’re right. My only desire is to provide a good and reactive user experience. I’m making my own ergonomie/design.
I feel that at the end the result will be the same, Blaze or React. Maybe I’ll use Blaze because of Atmosphere.
You are developing an app for an audience of 100K to 1M users.
Do you already have that audience? If so, you likely have cash to spend and need to put out a top-notch app, so I’d look into either React Native or standard native apps.
If you don’t have that audience, it really comes down to budget vs quality vs time.
A well-built native app (React Native or otherwise) will have better performance than a well-built hybrid (Cordova) app.
Does this matter? That depends on your app. If you have flashy graphics, yes. In most other scenarios, the performance difference are unnoticeable to the users.
The key of course is “well-built”. Many of my clients have opted for a Cordova app because it is quick and cheap; many of the quality differences between hybrid and native apps come in due to those 2 constraints. If an app has a low budget and is rushed, it obviously won’t have the polish of an app with a bigger budget and more time, and the clients with those constraints opt for hybrid apps… this is part of the reason why hybrid apps have such a bad rap.
If you are just starting out and have a limited budget, it may make sense to develop the best hybrid app you can then rebuild as necessary once the users start picking up. As you start getting close to that scale you will almost certainly need to rethink a lot of your code anyway. 
Blaze vs React? Again in many cases the performance differences aren’t huge, and with a package like manuel:viewmodel, Blaze development becomes pretty awesome. Personally, I’d say to use whichever one you / your development team is more comfortable with. If you start with Blaze but discover down the road that you really need React, you can transition your app to React piece-by-piece.
4 Likes
Thanks a lot for your time dude.
I understand and take note of all your advices. I haven’t that audience, of course if I had this now I’ll just build a native app, but we have many reasons to think that we can reach that in about 1 or 2 years.
The idea, for now, is to rush a first app to build our community then redev it in native.
I think I’ll start with Blaze, it seams to be awesome as React, but many package attract me (package porn 
).
In 2 years from now there will be some new technologies that you will possibly want to take advantage of.[quote=“emant, post:18, topic:19885”]
I think I’ll start with Blaze, it seams to be awesome as React, but many package attract me (package porn ).
[/quote]
Be sure to use some Blaze extension like manuel:viewmodel or Blaze Components - like @nathantreid suggested, they greatly improve the developer experience and make Blaze more powerful, helping with things like reusable components and state management, which are very important with bigger applications. I’m personally fan of the first one.
2 Likes
Would using viewmodel make it easier or more difficult to migrate to React in future than if viewmodel was not used?
I’d say it would make things easier - for example in React you call actions very similar way as in Viewmodel:
React:
<button onClick={this.myAwesomeAction} />
Viewmodel:
<button b="click:myAwesomeAction" />
or even:
<button on="click:myAwesomeAction" />
when you want to use the original javascript click event for some reason.
There’s also Viewmodel for React in the development right now, which will be a very easy way to switch to React from Blaze.
1 Like
Here’s my advice: Keep using Blaze but when anybody asks, tell them you’re using React. This serves 2 purposes:
-
You’ll keep getting awesome things done quickly with Blaze, and won’t get sidetracked by the “What, you’re using Blaze??? OMG - you should really use React!!!” never-ending discussions.
-
This is an awesome way to really mess with anyone new starting on your team (hazing ritual).
17 Likes
kind of agree - be careful investing time and energy into react (or any other technology), the JS community switches so quickly that it’s only worth the effort of using React if it genuinely will improve you or your teams productivity (disregarding marketing yourself as a developer)
blaze is actually pretty good
For myself I went with AngularJS instead of React for my app. However, if you’re learning best to do something new than go deep dive into a single technology too much especially in UI land where technology stacks can change every few years. Even AngularJS will look vastly different from a few years ago when Angular 2 comes out.
Personally I chose AngularJS at the moment because of the Dependency Injection, modules, and other things I was used to on the server side and it allows it on the server side.
My only issue with angular-meteor is it seems like a second class citizen in the Meteor ecosystem. The examples on the main site use deprecated methods already.
I also had some minor annoyances when using things like blaze-with-angular, more like I gave up after a while and just re-implemented some blaze templates as Angular instead.
Overall though, because I can do Angular on the server side is the main sell for me, because I can develop in one “framework” on both ends.
ReactJS and Blaze from what I can tell are both UI frameworks. Whereas AngularJS with Meteor via angular-server makes coding a bit more awesome with Meteor.
1 Like
Yes, be careful investing time and energy into a framework used by Facebook, Netflix, AirBnB, Instagram, and many other $1B+ companies. It might disappear overnight!
Instead, you should use this other framework that’s not actively maintained anymore and only used by a comparatively tiny part of the JavaScript ecosystem. This definitely sounds like the safest option! 
7 Likes
I get your point- but you could have said almost exactly this about Angular 1.x 18 months ago. I’ve watched companies pour literally millions into re-writing apps on Angular 1.x because “Angular is the future and it’s backed by Google”, now the same people that championed Angular are banging the React drum (or Angular 2.0)- but the end result for the business is exactly the same.
If your app is going to stick around for more than a few years (admittedly that’s not always the goal), consideration should be given to future engineers. The devs who understand the benefits that React brings right now are well above average, but sooner or later those engineers will move onto newer things and maintenance will fall to below average engineers, who won’t be able to just pick up React v0.14.4 in a week and be productive.
And for a beginner you don’t really have to “learn” blaze, IMO the cognitive load of React is higher and that’s not something beginners can abstract away immediately, my hypothesis is that a beginner would be more productive with blaze than react out of the box.
6 Likes
That’s true. Billion-dollar companies can afford to discard whatever they have for something new that they think looks better. They could probably afford to have their apps rewritten with whatever supposedly great framework is out at the time on an annual basis.
5 Likes
I like how much faith you have in blaze…haven’t peeked in on the battle in a while but it’s encouraging
1 Like
Now that Blaze has been split out into it’s own project (for real this time), I would love to see some kind of roadmap outlining its future plans. There has been a lot of discussion lately about getting the community more involved with projects like Blaze, and splitting Blaze out on its own is definitely a great step. I’d love to see some discussion around the next steps though, especially with regards to what “future Blaze” will look like, and how we can help out. Some form of concrete plan of attack would be awesome. I know MDG has @mitar spear heading up the new Blaze effort from the community side, but I don’t think he can do it alone (actually, it’s @mitar - maybe he can ).
EDIT: Just to add, I know the open issues serve as a roadmap of sorts, but something a little more structured and concrete could really help build anticipation, and get people excited about Blaze again.
1 Like
I can tell you how I see it from my point of view. I think the first step is to get Blaze to be available as a NPM module. And split also dependencies into separate repositories/NPM packages.
Then having working testing. And some stand-alone documentation page. So first we should have basic project infrastructure.
After that I think it should mostly depend on the community, what would they like to make pull requests for.
As a matter of fact, I do not think I will have much time to work on Blaze myself. I made Blaze Components work pretty well for me and I think that Blaze should mostly now be in maintenance mode, fixing some long standing issues, but should be kept backwards compatible. On the other hand, if there are some backwards compatible changes needed to make new stuff on top of Blaze work, that would also be OK from my point of view. If community would like, we could try to get Blaze Components to be Blaze 2 or something, a new version, but I personally will not be pushing for that. It does not feel right.
I think one interesting next step would be server-side rendering. I tried to play a bit with that and it seems to work well.
One thing I would like to see for Blaze (especially with components) is some type of gallery. Something like I made for Blaze Components: http://components-explorer.meteorapp.com/ (Site is going down all the time, since I migrated it to Galaxy, 
) So a more visual way to navigate Blaze packages.
3 Likes
How about adding virtual DOM to Blaze? There was talk of Ember (which is based on handlebars) implementing it. Maybe we could ‘borrow’ it.
But I do agree that SSR would be great for many applications.