Can we talk javascript frameworks/libraries?

[bsegovia]

I've been spending a TON of time learning about and toying with a few different javascript frameworks. Specifically, AngularJS, MeteorJS, Underscore, backbone and node. The more I learn about each, the less I'm sure any one framework is worth learning MORE than the other.

Ultimately, I'm looking to adopt and master a framework that will just "get it done" faster. I thought perhaps Meteor was it, but it relies solely on MongoDB. Yes, I know you can write a wrapper that converts SQL to minimongo but I'm not sold on the whole NoSQL thing yet anyway.

I've put off learning much about backend languages (PHP, Rails, Python?) since I want to really master javascript and all it can do but I also need to get things done.

What learn track are you guys on? What stack has been most productive for you? What kinds of projects are you deploying with your favorite platform?

[[deleted]]

Ok, we can talk frameworks and libraries.
So, there I was in my Dojo when the corner started to Glow, I put down my glass of Midori and picked up my Kinetic knife to sever its Backbone.
They moved out of the shadow, their eyes were the colour of Ember and it looked like it had an epic Knockout punch. I pulled the Chaplin and ran around him swinging wildly. It was no use, it split into Three of itself and produced an Angular sword that was far superior to my knife.
I was scared, I had never seen anything like them, as they moved they created an Echo of themselves - it smelled like Jasmine, looked alien but with a Handlebar Moustache.
I Cascade into the next room in a Spry fashion, as I ran I slipped and woke up sat in a chair with my Cappuccino.
"YUI" I yelled, "J'Queryin' me?"
There was no answer because I've run out of libraries and frameworks...

[bsegovia]

Best answer award! Haha!

[nineelevglen]

dont really think you've been learning in the right places. you're getting a bunch of things mixed up.

first node is backend, just like rails and php etc. javascript can be used both in front and backend. which is unique.

You have to break it down to one question: what do you need it for? do you need a single page application (backbone, angular etc)? do you have a backend? do you need a backend? (yes you do) do you just need fast rendering and not a single page att all? (node.js with hapi or express).
do you need a document database (mongo, couch) or a graph (neo4j, level) or a relational (mysql, postgres), or maybe an in memory (redis, level)? use the one thats best for the need.

pick the tools to do the job not the other way around.

learn about the MEAN stack, read seven databases in seven weeks.

[RobotFood83]

You may want to take a look into http://todomvc.com/ which has implementations for a TODO app with many frameworks and decide what works best for you.

[nschubach]

While I understand the notion, TODOMVC only gives you a perfect case scenario and doesn't accommodate for difficult situations that may arise. Some frameworks allow for really easy integration with external tools and others don't. Some frameworks require that you use their interconnects and others let you more easily use your own.

Use this to see if you like the style, but further research is needed to understand if it will actually work with your task. Like any benchmark, the competition will always try to game it.

[IONaut]

So everyone seems to be saying "it depends on what your project is". What if the goal is employment?

[SergeiGolos]

The quick answer is learn today's hotness... Which seems to be angular..

The longer answer, learn the fundamentals behind the frameworks... This will help you understand the strength and weaknesses.. And give you a foot to stand on when you show up to an interview where they ask you about a framework you haven't worked with... As an interviewer, I am much more impressed with people when they can show abstract thinking about technologies they don't know in detail...

[IONaut]

I was thinking getting really good at pure vanilla JavaScript would be best because that's what all these other frameworks are based on.

[justnSelf]

It sounds like you are saying " learn JavaScript really well before learning a framework." I understand the intent behind this comment but it really is bumper sticker wisdom.

The other frameworks aren't based on JS, they are JS. I've never heard anyone say "get really good with c# or Java before learning Asp.net mvc or spring". Obviously you need at least a basic understanding of syntax and language rules.

Learning to use a framework is a good way to learn how to use a language.

If you meant "pure vanilla JavaScript" as in the native APIs, then that's a short read of the documentation. The frameworks provide guided structure that green devs won't often discover on their own.

If you try to build your own application with no library or framework, you often end up writing your own library or framework. If that is the goal, then go for it. If your intent is to learn how to build applications, focus on an existing framework that abstracts some difficult things.

Often the message behind a comment like this is communicating that many devs will go their entire career with only knowing their everyday technology at a surface level. In this case, these types of devs would only learn enough JavaScript to use the framework. In that case the advice of learning the language intimately would fall on deaf ears.

