Intro and general question

announce
9

I would like to begin with clarifying against @cloudspider’s comment and say that I definitely am not suggesting a “lesser” tool, in fact I am suggesting vue because I think it is a better tool for you for the reasons I’ve listed.

Otherwise, all these ui frameworks/libraries are, again as he said, equally powerful and offer almost the same featureset where it may be easier to do one thing with one than the other but mind you there’s no magic wand out there that’s great on all aspects.

It all boils down to experience and preference.

That brings me to my conclusion; you don’t have the experience, nor a preference (yet) for a ui framework. But looking at other people’s experience, especially people who come from mostly server side “non enterprise web” stacks (php, perl, ruby) with some templating language experience, it looks like - based on statistics - that vue is going to get you from zero to mvp much faster.

But since it is also a very powerful alternative with a very vibrant community, the odds are you are going to continue with it and reuse parts of your ui codebase for the next iteration of your product.

By the way, I prefer react for my development because I am very experienced with it and know how to both quickly build stuff and architect a future proof codebase. I also happen to believe that the corporate backing is a good thing. But these are all opinions.

Just the other day, I was discussing a similar topic with a ceo planning to rebuild their product from scratch. They wanted to use vue and are recruiting. What I said was “get react developers to build your project with vue” because a good share of people who develop and become highly productive with vue have been using vue as their first library. They might kind of lack why vue was created and in what ways it might be better/worse for a specific task etc, but the ultimate reality is, they have become productive with it in no time. That’s vue’s main focus, developer experience.

Now coming back to the “official” word. I think it is one of meteor’s main pain points in communicating what it is.

Meteor is an amazing build tool that lets you use modern standard javascript without configuration hassle to build full stack applications that contain both the server and the client parts at the same deployment target. You can in fact use any data backend or server side node library and use any frontend javascript library or framework to build your app.

It just happens that, blaze, angular and react have been documented by mdg (company behind meteor) and they have also released some tools and utilities around them, but they are so small or simple that there’s not much that differentiate those utilities from their community counterparts. In fact, that’s how angular and react entered the meteor ecosystem in the first place.

At this point, MDG’s official stance is to encourage the community to build utilities, documentation and governance around these new ui frameworks and they (imho rightfully) don’t want to maintain all of them themselves “officially” because there really is no extra value that they can provide.

As for the vue-meteor community, they are quite good in what they are doing. You’ll very soon realize that the meteor-integration is such a thin layer that you’ll even forget it is there and you’ll spend most of your time going over general vue docs, tutorials etc.

By the way, these arguments can all be repeated with the data system. I’ve advised that you stick with meteor’s built-in data system with publications and methods and mongo whereas I could have advised you to go with apollo, or something else entirely. But the reality is, the built-in data system is going to make your life so much easier, getting out of your way, solving many problems for you so that you can build your mvp. Don’t get me wrong, it will also get you up to some quite large scale, too, if you architect those building blocks correctly.

And lastly, again, stop burning rubber thinking about these, pick the tools and release the brakes. Come back and ask more questions, this time for features of your app, parts of your codebase, begin building so that we can help you build!

3 Likes
10

@serkandurusoy, thanks so much for the time you’ve spent articulating all of this! I’ve already learned a lot and, believe me, I’m making a choice and getting to work next week :slight_smile:

The crux of your suggestion to go Vue seems to be the time it will take to get to an MVP. That is very important to me, but so is getting from MVP to the next stage with minimal backtracking. If I understand correctly, you have chosen to stay with React partly because you’re very familiar with it (plus the corporate backing opinion, which I agree with). From the valuable knowledge that you are sharing, I have to assume that you’re pretty familiar with Vue also. Yet, you are choosing to use React. So, I’m inferring that you believe that, for larger projects with more developers (which is where I’m going to be in one year), the extra effort to use React is worth it. Is this a fair conclusion?

So, this gets me back to the main question that I’m not fully clear about - just how much easier is Vue to learn/use compared to React? Is it enough to outweigh the risk of backtracking and that React is backed by FaceBook? Are we talking about a development process slowing by 50%, or 5%? You’re input has been very valuable, and I’d really love to get your view on that (pun intended!)

1 Like
11

It’s a pleasure to discuss these with you because I believe there are lots of things to learn from different perspectives here.

Now my react preferences is mainly due to my react experience and the productivity edge that vue offers does not really translate to much for me. For a lot of developers who are experience with react, vue’s edge is still so tangible that they prefer to switch to it as their preferred library. But for you, that edge will probably be “the” defining quality.

Furthermore, lots of huge companies and big name products have switched to vue or adapted it for parts of their offerings. That means it is also scale-ready.

