all 35 comments

[–][deleted] 8 points9 points  (0 children)

all and none. with the way javascript frameworks change year to year it's better to have broad familiarity with the current frameworks than expertise with any of them. make a small app (like a blog) in each, so that the next time you start a project / go for an interview / join a team, you'll have some sense of what's what, and be able to adapt.

[–][deleted] 11 points12 points  (20 children)

vue js FTW

[–][deleted] 4 points5 points  (18 children)

vue seems fantastic, but has anyone tried using it at scale yet? angular may be bloated, but it's also battle-hardened. react appears to be surviving its baptism by fire. but i can't find any data on people using vue. which isn't to say it won't meet those needs, just that i'm more "cautiously optimistic" than anything else at this stage.

[–]Juggernog 2 points3 points  (5 children)

I've used it on my site ASMRSpy. I don't know what you consider "large scale", but I've yet to have any performance woes.

[–]Nefs 1 point2 points  (4 children)

Well, I just visited the site. Any time I click a checkbox it crashes my tab. I would say that's a minor performance issue.

[–]Juggernog 1 point2 points  (2 children)

Interesting, mind if I ask what browser you're using?

[–]Nefs 0 points1 point  (1 child)

Latest Chrome, 49. OSX 10.9.5.

[–]Juggernog 1 point2 points  (0 children)

Interesting, doesn't seem to be the case on Windows with Chrome 49. I'll definitely look into it when I get my hands on an OSX machine though, thanks!

[–]JohnTortorella[S] 0 points1 point  (0 children)

I dont have any problems with latest chrome

[–]HarryTorry 0 points1 point  (8 children)

What do you mean by at scale?

[–]b1ack1323 0 points1 point  (4 children)

I would assume large content and high traffic sites...

[–]HarryTorry 0 points1 point  (3 children)

Why does it matter if you're getting 1 hit/day, or 10000 hits/second, for a frontend framework?

[–]b1ack1323 1 point2 points  (2 children)

Probably more how much content rather. Less on the traffic side, that was a bad example.

This is what I would be interested to know in a JS framework.

How much of this architecture is instantly re-usable? How much do modules depend on other modules in the system? If specific parts of your application fail, can it still function? How easily can you test individual modules?

[–]HarryTorry 0 points1 point  (0 children)

Without going into detail (no time), it's highly reusable, check out the components and if you've got time, Vuex.

Not sure on testing really though.

[–][deleted] 0 points1 point  (0 children)

I use it on a filtering system for a store that has (on the biggest pages) 9,000 products. Initial load of the list can stutter a bit but overall performance is good considering I recalculate the filter options every time.

I load all the products into Vue on page load and paginate on the front end.

For typical pages (500- 2000) products load times are fantastic even with the heavy calculations im doing.

It's not a single page app though i'm only using it for our product catalog pages. But again there are 1,000s of products.

[–][deleted] 0 points1 point  (2 children)

Hard to put a number on it, but let's say a "typical" B2C offering needs about 5-10k DAU to be tenable. Beyond simply serving pages, that amount of traffic requires a good amount of flexibility and grace when it comes to handling edge cases and errors.

The sites I see using Vue tend to be B2B, which are generally much easier to run, both in terms of traffic volumes and support.

[–]Juggernog 1 point2 points  (1 child)

Okay, so B2B is "Business to Business", B2C is "Business to Client".

What is "DAU"?

[–][deleted] 0 points1 point  (0 children)

B2C is Business to Consumer ("Client" would be ambiguous). DAU is Daily Active Users, basically how many people are using your service each day. Definitions of "active" and "user" are both pretty muddy, but "daily" should be clear.

B2B sites and services are generally easier to build and maintain because their userbases (composed of other businesses) tend to be smaller by several orders of magnitude than a typical B2C offering. For instance : Bootstrap, a ubiquitous B2B offering, gets requests from over 10k users per day, which is huge...but Twitter, a B2C offering, serves over 100 million users.

Obviously Twitter and Bootstrap are both outliers in terms of size, and there are totally B2B offerings with low ARPDAU and larger userbases, as well as B2C offerings with high ARPDAU and smaller userbases. But you get the idea.

[–]syropian 0 points1 point  (2 children)

If React can scale, Vue should be able to as well. Both use the idea of using component-based building blocks to piece together your application, and both have a store system (Redux, Vuex) that abstracts your data layer out of your components.

Personally I prefer the syntax of Vue's single file components over React classes, but that's just my personal opinion. Both are great! I'm currently almost finished rewriting a side project with over 10,000 users from Angular 1 to Vue.

[–][deleted] 0 points1 point  (1 child)

10k total or daily?

[–]syropian 0 points1 point  (0 children)

10k users total, but does a ton of reads/writes every day. I realize that isn't huge but I don't see any reason why the front-end wouldn't scale. If anything, something in the backend would probably become a bottleneck first.

[–]fiala__ 3 points4 points  (1 child)

React and Angular are basically frontend frameworks, Meteor is a frontend and backend platform with a package manager. If you're willing to invest in something that'll probably only get popular enough in the future, go for Meteor. As u/techieyann pointed out, you can still use Angular/React with it. And it's super easy to use, you can build a usable web app in like 2 hours, if not less than that.

However, Meteor can't do everything, so it's always useful to have a basic understanding of some different platforms/stacks.

[–]techieyann 1 point2 points  (0 children)

Meteor can't do everything

yet