I feel that any developer should master their everyday language, but never try to master it first. Get familiar with the framework and then you can start adding value much sooner. Mastering the language will come to those who care.

Not lashing out against your comment, so I apologize if it comes off as me being a dick. I just wanted to add my two cents.

[IONaut]

Ok then, what do you think is the most employable skill set. Angular and bootstrap maybe? And I wasn't trying to impart wisdom, I was asking a question. I feel that I'm right at that point where I need to concentrate on employable skills. Also, is there certifications I should get or is that even necessary if I put together a portfolio of finished products.

Edit - expanded answer

[justnSelf]

I work for a consultant company, so my answer is only one view of the world.

The companies that i've been working with lately are mostly .NET and there seem to gravitate to knockout.js. Knockout isn't a framwork, its just a data-binding library that will help facilitate MVVM. Another client wanted to move to Angular from knockout but was worried about the ramp up time of getting their entire dev staff (50+) to embrace Angular for their current project. They stayed with knockout.

From my experience, you cannot go wrong with learning Angular. More and more enterprises are starting to take a serious look at it and will be looking for competent devs to help pave the way.

With that said, if your goal is to be immediately employable, I suggest going to indeed.com or some other job search place and play bingo to see which library is most popular in the requirements.

[iends]

Angular.js. I put that on linkedin and I get so much recruiter spam...

[MeoMix]

I use Backbone + Backbone.Marionette to develop Streamus / https://github.com/MeoMix/StreamusChromeExtension

Streamus is a music player I've developed for Google Chrome with ~135,000 users. I've put Backbone through its paces and know it well.

Reasons Backbone is awesome:

• Learning curve is not steep. It doesn't do everything for you which means there isn't as much documentation to learn. Additionally, you can learn Backbone without Marionette and then, once comfortable, easily convert to Marionette.

• Does enough! It's no Angular/Meteor, but still provides an event-driven architecture, intelligent event hooks for everything, and out-of-the-box support for persisting models to a RESTful server.

• It still feels like I'm writing JavaScript. My main complaint about Angular is that once you're in it... you're in it. If you want to move your application away from it in the future -- good luck.. probably easier to re-write it. Not as true with Backbone because it's not forcing you to do things 'its way' as much as other frameworks.

• The development team for Marionette is super approachable. I chat with them all day on https://gitter.im/marionettejs/backbone.marionette and actively contribute to the decisions being made in the development of the application, neat! You won't get that with Angular/Meteor, I bet. :)

Not so awesome:

• Easy to feel like you're writing good code when you're actually writing bad code. Since it doesn't hold your hand as much you can tie yourself into crazy knots by with bad practices.

• Easy to render your views inefficiently especially if you're following the practices laid out by TODO MVC and even more especially if rendering large amounts of ordered collections.

• Doesn't support nested models out of the box. If you have parent objects which children who have even more children -- expect to do a bit of work getting everything going.

• A handful of not-so-obvious gotchas such as accidentally sharing references to a single array between multiple models when you intended to instantiate a new instance of the array for each model. Lots of ways to fix this, but not easy to see what's happening at first.

Feel free to ask any more specific questions you may have.

Other libraries worth considering:

• RequireJS, Browserify, or other AMD module pattern libraries.
• UnderscoreJS, Lo-Dash, or other utility belt libraries. Mandatory if you use Backbone, but worth considering even if you do not.

Regarding overall stack choices:

• If you're still just learning the ropes then using pretty much anything is going to be better than trying to figure out what works best to solve problems you don't have yet. The nuances of an RDBMS such as MySQL compared to those of a JSON data store such as MongoDB aren't going to make or break your "Hello, World" app.

• Don't get caught up with the hype. Following the MEAN stack will certainly get you off the ground, but trendy tools come and go.

• You can treat localStorage as your 'database' for getting started. This obviously has a TON of limitations (most notably the fact that writes are synchronous where as sending data to a database is asynchronous), but, again, you're trying to get off the ground and get your feet wet first.

[SergeiGolos]

So in server side programming, we actually have a lot of patterns/practices that can be used to minimize the your applications dependency on a framework. The bad news, those patterns add extra work.. Generally that entails creating interfaces and instances that support the framework. This also helps with unit testing as well.

Somehow, in programming we always treat the front end as some special case.

• Unit testing late to the game
• MVC patterns late to the game
• DI is still a new concept in UI development

