an skeleton posted:

I have a question. I'm a novice developer (been seriously developing for about a year or so) and I am finally feeling pretty proficient in AngularJS (I still kinda suck at creating directives from scratch but whatever). I kind of have the itch to learn a new JavaScript framework, I was thinking Backbone or Ember. However, I have 2 questions.

1) Is there a real plus to learning to different frameworks or should I just keep at one and if I ever have a serious need for the other, switch over?

2) What would you use Backbone for that you wouldn't use Angular for? Like is there a specific type of application that just screams Backbone? (ditto for Ember, I guess)

Of course the real answer to my question 1 is "just do it and find out you dickhead, you're still a newb" but I'd rather listen to internet strangers' theories. Thanks!

an skeleton posted:

Lumpy posted:

I second Thermopyle's recommendation to look at React. For fun, learn Ampersand (https://ampersandjs.com) as well. It's a different take on Backbone, and looks pretty interesting.

Thermopyle posted:

It kinda depends on your goal.

If you're wanting to expand your ways of thinking about the problems we encounter, I'd recommend learning React. Particularly because it's got a small API and you can read all the docs in one sitting, so it's not like you're devoting a big chunk of your life to it.

Really, the more you learn, the more tools you have to solve problems you encounter. They're all good to be familiar with.

caiman posted:

This is less a "newbie" question and more a "I have no idea what this poo poo is" question. How does the database fit into this whole front-end framework thing? All the overviews I read about AngularJS (for instance) keep mentionaing JSON files. But where does, say, a mysql database fit into the picture? Do these frameworks function in lieu of a traditional relational database? Or is getting the database formatted into JSON data just one of the back-end steps required for these frameworks?

caiman posted:

This is less a "newbie" question and more a "I have no idea what this poo poo is" question. How does the database fit into this whole front-end framework thing? All the overviews I read about AngularJS (for instance) keep mentionaing JSON files. But where does, say, a mysql database fit into the picture? Do these frameworks function in lieu of a traditional relational database? Or is getting the database formatted into JSON data just one of the back-end steps required for these frameworks?

quote:

Or is getting the database formatted into JSON data just one of the back-end steps required for these frameworks?

caiman posted:

So are CRUD operations common in an average Angular application? Or is that not what it's intended for?

NovemberMike posted:

One big thing to remember is that most Single Page Applications (React, Angular, whatever) will still have a backend somewhere. That backend won't be fully featured usually but it's still where you go if you want some user data or whatever.

caiman posted:

So are CRUD operations common in an average Angular application? Or is that not what it's intended for?

caiman posted:

So are CRUD operations common in an average Angular application? Or is that not what it's intended for?

Tres Burritos posted:

I just started using Angular for a project, and while it is pretty neat from a whiz-bang databinding perspective, I gotta say it's bloated as gently caress. The amount of loving garbage that you have to deal with is sort of ridiculous.

shodanjr_gr posted:

What do you mean? The only garbage that I've found is the relatively verbose boilerplate for setting up new directives...overall it absolutely blows my mind how much angular accomplishes with just a few lines of code...

glompix posted:

With a NoSQL database like Mongo the idea is that your JSON document is your datarow and your primary key is a GUID.

Misogynist posted:

The backend will be completely full-featured, it just won't render full HTML pages whenever you click a button. It's more helpful to think of the difference in the interaction model being at the client end, not the server end. The server can still do whatever it wants.

Pollyanna posted:

...that you see. For basic stuff and CRUD, it's pretty simple, but if you want anything more complicated than that, then you have to create your own directives, which means you then have to read up on how Angular expects you to program modules and organize your project, and then that means you've touched the surface of the documentation and you figure "hey this can't be that bad" and no it is that bad it is really that bad.

Backbone might take more typing overall, but I found that I actually knew what the gently caress was going on when I used it. Unlike in Angular. Also, gently caress compiling

sim posted:

[*] two-way data binding is slow, makes data flow complex, and has hard limits (2k watchers)

quote:

[*] string based dependency injection breaks on minification

quote:

[*] errors in templates don't fire, which might be ok except...
[*] logic is in your HTML

quote:

[*] scope inheritance is complicated
[*] directive methods are complicated
[*] terrible documentation

NovemberMike posted:

I meant not fully featured in the MVC sense. When you have a single page application you stop needing the templating and everything that the View layer has, so you end up with a very simplified system. The bulk of what you care about is in the model and the controller simply does routing and possibly some transformations. There are even frameworks now that focus on acting as RESTful interfaces and are simplified/specialized compared to fully featured frameworks.

pigdog posted:

