Angular 2.0 • Hacker News Board

Re: Angular 2.0

#71

Post by nawitus » Tue, Mar 18, 2014, 1:40 PM UTC

candybar wrote: post #61

uptown wrote: post #59

I realize this is a basic question, but how does synchronization between the client and server work with Angular? I understand the concept of data-binding once you've retrieved the data to a data-structure on the client-side, thus causing that data to update the view in the DOM, but what triggers a client-side update when your server-side data changes? Do you need to poll a REST service to check for changes? Does the…

AngularJS is not a server-side framework and therefore it is agnostic on that question. You can do it however you like and you can even create directives that keep the client model synchronized with server-side, but it doesn't come out of the box.

You should actually use a service to keep data synchronized.

Re: Angular 2.0

#72

Post by kayoone » Tue, Mar 18, 2014, 1:43 PM UTC

stuaxo wrote: post #65

jeswin wrote: post #15

AngularJS has a J2EE mindset. Where libraries grow to become as hard to learn as programming languages themselves. It does not make semantic sense to me anymore. Here is an example from the site: Length (float): {{length}} This is not a valid float number! How semantic is ng-show="form.length.$error.float? smart-float sounds like C++. If programming languages worked like this, we wouldn't have built many apps. The pr…

This is true. AngularJS is much better than what we had before, it is kind of large and monolithic. The cycle probably goes thusly: Large monolithic framework comes and shows everyone a new way of doing things (Angular/Django). People think it is too large and monolithic, so make microframeworks (Flask/Whatever comes after Angular). The next step will be a kind of happy medium.

imo AngularJS can be pretty micro and scales nicely. Its one of its major strengths, as you can use it to just build a tiny widget inside an existing page or all in and build a huge application.

Re: Angular 2.0

#73

Post by duebbert » Tue, Mar 18, 2014, 1:45 PM UTC

ap22213 wrote: post #30

All I really need are client-side templates and awesome DOM binding. What's the current best options?

http://www.rivetsjs.com/

I'm planning to use it in my next project but haven't yet. It seems to fit the bill nicely.

Re: Angular 2.0

#74

Post by Touche » Tue, Mar 18, 2014, 1:47 PM UTC

marknutter wrote: post #67

stuaxo wrote: post #65

Earlier quoted context omitted.

This is true. AngularJS is much better than what we had before, it is kind of large and monolithic. The cycle probably goes thusly: Large monolithic framework comes and shows everyone a new way of doing things (Angular/Django). People think it is too large and monolithic, so make microframeworks (Flask/Whatever comes after Angular). The next step will be a kind of happy medium.

Except that Backbone.js, a micro-framework if there ever was one, exploded in popularity long before most people had even heard of AngularJS.

Backbone was the start of the cycle. It came around at a time when front-end apps were largely jQuery soup and put polish on best practices that good JS developers were already doing. Then a lot of other frameworks were developed which largely started from the same code-first premise that Backbone had/has, and Angular "won" by introducing a new paradigm built on declarative binding.

I predict that the next winner will leverage web components and do the one thing that makes that paradigm better.

Re: Angular 2.0

#75

Post by jeswin » Tue, Mar 18, 2014, 1:48 PM UTC

marknutter wrote: post #70

jeswin wrote: post #66

Earlier quoted context omitted.

> DI enables testability, ..... the learning curve of DI doesn't justify the gains in testability Dependency Injection is a redundant, useless pattern in dynamic languages; especially when it comes to testability. In test.js: //paymentService may be an instance or a class services.paymentService = mockPaymentService; .... //use paymentService in your tests here. The above over-simplified example satisfies most test c…

With DI you can ensure you're not accessing anything that's globally defined. While you can mock out global objects and methods on global objects, it becomes far less clear what the ramifications of doing so becomes when your app becomes large and complicated. With DI, you have all the dependencies clearly defined for the function you're concerned about. Beyond testing, DI makes it much easier to swap in different im…

Your first point cannot be debated, since we are speculating. In practice, I'vent seen a problem. It works, it's clean, and it is the right amount of engineering needed to solve the problem.