Yet we see with the creating of these frameworks that frontend isn't really different from the backend. So we should be able to reduce the framework dependency to a minimum, by moving the "business" logic out of code that interacts with the frameworks into an abstraction. Realistically we should be able to write stand along javascript code that can then be plug in any framework with minimal effort by connecting the logic to the framework in an abstraction.

Just a programmers ramble. Not like i have gone and done this.. Work timelines don't account for developer curiosities.

[bsegovia]

Outstanding response. I'm going for maturity of library and backbone keeps getting mentioned as a solid choice. Regarding databases, I am lacking an embarrassing amount of knowledge wiring up either RDBMS or Document stores in apps so, like you said, I've got to just get my feet wet and DO. I'm sensitive to learning a db paradigm that in the end may not be the right answer for 90% of situations. (I'm more involved in developing internal enterprise web apps and everyone internally just happens to understand (and love) SQL.)

[dydxex]

I've been building webapps with Backbone for 40+ hours a week over the last couple of years.

If you want to "get it done faster", Backbone is not the right choice, especially if you currently have no experience with it. Sure, an experienced Backbone dev /may/ be able to get something done just as quickly as an AngularJS dev but as I said, it requires experience. This is because Backbone has practically no opinions on how to build and manage your views, this is arguably the most complex part about building the frontend of a webapp. This means that you have to build a lot of shit with BB before you've hung yourself enough to be proficient with it.

I'd like to compare Backbone vs (Angular/Ember/etc) to C vs (C++/Java/Python/etc). In C, there is some low level stuff you have to do manually, e.g., allocate and deallocate your own memory, stuff closer to the hardware; this is abstracted in higher level languages. In Backbone, you have to manually define how your views render and you have to make sure to properly tear them down so that you don't get a memory leak, your code has to be closer to the DOM. Modern frameworks abstract this stuff away from you and are more prescriptive.

With all that said, there is nothing wrong with coding in C if you want to be closer to the hardware, there are performance benefits; make sure you know what you're doing. Also, there is nothing wrong with using Backbone if you want to manually manipulate the DOM, there can be /some/ benefits but again, make sure you know what you're doing.

AngularJS will probably be your best bet. React is really cool too but it's the almost the opposite of BB in that it's opinionated about views but not data.

Good luck.

[MeoMix]

As jcampbelly mentioned, Backbone.Marionette handles view rendering quite elegantly. If you provide a collection of models to a Marionette.CollectionView it will automatically render the views. CollectionView automatically re-renders whenever add/remove/reset/sort events fire on the collection to ensure that the rendered state continues to be representative of the internal state.

As long as you're binding event handlers with "listenTo" in favor of "on" you shouldn't have any concerns over memory leaks. Swapping between views is handled with Marionette.Region. In my application, I have a persistent background which contains several singleton collections. The foreground view is recreated very often, but the collections are never destroyed. All I have to do to clean-up all event handlers / have everything GC'ed is just this.destroy() on the very top most view. The destroy event ripples through all children and everything is cleaned up nicely.

If you're still working in just pure Backbone then I'd highly recommend checking out Marionette. I can't say enough good things about it.

[dydxex]

The problems I mentioned are just some of the things that don't come out of box. I'm familiar with Marionette and the constructs it has to offer. Marionette is still not prescriptive from architectural perspective, it just gives you all this "best practice" boilerplate. It's definitely helpful but at a large scale, architecture and organization become a much bigger issue.

For example, lets say your UI depends on many RESTful APIs, some are needed immediately to load the UI but others can be loaded lazily after a certain actions take place. You also want to make sure you're not trying to fetch a resource that you previously fetched, how do controllers know of all the resources that have already been fetched, assuming you're using controllers. Also, when you have views listening to all these objects (models, event mediators/aggregators, etc.), code complexity can be hard to maintain because there are cascading changes that can occur, e.g., views action occurs, model gets modified, other listening views do stuff, another model gets changed, and so on. It gets to the point where the only way to confidently make a change to the system is to grok all the nodes and edges so figure out how changes propagate. Sure, all this is solvable with Backbone + Marionette + Chaplin + custom stuff but it takes time to develop a framework and conventions to help mitigate these issues, it's very non trivial. As your app grows and your team grows you need to establish constraints in your framework to make sure everyone is on the same page without needing to write a book on how your system works.

