Blaze or React, what should a Newbie do?

help
41

+1k for Hanselman reference :slight_smile:

42

Maybe I just don’t understand your point, but it seems like you have a lot of misconceptions about what React actually is? It looks like you’re thinking about React Native, not React itself.

I would also recommend you don’t present your speculations (“the driving reason has evaporated”) as facts, it’s already hard enough for new developers to choose the right technology as it is just based on the current reality.

1 Like
43

I disagree with that. React is a new approach to doing things, which is more suited to certain scenarios, and the speed difference is still there.

44

Thanks @sacha for your comment

I have been around long enough, I don’t believe I have misconceptions. I am indeed, however, oversimplifying for this post.

React Native is a key component of the React echo system. (We could research which came first, ReactJS and React Native). In essence, what it does is encapsulate App UI design elements into components to avoid seeing the underlying HTML so your code works on both Web and Native mobile. This way you avoid Webviews altogether with the same (or similar) UI code. I get that some believe it’s better (thanks to reuse, encapsulation etc.) but that’s besides the point (in my humble opinion) for the original developers (which is SUPER important for the health, maintainability and roadmap of React).

Time will tell if my point is valid … once the faster webviews become the standard, we’ll see how far React goes.

Now, each to their own, use React, Web Components or even pure HTML5. They are all valid. The original poster is asking what to start with, and the answer should be what will get him to his destination faster and easier – and at the moment, even confirmed by MDG, that’s Blaze.

Important note: As mentioned before, a big part of the roadmap for Meteor for next year is being data-source agnostic, hence the investment in GraphQL. This is the right way given corporate feedback. This means the community may have to shoulder a big part of development of other Views and their ecosystems.

46

Actually, I am not looking for the fastest or easiest route. I am interested in the tools that have the best chance for longevity so that I don’t have to completely rewrite everything in the near future. I don’t mind a challenge (of course, easier is nice!). I am just looking for the most appropriate choice.

47

@ptken, that’s a tall order :slight_smile:

The challenge lies in the fact that the road is not really paved yet with anything other than Blaze, which is the original view engine. You will find that you have to do a lot of the basics. For example, there are some excellent libraries that can help you get faster, including the amazing aldeed:autoform for forms (and its large ecosystem), sach:flow-db-admin for amin panels (or yogiben’s but that uses IronRouter) and philippspo:momentum-flow-router for app-like behaviour.

I also can’t say honestly that you won’t have to rewrite anything if you use any other view engine than Blaze; as the community is shouldering a big part of the development things many change and / or break. This is precisely why you have so many questions on this forum for React (and sometimes Angular) and little for Blaze – the latter is mature.

Again, bleeding-edge vs. mature and stable. Whatever direction you take, good luck and please come back and post your experience for all of us to learn.

EDIT: And for completeness sake, I have to say that there are a lot of consultants on these forums – consultants need change, need new exciting things to sell their services, write blog articles etc. Not really a bad thing per se, not disparaging anyone, just stating things not so obvious to new comers.

1 Like
48

I am sorry to say, but with Javascript development in general, there’s no such thing as “future proof”. With so many libraries, frameworks, etc… users have a huge list of options to choose from, and the product choices that the user choose to back is constantly in flux.