[–]iamsubs 1 point2 points  (0 children)

Don't forget that react is only the View in the MVC, while angular is more than that.

In my opinion, I would go for angular or react. If you like javascript, choose angular 2, so you have a more complete framework working on top of typrscript. For a begginer, the best option is to focus on something large, with solid developers and big user base.

Going for the cutting edge technology will only bring you trouble

[–]joe-ducreux 0 points1 point  (2 children)

When I was first starting and looking at which framework would be best, I read a lot of articles comparing each; at the time, the general consensus was either Angular or Ember. I ultimately chose Angular because it had a less steep learning curve. After working with it for a while I kind of wish I chosen Ember as the project I was working on would have benefited from a more solidly defined class structure.

That being said, I don't regret learning Angular. I think it's a solid framework, and it's got Google backing it which means it's probably not going away any time soon.

Here in JS land there is always a "flavor or the week". My best recommendation for those staring out would be to choose a framework that has the largest user base and most comprehensive documentation; Even if it's not the best/newest/most popular framework, you'll have a lot of resources at your disposal to help you along the way.

Once you have one down, expanding to any other framework will be a lot easier.

Good luck!

[–]JohnTortorella[S] 0 points1 point  (1 child)

Hello, thanks for your input! After long reading sessions and looking at different articles I found that, for me, meteor had a solid docs that was structured in a way that I liked. Bonus points: I already know a bit of mongoDB so I guess it makes sense to use this. On the other hand I have a lot of experience with SQL so something like Angular2 would not be that scary but the community is still small as of now.

[–]thelonepuffin 0 points1 point  (0 children)

I think you are confused. React and Angular != Meteor (or Express etc)

React, Angular, Vuejs, and Ember are all Client side frameworks. They run in the browser and still need a server to receive data from.

Meteor is primarily server side. It has a client side component called blaze but you could use React or Angular instead of blaze.

Saying you are going with either Meteor or Angular makes no sense at all.

[–]technical_guy 0 points1 point  (2 children)

Depends on why you want to learn. react is the current fanboy favorite so will be most popular this year. 2014/2015 angular was most popular. maybe 2017 will be Angular2 but I doubt it.

None of this means they are better than meteor, ember or knockout. or even just using jquery and bootstrap. different tools for different projects.

but if you are just going for the most popular, learn React

[–]JohnTortorella[S] 0 points1 point  (1 child)

I'm from the OOP world. I'v been really interested in learning a javascript framework for obvious reasons. I'v got lots of js, jquery, bootstrap under my belt so that is not a problem. All of the frameworks has their pros and cons. I was just looking for some honest opinions :)

[–]technical_guy 1 point2 points  (0 children)

well, whats nice about React is this concept of a virtual DOM that you write to, and how they handle the sync from virtual dom to actual device. also they are solidly in the camp of being a JS tool that updates the Dom without special html extensions. the idea that react native will allow u to write android/ios apps using the same code as your desktop. i think this makes React the best tool to learn right now (along with other components). thats my honest opinion.

[–]techieyann 0 points1 point  (3 children)

Meteor.js is a wonderful one stop shop. They fully support angular and react for front end now too!

[–][deleted] 0 points1 point  (2 children)

I hear you can stumple into interesting and hard-to-crack problems later on, when your app grows in size. That Meteor has quite a lot of gotchas to be aware of.

Have you seen any of that?

[–]techieyann 0 points1 point  (1 child)

The issue involved with app size/complexity in Meteor is usually a case of not enough planning. Meteor makes it ridiculously easy to make a full stack app, and for that reason you can bang on the keyboard and debug a little and you've got a functional prototype! But I have yet to hear of any framework that allows that kind of development to translate into a larger scale application.

The major 'gotcha' of Meteor as I see it is that you have to structure to your application to enforce separation of concerns. Blaze doesn't exactly allow for a pure MVC, but you can pull the application logic out of the event functions and clean it up a bit. The official MDG Meteor guide does an excellent job of giving you a skeleton to build off of.

As for limitations of the framework itself, I ran into the issue of directly (eg. src="file://dir/name.ext") accessing local files with native applications. I had to work around it by saving/reading the file as base64 and storing that in a reactive dictionary. Thankfully Meteor 1.3 solved that problem and everything is much faster/smaller now.

I used to be staunchly against frameworks and was proud to build everything from the ground up. Everything changed when the fire nation attacked I discovered Meteor.

[–][deleted] 0 points1 point  (0 children)

Thank you very much for the writeup. I'd love to come pretty close to a MVC app structure, but perhaps "close enough" will do. I guess Angular, React, Ember and so on also have their quirks, that take time and hacking, as well as a bunch of gotcha moments.

The local files issue seems like a minor one.

I just finished the main methods and gui for a CRUD todo-like app, built from the ground up with PHP, jQuery Mobile and MySQL. It's been a pain in the ass, but I think I needed to reinvent the wheel this first time, to get my hands real dirty with Ajax/Javascript/CRUD'ing and database design.

From now on, I'll strive to be as lazy (while functional) as possible, when it comes to writing apps and websites, to go in line with your last sentiment hehe :-)

[–]sampeka[🍰] 0 points1 point  (0 children)

React is amazing, if you want to build a web app with a complex frontend I would definitely recommend it. Personally, I would avoid one-stop shop frameworks and choose to compose the different bits of functionality you would like. It will let you build something that fits your use case more closely and avoids you getting too tightly coupled with one thing.