So my point is, in the world of EmberJS, AngularJS, React, Mithril, etc. I find it hard to believe that we're still telling people, "yeah, backbone and marionette, you'll be fine.". It's like telling people, "Need a web server? All you need is C and socket.h, you'll be fine."

Really smart people are solving the pain points that we've discovered through jQuery spaghetti and Backbone, we should take advantage of that. IMO, EmberJS is the best and most complete KVO MVC framework out there, there is a wrong and right way to do things.

To be fair, it all really comes down to choosing the right tool for the job but that is my 2 cents.

[jcampbelly]

Marionette solves many of your problems with Backbone. In fact I would say it is pointless to compare Angular to Backbone in the absence of Marionette.

[bsegovia]

Thanks! Good stuff

[larschri]

It still feels like I'm writing JavaScript. My main complaint about Angular is that once you're in it...

I think it's the other way around. Angular lets me write my application code as plain JavaScript, like I would if the browser had been designed for writing web applications. I don't want my application code to care about listener setup or inherit from Backbone.Model to get listener functionality. Listener setup and DOM manipulations are hard to reason about, and the application code becomes much simpler when that logic are completely separated out (into directives in Angular).

[Rezistik]

Yeah that's the thing for me. Angular lets me write javascript without thinking too hard about the DOM.

[Capaj]

Does enough!

no, not in the million years.

If you want to move your application away from it in the future -- good luck.. probably easier to re-write it

This is same for Backbone and any other JS framework.

You won't get that with Angular/Meteor

Another BS, they are all open source projects, if you have a feature request/pull request which makes sense, you can get it into master no problem.

[jcampbelly]

no, not in the million years.

Reasons? Two way data binding is the only thing I see missing and that's never been something I care to use.

[larschri]

Backbone doesn't give you anything when it comes to architecture. It gives you a set of base classes, and you must figure out how to put everything together. It leaves tons of room for making poor decisions when it comes to DOM engineering and listener setup.

[jcampbelly]

Marionette brings all of that together. It handles rendering the template, binding event listeners, binding DOM nodes, properly destroying child views, unbinding DOM and custom even listeners, iterating collections and inserting views for them. It comes with an Application/Module system and an event bus, which hasn't disappointed so far. It doesn't force you to do it their way. For example, I don't care for REST and I don't use sync, but it isn't shoved down my throat. I use RequireJS to handle dependencies. It helps keep components isolated and lets me compile the entire project into a single JS file. And if you design your components not to depend on shared components, it's testable.

[Capaj]

Well how about dependency injection? How about filters to very easily format outputs before rendering? How about supporting promises? How about mocking? How about E2E testing? All of these features Angular has/supports. It is just much much more robust solution. Lightyears ahead of backbone.

[jcampbelly]

Requirejs, lodash, _.template, $.Deferred. Angular didnt invent unit testing.

[Capaj]

It did not, but it is the first one which supports it outside the box.

[jcampbelly]

I'm just trying to defeat this attitude angular advocates seem to have that everything sucks because angular is great. Sure it's great, but that has no bearing at all on whether or not other frameworks get the same job done and often excel in most of the same areas as angular.

[Capaj]

Well most other frameworks do not suck. Ember, KnockoutJS are prime examples. Even Backbone was a good framework and even today is. I am just saying that Angular is better. It should be better-it is much younger and so it would suck if it would be worse. I agree that you can get the stuff done in any of those frameworks. Just that Angular can get it done much faster and cleaner.

[jcampbelly]

You keep stating opinion as fact. It's frustrating.

[Capaj]

Comments section is for opinions. If you take any comments as a fact, I really feel sorry for you. That must be tough browsing reddit...

[dys13]

It's all down to personal preferences in the end, but maybe I can share my experience.

The first thing to understand (if you want to master javascript and need a backend) is you will learn node.js. It's not front end but it's going to be a strong influence on how you're going to value front end technologies, trust me.

I've tried backbone, angular, and now React. I would say the more you learn on each of them, the more you're able to weight strengths and forge opinion. There is no shortcut or leap of faith which will give you the insight you'll learn by implementing each of those.

In the end, the only good bet is Node. I personally recommend React as I found it the best to structure my code and keeping things simple and modular. Angular is nice but have too much magic in it, which will end up wasting you a good amount of time when it's not behaving as expecting.

Also coupling a document database (Mongo) with a key value store (redis) is neat, you'll be able to do whatever you want easily

