Live data from Hacker News

Angular 4.0.0 Now Available

angularjs.blogspot.com

251–260 of 360 posts

Re: Angular 4.0.0 Now Available

#251
post #183

Hmm. I see that Angular is getting aaaaalot of hate here. I really tried to understand why but have not found really valid reasons, just preferences. I have used Angular 1.x a lot and have just tried Angular 2. It really enables me (somebody who comes from primarily strong backend dev experience) to work on frontend SPA apps productively and fast. It does not 'feel' heavyweight or that it gets in my way too much, but…

Try Vue.js. It's what Angular 2 could have been, if they had taken proper advantage of ES2015 and virtual DOM. Another way of looking at it: Angular 1 and React had a baby, and they named it Vue.js. Vue has HTML templates like Angular and virtual DOM like React. It is faster than both of them. It has a smaller file size than both of them. It has a clever single file component concept that makes developing components…

[deleted]

Re: Angular 4.0.0 Now Available

#252
At some point, I will take a look at what Angular 4.0 has to offer.

My criteria to adopting a framework:

* Makes me more productive

* Allow me to ship apps / solutions better and faster

* Minimal time doing some head scratching on how to implement stuff

* Integration with other frameworks

* Uncomplicated setup and build process

* Community support (hey, we can't possibly know every inch of a framework unless we are the author)

Re: Angular 4.0.0 Now Available

#253

Earlier quoted context omitted.

Angular is a mess but typescript is alive and kicking on its own, even with react. Personally I'm one of the apparently rare breeds that hate angular but loves typescript. I wish there were more of us. They're really in different realms and please don't make them part of the same whole. Typescript is a transpiler but the transforms it does are designed to mimic accepted JavaScript idioms. When I'm debugging typescrip…

I feel like Typescript is the only thing that will stick around for sure in the coming years. Frankly, I don't know if I can say the same about all the other libraries/frameworks/etc since every month there is something new that's supposed to make all the other competing tools part of ancient history.

The best thing about Typescript is that if it dies one day you can compile down one last time to pure, human readable, JS and toss it out.

There's literally no reason to not use typescript

Re: Angular 4.0.0 Now Available

#254

Earlier quoted context omitted.

A breaking change in your dependencies is a breaking change for you. If it weren't, minor version upgrades would cause you to pull in incompatible dependencies. This is why keeping your dependency list as tiny as possible is imperative.

Wait, I'm confused. Say I'm the author of a library. Some of my dependencies had breaking changes, but they didn't affect the users of my library, as it's handled in some method. Should that be a new major version of the library?

The sensible default answer with no context is: bump your major version as well.

The more nuanced answer is that it depends on your packaging system and your language runtime. If either cannot handle more than one minor version of a dependency at the same time, you need to bump a major version. The problem is that the code that uses your library might also indirectly be using that dependency, but pinned to a different major version. This means that the application is broken even though the breaking changes aren't used by your library.

To illustrate:

   apple-1.0 => banana-1.0   => carrot-1.0
             => broccoli-1.0 => carrot-1.0
Say, as the maintainer of banana-1.0 want bug fixes in carrot-2.0, so you pull it in and bump your minor version. And then an application updates it dependencies.

   apple-1.1 => banana-1.1   => carrot-2.0
             => broccoli-1.3 => carrot-1.1
In some, though not many, systems, you can pull in two versions as if they were different libraries. But in almost all, you get a dependency conflict and apple will be broken.

Even if you can juggle two dependencies of the same library, you need to make sure there wouldn't be any logic changes that would break the system or even corrupt data (!).

Anyway, it's simpler to be conservative and bump the major version. Yes, that can be a pain. But, again, it's good to keep your dependency list small or at least very boring to keep that pain to a minimum.

Re: Angular 4.0.0 Now Available

#255
post #183

Hmm. I see that Angular is getting aaaaalot of hate here. I really tried to understand why but have not found really valid reasons, just preferences. I have used Angular 1.x a lot and have just tried Angular 2. It really enables me (somebody who comes from primarily strong backend dev experience) to work on frontend SPA apps productively and fast. It does not 'feel' heavyweight or that it gets in my way too much, but…

I started with Angular 1 and like it very much. Like you said, it enabled me to structure the code a certain way that made understanding it easier. I tried Aurelia since and moved on to React, and I have to say that while I still like Angular, not having to deal with state and mutability everywhere is a big boon to productivity. Whenever I code a component, I can simply think of the props (it's parameters) and the ou…

I would suggest trying ng2 before dismissing it over experiences with ng1. I was having huge issues with ng1 with updating scope and simillar things and then I tried ng2 first for a hobby project then a bigger collab one and if theres one thing I can say it's that Google did serious damage to the project by reusing the branding for two different frameworks for both searching/googling purpouses and by reusing branding from a framework which isn't similar and has been dismissed by many already. I hear too often how people say react is better than angular without trying ng2. It's like saying python is better than c# 1.0. Maybe it is but youre not making a fair comparison

Re: Angular 4.0.0 Now Available

#256
post #250

Earlier quoted context omitted.

Try Vue.js. It's what Angular 2 could have been, if they had taken proper advantage of ES2015 and virtual DOM. Another way of looking at it: Angular 1 and React had a baby, and they named it Vue.js. Vue has HTML templates like Angular and virtual DOM like React. It is faster than both of them. It has a smaller file size than both of them. It has a clever single file component concept that makes developing components…

Why are HTML templates a good thing? It's hands down my least favorite part of Vue.

You don't even have to know use them. You can use render functions or JSX like React.

Re: Angular 4.0.0 Now Available

#257

Earlier quoted context omitted.

I've been using Angular 2 for a medium sized application that will be going into production within the next few weeks. I'm not affiliated with the Angular team at all. I started using it when this app was very much a POC last summer, just as the Angular team was finishing up the 2.0 release. I learned firsthand last summer the issues with using a framework that was still in the oven: constant updates and some depende…

I don't particularly like TypeScript. It slows me down because of several reasons: - Compile time means that it takes more time to debug anything. - The rigid interfaces mean that I need to spend more time researching how to use various modules/libraries (maybe code completion would offset this problem but this is only possible with a heavy IDE that has intellisense or similar - Not Atom). - When I want to test somet…

> - Compile time means that it takes more time to debug anything.

how can this be an issue? even javascript needs to be concated minified and whatever to take it into production. it's not like that any human writes minified and mangled javascript with direct gzip.

P.S.: I'm not a fan of TypeScript. But to say you need to compile it, is just an excuse.

Re: Angular 4.0.0 Now Available

#258
post #222

Earlier quoted context omitted.

That's why I'd personally prefer Flow for that. It has a more elaborate type system anyway. [1] Moreover, Flow is pure annotation, which can be removed by Babel. And Flow is also backed by a large company (Facebook instead of Microsoft). However, if you do want to generate JS, use a language that elminiates runtime errors almost completely, such as Elm or OCaml (through bucklescript or js-of-ocaml). [1] The following…

Your comment neglects to mention that Typescript debugging is generally easy because one of the design goals of typescript is to produce javascript that matches what a developer would write. Debugging javascript produced by Babel is generally hell in comparison. The transforms done by Babel are not designed to be human readable and they generally aren't.

Whoops, you are right. Removed the misleading part of my comment.

Re: Angular 4.0.0 Now Available

#259
post #183

Hmm. I see that Angular is getting aaaaalot of hate here. I really tried to understand why but have not found really valid reasons, just preferences. I have used Angular 1.x a lot and have just tried Angular 2. It really enables me (somebody who comes from primarily strong backend dev experience) to work on frontend SPA apps productively and fast. It does not 'feel' heavyweight or that it gets in my way too much, but…

Try Vue.js. It's what Angular 2 could have been, if they had taken proper advantage of ES2015 and virtual DOM. Another way of looking at it: Angular 1 and React had a baby, and they named it Vue.js. Vue has HTML templates like Angular and virtual DOM like React. It is faster than both of them. It has a smaller file size than both of them. It has a clever single file component concept that makes developing components…

[deleted]

Re: Angular 4.0.0 Now Available

#260
post #250

Earlier quoted context omitted.

Try Vue.js. It's what Angular 2 could have been, if they had taken proper advantage of ES2015 and virtual DOM. Another way of looking at it: Angular 1 and React had a baby, and they named it Vue.js. Vue has HTML templates like Angular and virtual DOM like React. It is faster than both of them. It has a smaller file size than both of them. It has a clever single file component concept that makes developing components…

Why are HTML templates a good thing? It's hands down my least favorite part of Vue.

It makes integration with existing code trivial. Vue's HTML templates can be neatly integrated into pretty much anything without a struggle compared to tools that make assumptions about your build chain and what you are working with. To use Vue, you could include it with a tag and suddenly your existing HTML can be rapidly extended. Or you could get way more involved and use webpack, JSX and such if you wanted to.

To not have HTML templates means you need to do something more invasive to retrofit client-side templating into place. It's personally why I don't bother with libraries that don't offer similar, because I don't always have total control over what I am working on and I still need to get work done.

Post reply on HN