Why don’t you give them each a shot, spare a day to test vue and react by following some video-tutorials to see which one matches your stylistic preferences. The odds are, your first impression is going to stick for 80% of the things you’ll be doing on your ui codebase. And as for the remaining 20%, they would probably be equally painful with either choice. Saving some time and headache from that 80% could help you ease yourself into the problems of the 20%.

12

I’d too suggest having a look at Vue. Have to agree with everything @serkandurusoy has mentioned above. If you do decide to go the Vue route, this repo might provide some help too: https://github.com/ejfrancis/Meteor-Vue-Enterprise-Starter

Also, ‘paralysis by analysis’ is a thing. I’m sure we’ve all suffered from it. So to ease your mind a little I’d say that as long as you pick either Vue or React, you just cannot go wrong at the moment.

Above I have assumed you’re looking to target mainly the web. If you wish to target mobile platforms and do so more or less natively, then react-native is probably the best bet right now.

1 Like
13

Thanks @serkandurusoy and @vooteles for your continued input. I thought I’d give a quick update.

I’ve chosen to take a 32 hour video course that covers Meteor and React from scratch, and is aimed at someone with only basic JS knowledge. I then intend to watch a shorter course on Vue to appreciate the differences, and decide between the two. To feel comfortable with the decision, I think I need to take a look myself. I decided to start with React for two reasons. First, if it is the hardest of the two to pick up then by going in deeper I should get a feel for the reasons why, and whether it could be a barrier. Second, I took a look at available courses that fit my style of learning and I found one that seemed to be a perfect fit and which was very well reviewed. It cost around $15 as a first-time Udemy customer, but that’s money well invested for a cohesive 32-hour course vs. a number of shorter free courses (I’m sure there are plenty available, and for Vue too, but I happened to find this first and want to avoid further stalling!).

If anyone is in the same boat, I’m a few hours into this course already and highly recommend it. The tutor has structured the course well and has you do plenty of exercises along the way to help you retain the knowledge. See https://www.udemy.com/meteor-react/

I’ll try to remember to drop back into this thread and provide a final update when I’ve finished my training and compared with Vue (feel free to remind me if I forget!).

3 Likes
14

My React-Learning Journey is a rather very old post (almost 2 years) and a lot has changed and evolved since then, but it might still be relevant, especially since some of the links provided in there have been kept up to date.

I also commend you for your willingness into formally investing time into learning the “arguably” harder option, if anything you will have gained a good sense of proper architectures and code structuring which you can still translate to other frameworks and libraries.

15

Thanks @serkandurusoy. I’ll take a look and review some of the resources you list there. Redux is something I’ve already decided that I should probably look into. Which brings me back to your point on structure and architecture. I think this is important to try to get it right from the start, if you have a feel for how complex your project may get (while trying not to over-engineer it, of course). I think this could be a reason why my gut feeling is tending towards React. My project has the potential to have many add-on feature sets, released sequentially once prior feature-sets are being used commerically. Thus, modularity is important. I may be completely wrong, but React seems more structured, in which case this could enforce a better architecture from day one. Fair?

Touching on something that @vooteles mentioned, my project will also target mobile platforms eventually. This isn’t a first release requirement, but as the project grows, mobile access (for a subset of features, at least) will definitely come to the fore. Does this shift the balance further in favor of React, I wonder?

16

You should draw your own conclusions after exploring both alternatives but you’ll eventually get to see that they both offer the same feature-complete development environment and ecosystem for you, including mobile. It is just that vue developers are very vocal about how much better the development experience is. So you probably won’t have made a mistake by choosing either one in terms of technical capability. Investing first in learning react is something I encourage because you will have a better understanding of the nitty gritty of javascript ui development, that’s all.

1 Like
17

I’ve got a similar background to yours, and have been tooling around with Meteor as a possibility for some in-house apps. (Right now we’re using a motley collection of tools like Google Drive, QuickBooks and Zoho, but I’m finding it harder to manage as we grow.) Curious to know what you end up using.

I found it easier to get going Vue than React, Angular or even Blaze. The devtools and documentation for Vue are very good. Haven’t progressed beyond simple apps, but I’d be very confident selecting Vue as my view layer framework and being able to hire developers who can get up to speed with it quickly.

Good luck and let us know what you decide to do!

P.S. From your username, is it safe to assume you’re a powder hound? I’m looking at a bunch of lovely powder here on a lovely sunny winter day in Maine, but no time to go out and play in it! So tempting…

1 Like
18

Hi,

what I found best to work with is Meteor + React + Redux. When you learn React you’ve pretty much covered React Native too so it like a 2 in one and the support for both is huge.
Redux is amazing for controlling states (not to replace the Meteor data pipeline). Example: if you have a chat in your app and a user has multiple contacts, you can send a URL which can: pop up the chat on the screen, open the conversation with a particular friend and add a short message. As you go through Meteor, every time you see a Session.get/set think of it as a definition at the top layer of the app and that would be Redux. Every time you feel like you need to go up and down and sidewise with some variables, functions, that is where Redux comes into place.