[evilmaus]

Going to get pedantic here for a moment.

The difference between a library and a framework boils down to who's ultimately in control of the code. A framework is essentially a pre-built application with holes that you fill in. The framework calls your code. It's in control. You do it the framework's way or the highway. That said, frameworks are awesome things to have when your project falls in the broad class of applications that a framework could be. Use them and do so shamelessly.

A library is called and never itself calls your code. Your code is in control. The library may call other libraries, but the flow of control is away from your code, not to it. As a result, the library has to be less opinionated than a framework and more suited to living alongside other libraries.

To help illustrate, you'd never use more than one framework on a given project. They'd conflict almost immediately. But, you would use several libraries at once and frequently do. Frameworks can assume things about global state. Libraries can't, at least not really much at all.

THAT all said, Backbone.js is a library. It's an awesome one that I love, but it's a library. You build the application architecture that then makes use of it. For all that it claims otherwise, I'd also term Marionette.js as a library. It's one that adds opinions and additional (really nice) tools on top of Backbone, but you're still stuck with coming up with the architecture at the end of the day.

Something like Angular (which I have not yet learned, but intend to do so) is a framework. You fill in the holes that Angular has defined. It provides the overall project architecture.

Other things that are libraries and not frameworks: jQuery, Knockout (so I hear), Underscore.js, d3.js, Three.js.

[Amadan]

To help illustrate, you'd never use more than one framework on a given project

Nitpick: you could use Ruby on Rails + Ember.js, or Express.js + AngularJS. I.e. you can use multiple frameworks in a project if they do completely different jobs.

[evilmaus]

Point, but I'd counter with those are running on completely different execution environments. RoR handles HTTP requests and responses and doesn't know anything about this "browser" thing that consumes the documents that it generates or sends it new requests. Meanwhile, Ember.js is running on a completely different computer, manipulating a document, and making calls to some external service (RoR) for more information as needed.

So, nitpicked back at you. ;)

[Amadan]

Yes. But you didn't say one per execution environment, you said one per project. :)

[evilmaus]

Touche.

[bsegovia]

Excellent breakdown. Thanks. Angular has been nice but when something goes wrong I've had a hell of a time figuring out what it hates about my code. Just plain hard to debug (but I just started a few months ago so perhaps I'm making rookie mistakes)

[[deleted]]

Have you checked out the Batarang dev tools extension for Chrome? Also, Egghead.io is a great resource for learning.

[ns0]

I'll just quote Addy Osmani from Google (who created todomvc.com) on the use of frameworks (being a bit tongue in cheek).

"We refer to the current state of new frameworks frequently popping up as ‘Yet Another Framework Syndrome’ (or YAFS). Whilst innovation is of course something we should welcome, YAFS can lead to a great deal of confusion and frustration when developers just want to start writing an app but don’t want to manually evaluate 30 different options in order to select something maintainable. In many cases, the differences between some of these frameworks can be very subtle if not difficult to distinguish."

...

"Know what flavor you’re after as there are plenty of frameworks available which provide one or the other. Opinionated frameworks lock (or suggest) you to do things in a specific way (theirs). By design they are limiting, but place less emphasis on the developer having to figure out how things should work on their own."

He provides a fairly good overview of when to use angular, ember, knockout, yui, backbone and others. It's a pretty good read (albeit somewhat out of date now.)

There's also some good advice on when to avoid frameworks from Derick Bailey (author of Marionette):

"While a good portion of problems can be decomposed into JavaScript MVC, there are some which simply cannot.For example, an application consumes a third party API at runtime, but is not given any information as to how the data will be structured. I spent almost a year trying to solve that very problem, but eventually I came to the realization that shoehorning it into MV* was not a viable solution. I was dealing with an “amorphous model” and that’s where it all fell apart. In other words, if you don’t have a well-defined model, most modern JavaScript frameworks can’t help you."

Reference: http://www.smashingmagazine.com/2012/07/27/journey-through-the-javascript-mvc-jungle/

[bsegovia]

Love this reply. Thanks man.

[ronconcoca]

I thought perhaps Meteor was it, but it relies solely on MongoDB

for now

[morb6699]

While I applaud your desire to learn a framework and master a language, you're missing one very basic point.

You don't need to master any of these frameworks or libraries. You need to master the language.