Parse and Firebase example:

  //someservice.js
  ...
  //works as long as both retain the same interface.
  provider = new FirebaseProvider; //new ParseProvider()

  //add: just using an if condition, the old fashioned way.
  getProvider: function() {
    if (config.provider === 'parse')
      return ParseProvider()
    else
      return FirebaseProvider()

Why is writing configuration cleaner than doing the above? That thought process is carried over from projects with lengthy build time.

Re: Angular 2.0

#76

Post by Touche » Tue, Mar 18, 2014, 1:53 PM UTC

marknutter wrote: post #68

fiatjaf wrote: post #57

Earlier quoted context omitted.

React solves all the problems in the world with their nestable but still autonomous components approach. It dispenses controllers -- and automatically give control to the component which deserves it --, it dispenses templates, and automatically gives the power to make the entire app in modular small pieces of HTML, it dispenses models, because models are already embedded in the components in which data is rendered. R…

I'm curious what happens when you want to share models across components. In angular.js you would use services to do this, but what's the analog in React?

If you're passing it to child components you pass it through attributes. If you're passing up to parents, however, you have to create a function on the parent that will get called to accept the child's new data. This can get really messy if you have deeply nested components and need to get data from one branch to another branch.

Re: Angular 2.0

#77

Post by Touche » Tue, Mar 18, 2014, 1:55 PM UTC

donw wrote: post #48

iSnow wrote: post #23

Earlier quoted context omitted.

I only looked superficially at React, so maybe I got something wrong, but the HTML/XML intermingled with Javascript seems extremely off-putting to me, akin to ASP/JSP/PHP.

The thing that sold me on React was this statement: "Most people make the mistake that the DOM is a place you put things." The DOM is what the user sees. That's all. With React, you have a virtual DOM that can hold everything, not just what the user sees. It's a pure data structure, and can be manipulated as such. Because that DOM is a pure data structure, React can figure out for you what parts have changed, and re-…

I agree with you that React's virtual DOM is a real breakthrough. However, that doesn't make all of React worthwhile. Other frameworks can (and should) integrate a virtual DOM.

Re: Angular 2.0

#78

Post by shadowmint » Tue, Mar 18, 2014, 2:04 PM UTC

marknutter wrote: post #67

stuaxo wrote: post #65

Earlier quoted context omitted.

This is true. AngularJS is much better than what we had before, it is kind of large and monolithic. The cycle probably goes thusly: Large monolithic framework comes and shows everyone a new way of doing things (Angular/Django). People think it is too large and monolithic, so make microframeworks (Flask/Whatever comes after Angular). The next step will be a kind of happy medium.

Except that Backbone.js, a micro-framework if there ever was one, exploded in popularity long before most people had even heard of AngularJS.

Backbone doesn't do data binding; it's a completely different thing.

(That's why things like rivet and epoxy exist; because backbone doesn't do it right)

Re: Angular 2.0

#79

Post by rok3 » Tue, Mar 18, 2014, 2:04 PM UTC

marknutter wrote: post #68

fiatjaf wrote: post #57

Earlier quoted context omitted.

React solves all the problems in the world with their nestable but still autonomous components approach. It dispenses controllers -- and automatically give control to the component which deserves it --, it dispenses templates, and automatically gives the power to make the entire app in modular small pieces of HTML, it dispenses models, because models are already embedded in the components in which data is rendered. R…

I'm curious what happens when you want to share models across components. In angular.js you would use services to do this, but what's the analog in React?

React encourages you to use a parent component that controls the state and passes it down to it's children via props.

Passing data to separate components without a shared parent is outside of what React is trying to accomplish but I've handled it before by passing a Backbone model to the separate components as props.

Re: Angular 2.0

#80

Post by yoshokatana » Tue, Mar 18, 2014, 2:09 PM UTC

uptown wrote: post #62

candybar wrote: post #61

Earlier quoted context omitted.

AngularJS is not a server-side framework and therefore it is agnostic on that question. You can do it however you like and you can even create directives that keep the client model synchronized with server-side, but it doesn't come out of the box.

So if you want to poll a service periodically, you can do that ... or if you want to use a websocket and just leave a pipe open to refresh your client-side model ... you can do that too? Got it. Thanks.

Yep. The $http service in angular core basically does your standard Http stuff (with some nifty additions like caching and promises), but people have built services to do sockets, sails, handle server-side events, etc.