If your app grows larger and you need to tap into a large DB (or more) of some client or partner… add Apollo and the Apollo client will read/write pretty much everything and … eventually in a reactive way.
Mobile interfaces with React…easy, you can control when things are being loaded, updated and you have a good support for dynamics and with Redux + some jquery you get a good grip on pretty much everything you need to move, show, shake etc

Bootstrap reached V4. You can add it as a library or as React components with some Reactstrap.

44
44680×759 132 KB

This was my experience so far.
I uploaded for you a sample of Redux log from one of my mobile projects where I have a lot of UX flows that needs to be controlled granularely.

1 Like
19

@pdrhound, I would 100% recommend Vue. Vue is WAY simpler than react and angular. The documentation is amazing. It is extremely fast. The library is only getting more popular and will have more and more support. I am transitioning from angular to vue in my app, and I couldn’t be happier. Being able to use HTML templates instead of JSX makes a HUGE difference in productivity. Vue is also smarter than react out of the box.

Vue is fast, simple, and mature (it’s on version 2 now).

Also the fact that react is backed by facebook isn’t important. For example AngularJS was backed by Google, but they stopped developing it anyways and use angular 2 now which is completely different. Vue is used by so many companies that there is no way development will stop, even if the founder quits.

1 Like
20

Thanks for all the additional feedback, everyone. I seem to be flip-flopping a bit right now on this question, which is fine, despite being little frustrating. I’ve got plenty to be getting on with before I start coding, so there’s no harm in some additional due diligence. I’m enjoying the dialog here, and that in itself is helping to validate my decision to go Meteor :slight_smile:

Here’s my current thinking. I really want to use Bootstrap for various reasons, so that’s one fixed requirement. I also really want to use Meteor. Everything else needs to fit that (partial) stack.

I’ve been taking a course on Meteor/React, and so far so good. I intend to do a short video course on Vue to appreciate the differences, but am starting to get a better feel for that already. Initial reaction - being more familiar with Javascript than HTML, the approach taken by React feels more familiar. I’m not saying that it’s best, but it may fit me better.

Here’s my current conundrum, which could sway the React/Vue decision. With Bootstrap as a fixed requirement, I’d probably end up using the react-bootstrap library with React or bootstrap-vue with Vue (I appreciate there are others, but these appear to be the leading - read better supported and tested - options). One issue here is that react-bootstrap only supports Bootstrap 3, whereas bootstrap-vue supports Bootstrap 4 (they’re working on it, but due to resources it is not expected to be available soon). Is using a 2+ year old version of Bootstrap a deal-killer? Probably not, but it’s a bit too early to say for sure and I’d hate to find out after several months of dev work. On the face of it, the improvements in v4 seem pretty cool (in particular it is lighter weight, uses Flexbox, has improved grid, and has moved from LESS to SASS). Given the choice, I’d go v4 (and just took a quick course in it).

So, the more current Boostrap library is a big plus in favor of Vue for me. On the other hand… I do envisage building a mobile app for this project, so React Native is a big plus for React. True, Alibaba is working on Weex to allow Vue to run native and that could change things here, but that’s also not ready for primetime yet.

Comparing the NPM downloads for these two Bootrap libraries:

… we see a huge difference in favor of react-boostrap (reflecting the downloads for vue vs react). So, here’s another area where the size of the ecosystem plays a significant part. I have to give credit to the developers of both libraries though for the quality of their docs.

As someone who is new to the stack (with the exception of Node.js), having a larger ecosystem in React makes me feel more comfortable in terms of quickly finding support. Especially as I then start to add further important libraries for Bootstrap, which have the same ecosystem size consideration.

I’m remaining agnostic for now, and am continuing to look more into the differences in the Bootstrap libraries (which is causing me to investigate Vue further). If anyone has feedback they could provide on using these, and with Meteor in particular, that would be super helpful!

Cheers!

21

You can evaluate reactstrap for a react bootstrap 4 library.

Bootstrap 4 has been around for a long time now and it is the way forward.

All in all, you’ll find both react and vue make it easy to get any vanilla bootstrap markup and styles and create components out o them.

Therefore, I’d suggest not to delve too much into the details. If you find that any react/vue bootstrap-4 library is actively maintained, you’ll likely to have very few problems with it. Even if the component coverage is not 100%, it should be easy for you to cover it yourself.

Nonetheless, you should also evaluate from a requirements perspective. Lots of projects just require a handful of the components actually :slight_smile:

And keep in mind:

:wink:

1 Like
22

@serkandurusoy, I saw that reactstrap is using v4, but as react-bootstrap is getting around 5x the monthly NPM downloads, I can’t help but wonder whether the community size should also play into this decision.