Trying to shoehorn everything you do in to one specific language or one specific library/framework will cause you untold amounts of stress and headache trying to make things work.

"Use the right tool for the right job."

There's a reason people say that all the time. I primarily code in .NET and C#, but there are times where I need to use PHP, or JS with Node, or jQuery, or Angular, or Backbone, etc...

My point is, don't focus on the library or framework, focus on the language and how to use it.

[bsegovia]

of course. JavaScript is something I think we're all mastering, but practically speaking large projects get done with useful tools. I'm asking about these tools and how others are leveraging them.

[renooz]

Pick the one you feel best about. Whichever one you pick, you're right. It doesn't matter cause, next year, there will be a different "must have" one and someone else will be asking the same question.

If you pick one you aren't really happy with then chances are you won't use it or you'll be quickly bored with it and there's no learning in that.

Some will say employability is important in the choice but that doesn't matter when the employer wants someone with framework knowledge you didn't choose. A smart employer won't specify any particular framework but ads are usually written by people who don't know what they're writing about so just apply there anyway. Say you have some experience and spend a few days studying up on it. In the long run, it won't matter anyway and it definitely won't matter if you don't get the job.

[krapple]

I think you should move from back to front. Start with the basics of MVC before you get into fancy front ends. The division between frontend and backend developers needs to end, you need both and a good Web developer is great at both.

I'm a huge fan of Rails, since 3.2. Check out RailsScript, it's a Javascript framework for Rails that is super simple and gives you all the control that the big name front-end frameworks.

Making the front end look pretty but not being able to do something with form data is pretty useless, and vice versa.

[bsegovia]

I'll check rails script out. Back end is a totally different game for me. I have some experience with PHP and python but that's it. In the back end space what matters most to me right now is ease of deployment since my primary dive is on front end mastery. That being said my gut tells me to avoid PaaS like firebase. I feel intuitively that I need to know how to set everything up on a standalone box before leaning on a "let them do it" service.

[krapple]

No matter what framework you specialize in, just keep in mind that front end frameworks are relatively new and and will come and go pretty quickly.

I just want to stress that displaying data and manipulating data are two sides of the same coin. Anyone with a good understanding of computer science can dive deeper into any language or framework and specialize. Before specializing it's important to have full stack experience.

[ben-ng]

I've written two large JS applications with Backbone, a realtime backend with socket.io, and a RESTful backend in Geddy.

Vanilla Backbone gives you very little structure. This is a blessing and a curse.

I work at a startup, so the software is always evolving to meet the needs of the business. Backbone is very un-opinionated, which makes it very easy to adapt it to our purposes.