React definitely has a lot of momentum right now. But then again, Angular had a lot of momentum a couple years back as well. Within 1 year React went from approximately 1/3 the traffic of Angular, to surpassing Angular. (Sources: https://www.reddit.com/r/reactjs/about/traffic and https://www.reddit.com/r/angularjs/about/traffic).

Unless some sort of js “standard” appears, there won’t be anything that’s truly future proof in the js world. Theres no way for us to know if something new is going to manifest amazing momentum in a year and actually catch on.

I know this may not be reassuring to you (nor is it to myself), but it’s the truth.

I recently had to decide for my new project if I wanted to stick with Blaze or go with React. I seen the posts on here with people not sure of which direction to go, and I seen MDG’s unsure direction of which to back. Also other factors, like Reacts momentum might give it much more job opportunities. In the end, I personally decided to stick with Blaze. That way I will not have to write all my code over, and more importantly, I’m getting new employees who will be working on this project with me, and if we go React, that will be a much bigger learning curve.

Since there is no real sure way to go, it mostly comes down to personal preference. If you try to base it on being super proof, or job opportunities, you can go with what seems to have the most momentum right now, but that could change at any time.

You can also stick with Blaze, as basically anything in HTML form is immediately compatible with Blaze. Even though React has a very good ecosystem, I don’t think it yet matches the ecosystem you can have with Blaze between Atmosphere as well as easy compatibility with any already existing HTML. Also, unless your project is a very large project with multiple users, React isn’t really necessary and will likely add to higher development time. Even if you compare Blaze + having to switch Blaze to another view layer, that will prob take less development time than it would to make your whole project in the ground up from React (unless of course you are already very comfortable with React). Keep in mind, React isn’t set in stone either, and simply using React may lead to you having to rewrite much of your project when React updates.

I also look at that as a hidden bonus of Blaze. Since Blaze is pretty simple, even if they update Blaze, likely everything we have will still work. If in the future we do end up having to move on from Blaze to React, or any other view layer. Blaze is basically HTML, and it should be much easier to refactor HTML to another view layer, than it would be to migrate from React to another view layer.

I currently am under the impression that, even if MDG changes the recommendation from Blaze to React in the future, I highly doubt they will completely drop support for Blaze. Yes, future development of Blaze may not be done, some Meteor packages may be designed around React (we already see this problem elsewhere though, with certain packages based around Ironrouter, etc). But what we have currently in Blaze should still at least work.

Of course, I do have my worries though. I would love it if MDG actually confirmed if my impression is true or not. But in the end, I’m confident that they won’t screw over all the Meteor users who have already invested time in to their software. That would do more damage to Meteor than the potential gain would be worth.

2 Likes
49

@Spyridon … Great points.

I especially like this one: [quote=“Spyridon, post:48, topic:17206”]
You can also stick with Blaze, as basically anything in HTML form is immediately compatible with Blaze.
[/quote]

Maybe that’s why my ‘old school’ brain is resisting React (disclaimer: I come from PHP, Perl, Flash and Adobe AIR) and anything that encapsulates / hides HTML. HTML is here to stay, does the job well, why add an opaque layer on top – add risk and complexity.

50

Yes. While I do like some aspects of React (it’s pretty awesome for organization purposes not having to manage a .html and .js file for every template, and the server rendering features are great, although not required in my current project), React simply does things pretty differently overall.

You can’t switch all your existing HTML work over to React in minutes, like you could in Blaze. You can’t get away with not training new employees in React if our project uses it (that is very important in my case).

Our new employees are skilled in HTML/CSS/JS, mostly worked on front end in the past. No Meteor experience. That said… I am sure it’s not going to be a problem. Our applications foundation is already completed. I could easily show the new employees how to work on client side in Meteor in just a couple hours. By simply giving them a list of collections & their schema, they could easily make a layout on their first day and get it working properly.

Then when time to move beyond that, Meteor is simple enough that a front end developer could learn to do some server side work. I already set the project up with a foundation and a few patterns for how we are going to be adding future updates. I simply need to show them the patterns used for the project alongside the Meteor basics, and with all the examples we have in our live application, they will be good to go for adding new features.

That’s the beauty of Blaze imo. Node/Meteor is simple enough that anyone experienced in JS for front-end work will be able to pick it up relatively fast, and Blaze is simple enough that anyone who knows HTML/CSS/JS will be comfortable nearly instantly. We don’t need to overpay in order to find developers specialized in a specific language, framework, AND view layer. We can simply pay for someone who has a solid foundation in HTML/CSS/JS and they will be perfect for the job.

That’s the reason I’ve loved server-side JS from the beginning. It builds upon the basics found in every single project on the web. It’s based upon common web design knowledge, it’s simple, elegant, straight forward, easy, and a pleasure to work with. And Meteor, along with Blaze, fits those requirements perfectly. React does have it’s advantages, but not in the areas that this project needs (and I would imagine most projects unless the extremely high scale ones out there need).

Now if you are already very comfortable with React, or using React for a very large scale project, putting together a project on the enterprise level, you really need server side rendering, or simply trying to add to your credentials & make yourself a bit more valuable on the job market, then by all means go with React. Otherwise, the advantages for most projects not involving any of those aspects are somewhat questionable.

1 Like
51

Thank you for all the great discussion. My current version of the app was always meant to be a learning experience and I will need to start from scratch regardless. You now have me thinking to use Blaze instead of React. I was also considering this before which is what initially prompted my original post.

But what about comments like this, which influenced my decision to stay with React?

52

I think that these types of comments oversimplify things, to the extent that it’s easy to take them as dogmatic, especially for those new to the ecosystem.

React has momentum; nobody is going to question that. But I think that over the past two or three years in the JS world, we are seeing that there is space (and plenty of use cases) for many players in each layer, and blaze/react is a great example. There are pros and cons to each, use cases for both, etc.

I love blaze for its speed, prototyping, familiarity, and especially so when I’m working on a project alone (or with little help). In a large app with a ton of components and team members, react might be a better solution.

53

Regarding the comment, in my opinion, saying “anything” is the future is a gamble. As Sacha said above, we shouldn’t present speculations as facts.

React does have momentum. Does that mean it’s the future? We won’t have any idea until the future actually gets here. Software development moves very fast, and countless products have been thought to be the future, and weren’t. If you look at web development, often times frameworks/libraries/even languages that are arguably not so great/well received became the most popular options out there, and just look at the insane popularity of things like Wordpress - When it was in it’s first year, would anyone have suspected a blogging CMS would be used in the way it has been over the years?

Regarding JS specifically, it has so many more libraries and moves so much faster, it’s even harder to predict the future than general software development.

Even 1 year ago, if you asked the general population, Angular was still far in the lead. That would have been the suspected view layer in the stack when people were asked.

Nobody could have suspected React would have blown up like it did over the last year. Is it at its peak of popularity? Or will it still grow? Who knows. But if it stagnates now, it will end up being in a similar situation to Angular was, with a similar peak of popularity. There’s no way to tell what’s going to happen.

Also, regarding the quoted post (again)… he used the recent post as evidence of React being the focus. I think that’s a little misguided, as it talks about splitting Meteor in to more modular components on NPM. IIRC, also specifically mentioning Blaze being put in to it’s own NPM package that could be used with or without Meteor. Also specifically mentioning Apollo being one of these optional NPM packages that could be used without Meteor.

This indicates, contrary to the quoted post, that they are going with a more modular path moving forward.

With that said, I suggest weighing which view would be most useful for your project. I mentioned my reasoning above for going with Blaze and you can judge for yourself if you are in a similar situation or not. If you think React fits your needs/desires better, go for that as well. I don’t want to promote one or the other, just sharing my personal reasoning behind my choice.

The only thing I hope you don’t do is choose something because it “looks” to be future proof. That’s never been a guarantee, and would be pure speculation. Have some reasoning with a solid foundation that leads you to your choice, rather than gambling and hoping for the best. Which actually fits your project, and possibly career, better.

If you still can’t decide, there must not be any major enough factors to influence ur decision. So then spend some time with both. See which you actually enjoy using more. Because that will be the best tie breaker!

54

@Spyridon, Agreed on most (if not all) counts.

We apply a few rules when we select technology (again, OUR rules – adapt to your own):

  1. How close is it to the underlying technology (e.g. I would rather write plain JS over Coffee) - in other words, how easy is to refactor / share things? Too much abstraction is dangerous when layers fall – which layers are likely to fall (e.g. jQuery is unlikely to fall anytime soon).

  2. Who is the sponsor and what is their motivation? In fact who (actual person) is pushing it – FB pulled the plug on Parse with almost no regard to the community. Are they a good sponsor of technology? What is their motivation? I know of many technologies that came from big giants, but when the actual person (or team) moved on, it slowed down and died.

  3. What are you building and what is your coding style? We use a lot of Events in our programming and encapsulate based on actual functionality not the framework. So Mantra would not be useful for us.

  4. Finally, there has to be some technology vision. In our case, we came from the old ‘Solaris’ days and Flash, so the browser for us is no more than a Virtual Machine and we deal with it as such. So we wrap native API’s with our own code so we can swap the Virtual Machine (e.g. Atom vs. NWJS vs. ObjC vs. Java etc.)

E.g. Angular was hot one day, not so much any more, as I (personally) see it failing many tests above, so would not have used it from day one (again OUR rules from OUR experience).

1 Like
55

It seems I have to partially mince my words about AngularJS :slight_smile:

Here is the analysis of a large survey by StackOverflow about technologies: https://medium.freecodecamp.com/2-out-of-3-developers-are-self-taught-and-other-insights-from-stack-overflow-s-2016-survey-of-50-8cf0ee5d4c21#6b9b –

  • Angular is the top Views layer / framework etc.
  • And React is (currently) at the bottom of the pit of front-ends.

Of course, this is the current state, not trends. This is where experience / research comes into play to choose your framework.

1 Like