That said, there’s still 2x more downloads of reactstrap per month vs bootstrap-vue. So, maybe that’s the middle ground I should be seeking :smile:

I agree completely with your comment about decisions being requirements driven. Problem is that while I do have a smaller set of day-one requirements, I have larger long-term hopes for this project and want to do what I can now to increase my chances of it being the right longer-term choice.

Thank you for your encouragement and reminder to avoid further analysis paralysis also :wink:

1 Like
23

@greenmoose, it does seem that we share some common requirements. Thanks for your input. My project is also evolving out of a motley set of homegrown tools, predominately Excel-based. I evaluated Zoho but quickly hit some issues with more advanced logic and database queries. I use Zapier to interface some industry-specific apps with third-party API’s, which has actually been very successful, but won’t scale to my longer-term requirements. No existing systems can do what I want without me paying high fees for features I don’t need, and then still adding other vendor solutions on top. So, I’m taking the route of building one, first for internal use, but with an aim of turning it into a commercial venture. Necessity is the mother of invention, as they say. Hence, all the careful due diligence (and a touch of analysis paralysis!).

You are correct, I am indeed a powder hound! Lived in CO for 12 years, and skied the Rockies almost weekly. I just moved to France, 45 mins from ski resorts in the Pyrenees, but am unfortunately on the bench this season due to an injury :frowning_face: Shame, because it’s been dumping in Europe all season! So, with no powder to distract me, it was time to take the plunge and start coding…

24

@paulishca, thanks for mentioning Redux. Although I’ve never used a state management system, I have identified this as important as my project grows. I saw that in the Vue docs, they talk about Vuex being available for this purpose.

I’ve used neither, so can’t make any judgements, except to say that this seems yet another area where Vue and React have similar advantages. Good to hear about your positive experience with Redux, though. It’s definitely on my radar for the future.

25

@turbob, all good points, thanks. Good to hear that your switch to Vue is going well.

26

I spent a lot of time doing some further due diligence this weekend and have reached a decision on this. I’m going with React. Here’s why.

Building a native app is important in my longer-term strategy for my project, but I want to stick to full-stack JS. So, I did some more research into React Native and Weex. I found a recent blog post comparing the two:

which was a good summary of what I’ve read elsewhere and confirms my suspicions that Weex would just be too difficult to get going in the near future. It seems that if I want to stick to JS (with some flexibility to add some native code if necessary - though it probably won’t be for me), then React Native is the way to go.

This was a sad finding. I’d spent much of Saturday reading the Vue docs and really liking the approach, especially that I had the freedom to use JSX if I needed to. Also, the main library that supports Bootstrap (vue-bootstrap) supports Bootstrap 4, which is a big plus. If Weex was as mature and easy to use as React Native, then I’d use Vue. But, it isn’t currently, and I need to be lead by my project’s requirements so that was the deciding factor.

I’ve decided to use react-bootsrap to support Bootstrap in React (which supports Bootstrap v3), rather than reactstrap (which supports v4). I’ve concluded that the former is more stable and will give me less brain-ache, when I’ve already got a steep learning curve. At this stage, this is more important than the benefits that I’ll see with Bootstrap v4 support. They are working on it, and now that v4 is out of beta, I think that work will get more attention. By the time I really need v4, it’ll probably be supported.

Now my next question is whether to jump right in to writing my own components or to use a template such as this: https://www.creative-tim.com/product/light-bootstrap-dashboard-pro-react

Thanks to everyone for your suggestions and support on this question. I hope that others have found the exercise useful! :grinning:

2 Likes
27

Nice summary and it is great that you’re sharing here your journey as you go along.

Regarding creative tim, I’ve used their products in the past and they’re actually quite good. Their react versions are also similarly good, but the pro versions may include jquery for some of the components which means dom manipulations, which is discouraged in react-land. Furthermore, I find these dashboard templates to be including too much code and opinion, such that it might make more sense to start off from a clean codebase.

Nonetheless, you can purchase it, or get the free version, use it as a general basis to your overall layout and perhaps copy over some of its components.

So yeah, it will definitely help you but instead of building your on top of that, build your app from scratch, copying over parts of that template as you see fit.

1 Like
28

Thanks again, @serkandurusoy. Good to hear some feedback on Creative Tim. I understand your point on jquery, and will aim to avoid it. This is why I will not be using Bootstrap directly, but rather react-bootstrap. I had assumed that because this template uses react-bootstrap, it too avoids jquery. I’ll validate that before proceeding.

I agree that rigorous adherence to a template could be a step to far. There’s a balance to be struck between code reuse and developing your own code. A compromise seems the best approach, and using the free template as a learning tool could be a good start. If it seems worth it to invest in the pro version and use some of their components then I’ll do just that. It could speed up development of the MVP, but I have no doubt that as time goes on, I’d be developing more custom components.

1 Like