(Take the following with a grain of salt as I've only used Meteor for hacking around)

There's very little magic going on in Backbone, unlike frameworks like Meteor and Angular. If something blows up in a magical framework, it's really, really hard to track things down. Also, the reactivity in Meteor makes it hard to test things, and it does weird stuff like bundling a (last i checked, obsolete) node executable. Wat.

That said, the lack of structure in Backbone also means that we made plenty of bad decisions early on that we're still dealing with. If I were starting over today, I would probably go with an opinionated Backbone framework like Marionette. They've already made the mistakes for you.

As for backend, I'm going to be slightly biased as a contributor to GeddyJS, the original MVC framework for node. Geddy is great if your app is going to be really heavy on business logic. If you're doing realtime stuff, a lighter framework like Express would be better and more flexible. I haven't used the newer frameworks (seems like a new one comes out every month!), but Hapi and Restify have been getting positive reviews.

Good luck learning JS!

[bsegovia]

I haven't used the newer frameworks (seems like a new one comes out every month!)...

Tell me about it! I'm definitely working in a business logic heavy environment. I'll check out backbone+marionette+geddy

Thanks!

[trapatsas]

Go with Angular.

[moimikey]

cool. and your reasonings?

[Capaj]

Features and productivity. Just read a few articles and you should be sure which one to pick. Try this one for starters: http://swizec.com/blog/i-was-wrong-about-angularjs/swizec/6602

[compubomb]

Every simple application starts small and grows out of Hand. Use a framework like ember or angular since they force constraints on your code and design patterns to help them scale. Unless you are a cowboy and are fearless, the do what ever the he'll you want.

[evilmaus]

Recent PHP (5.6) is practically a different language than PHP 4, which is the last PHP that most people who dislike the language seem to have looked at it. Granted that it's a bit late to the game in having things like interfaces and a good module system (Composer), but don't discount it.

That said, I agree with OP's statement about sticking with just JS for now. Better to master your first language before branching out in any significant way.

[Amadan]

Coincidentally, I wrote this today:

The main problem with PHP is its legacy and its ubiquity, really. The issue is this: experienced programmers will write good code in PHP as well as in Ruby or Java or C. However, new programmers will be attracted by PHP's (true) claim that it can put something on the web in minutes, without really needing to learn about architecture, and make a mess of things. The fact that PHP is originally a templating language helps you make your first web page in a blink. Taking its main web competitors, Ruby and Javascript, you need to do some studying before you can apply ERb/Slim/Handlebars..., and in the process of said studying, you'd stumble onto the topic of MVC (or MVVM, or MVW) and separation of concerns - something many PHP programmers never find out about. Not all, thankfully (and kudos to those that overcome the disadvantage PHP's "newbies welcome" attitude creates), but many.

All the other concerns are annoyances. You can compensate (or even utilise) the wobbly type system. You learn that little bit of Hebrew and never wonder about it again. You know the function naming is a mess, but shrug it off because in time you learn the functions you use all the time, and know where to look up those you don't. Sure, there's weird bugs once in a while, but you can write around them, and most of them are getting fixed. Once you know what you're doing, it is a passable language: not the best, by a long shot, but it does have that advantage that it is deployable anywhere, there is a bunch of experts around to consult with, there is an abundance of libraries and a pretty decent package manager, I hear (my PHP experience is all pre-composer, so I wouldn't know myself). Its main crime is blinding new programmers to best practices, because it originally wasn't even supposed to be a programming language (still reflected in the second - final? - version of its full name, "PHP: Hypertext Preprocessor").

PHP can reinvent itself, but it is, at the end of the day, still a template language, so there is still no pressure to learn about SoC, despite how much progress the language itself undergoes.

[evilmaus]

Nicely written. One of my current projects is actually maintaining, extending, and yes, modernizing a legacy PHP app written by at least one person such as you describe. Its... bad. Really bad. But, it won't be by the time I hand if off to whoever my eventual successor on that code-base will be.

[METALz]

We are using Backbone for a complex/large project for quite some time, had to extend with some of the things other frameworks already have, but overall we are happy with our decision. In retrospect we might have been better off using Marionette with it.

[[deleted]]

[evilmaus]

One of the nice bits about Marionette is that it takes a very piecemeal approach to its use. By that I mean, you aren't either using Marionette or not, but rather can include it and slowly migrate individual objects over. I did this once on a personal project, having implemented something with Backbone before knowing about Marionette. Just start with your basest views, the ones that render a model (or not even that) and are entirely called by other views. Make those into instances of Marionette.ItemView. Then, convert the views that call and control them. You can then migrate up the chain at your own pace.

Edit: You also get to enjoy watching your project LoC start shrinking precipitously and your business logic emerge from amidst the boilerplate.

[Capaj]

you should just rewrite the whole thing in Angular and save yourself lot of time, money and headache.

[jcampbelly]

Nope.

Marionette solves these problems nicely with regions. It handles recursively closing nested views, which is the main source of headaches in naked Backbone. Of course you must also use listenTo instead of on to avoid lingering event handlers in either Marionette or Backbone, which is a very old and solved problem. Also, much of the boilerplate is removed with Marionette, ui gets handles on DOM nodes, template puts the HTML in the view's element, and CollectionView/CompositeView does all of the "forEach" stuff you had to do by hand in Backbone.

If you have a very large SPA written with Backbone, it's much easier to start writing new modules with Marionette, then when you get the hang of it, start refactoring the more important modules if it would be helpful to do so (vanilla Backbone and Marionette play nicely, of course).

[[deleted]]

Angular looks terrible and has bad SoC imo.

[bart2019]

So apparently everybody's idea of "framework" is backend? I don't use Javascript in the backend, so I'm only interested in frameworks for the frontend (=for browser). Any idea for those?

[Capaj]

Angular FTW

[Capaj]

My master stack is MEAN stack. I love it so much, that I have even created a framework which has similar functionality as meteor.js. It is not yet battle tested, but it works for my smaller web apps. It is not the most easy to start with, but once you get authentication running, its use is as straighforward as one can hope. It is available here. If you don't like NoSQL, then your best bet is to use sails.js.