Which is why every Angular guide and official documentation strongly encourages using array syntax which doesn't break.

Misogynist posted:

It depends?

I mean, that's totally true of small apps and internal things where you don't need search engine visibility. But for decent performance on apps of reasonable complexity, and for SEO, you're still going to be doing a good amount of server-side rendering. Here's a piece from Twitter on why they moved back to server-side rendering and progressively enhancing the content experience on the client side:

https://blog.twitter.com/2012/improving-performance-on-twittercom

sim posted:

I agree that Angular has major problems. I just started developing with it a couple months ago, before that I used Backbone, Knockout, or just plain old JavaScript for many years. Here's a great article that references many of the problems: https://medium.com/@mnemon1ck/why-you-should-not-use-angularjs-1df5ddf6fc99

Basically:

• two-way data binding is slow, makes data flow complex, and has hard limits (2k watchers)
  
• string based dependency injection breaks on minification
  
• errors in templates don't fire, which might be ok except...
  
• logic is in your HTML
  
• scope inheritance is complicated
  
• directive methods are complicated
  
• terrible documentation

There's also this article: http://www.fse.guru/2-years-with-angular, which talks about similar but different issues with Angular. The author only recommends it for prototypes, or very basic CRUD applications.

HaB posted:

The guy who spent 2 years on Angular has a few valid complaints, but I'm guessing two years with ANY library would result in an equal number. Angular is not the end-all, be-all - neither is any other library. We looked at a lot of frameworks before doing the project we started a year ago at work, and Angular / Ionic turned out to be the best tool for our specific situation. Would I recommend it for another project? Maybe? Depends on the project. Like it always should.

Wheany posted:

But for the InfoWindow, I need a HTML text.

bartkusa posted:

I don't work with Google Maps, but I would be surprised if Google didn't let you pass in a DOM node, instead of an HTML string.

Wheany posted:

Ember question:

I want to show an InfoWindow when a user clicks a Google map marker.

I have a class for the map markers, they seem to work fine, their positions and visibility and all that update automatically when the underlying Ember-object changes.

But for the InfoWindow, I need a HTML text. Apparently there isn't a way to render a template file to string, then set that as the contentString of the InfoWindow. You can call Ember.Handlebars.compile to compile a template, but you need a template string for that.

Now I can just supply it with a template in JS code, but that kind of defeats the point of having template files.

Can I render a template file to a string and if so, how?

HaB posted:

As a semi-aside: I have never understood evangelizing for or against ANY library/language/framework. It has always struck me as the weirdest possible place for dogma to appear. If it doesn't do what you want it to do, then use something else? If there isn't anything which does exactly what you want it to do, either write it, or re-think your design. Thankfully this thread has been mostly free from this idea, but it's always weird to see someone writing an article which describes them doing the programming equivalent of holding a hammer and complaining that the hammer sucks because everything isn't a nail.

SuicideSnowman posted:

https://docs.angularjs.org/guide/directive

Read the section titled: Isolating the Scope of a Directive

You can pass an object to a directive with an attribute:

code:

<my-directive users="userProfiles"></my-directive>

Then in the directive:

code:

return {
    scope: { users: '=' }
}

Then you should be able to access the userProfiles in the directive via 'users' just like you would access userProfiles in app controller.

Sedro posted:

You can bind a view's template name to a property on your controller/model.

Here's a jsbin I threw together.

Wheany posted:

I'm just going to steal all the codes. Thank you.

TildeATH posted:

So I finally jumped into MVC and built a small app with Ember and Ember-CLI but, I don't know, it just seems too over engineered to me. I don't work on a big team, and for some reason I don't like the jQuery dependency and so I'm going to play around with React, which looks interesting. I'm a little leery of JSX, though, and prefer writing out the vanilla JavaScript. Does that make sense?

TildeATH posted:

I'm a little leery of JSX, though, and prefer writing out the vanilla JavaScript. Does that make sense?

TildeATH posted:

So I finally jumped into MVC and built a small app with Ember and Ember-CLI but, I don't know, it just seems too over engineered to me. I don't work on a big team, and for some reason I don't like the jQuery dependency and so I'm going to play around with React, which looks interesting. I'm a little leery of JSX, though, and prefer writing out the vanilla JavaScript. Does that make sense?

quote:

Once we move over to HTMLBars, the interaction between Ember.js and the DOM gets smaller. We can probably treat jQuery as an optional dependency and only use it if it is available via globals or as an AMD module. We just want to make sure that we remove components/views using jQuery if its available so that jQuery UI widgets that have stored data in the DOM via jQuery.data() get cleaned up appropriately.