Angular 4.0.0 Now Available(angularjs.blogspot.com)
angularjs.blogspot.com
Angular 4.0.0 Now Available
http://angularjs.blogspot.com/2017/03/angular-400-now-available.html
358 comments
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 dependency changes. That was no fun for some time.
But I'll say now that it was worth it. (Maybe I should have started a little later, post-2.0 release). But I'm now building out a decent sized and complex application much faster than I'd ever done before.
It is strongly typed, it is modular, and it has dependency injection. Oh and it's strongly typed. I can't emphasize the importance of this enough. I know you can use typescript without Angular, but that the Angular community and the docs are all in typescript make this a typescript-native framework.
I'll never look at JavaScript again if I don't have to. You and your IDE and the rest of your team can know an object's Type without having to scrounge around, it's such a blissful departure from JavaScript.
It definitely has a learning curve. If you're spinning up a simple web app it may or may not be for you. (...though now I use it to spin up simple web apps because I'm used to it and it's so good for that) But for anything complex that is being worked on across a team, I recommend you take the time to learn it.
It's not perfect, nothing is. But it is leagues ahead of any framework I've used on the front end. And having gone to Typescript, I will never use a native JavaScript framework again.
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 dependency changes. That was no fun for some time.
But I'll say now that it was worth it. (Maybe I should have started a little later, post-2.0 release). But I'm now building out a decent sized and complex application much faster than I'd ever done before.
It is strongly typed, it is modular, and it has dependency injection. Oh and it's strongly typed. I can't emphasize the importance of this enough. I know you can use typescript without Angular, but that the Angular community and the docs are all in typescript make this a typescript-native framework.
I'll never look at JavaScript again if I don't have to. You and your IDE and the rest of your team can know an object's Type without having to scrounge around, it's such a blissful departure from JavaScript.
It definitely has a learning curve. If you're spinning up a simple web app it may or may not be for you. (...though now I use it to spin up simple web apps because I'm used to it and it's so good for that) But for anything complex that is being worked on across a team, I recommend you take the time to learn it.
It's not perfect, nothing is. But it is leagues ahead of any framework I've used on the front end. And having gone to Typescript, I will never use a native JavaScript framework again.
What's been your experience with browser-side debugging? The one thing that scares me about typescript is you end up debugging something you didn't write.
Yes, good question.
I use VS Code (with the Chrome debugger plugin) and that works like a charm. I don't debug javascript in the browser anymore.
TS provides source mappings to map the compiled javascript back to the source (similar to a .dll's .pdb maybe?).
It took me some time to set up the config file which proved to be a headache (because webpack was screwing with the source maps), but again once that was set up it has been a breeze to debug right in my IDE whenever I want.
I use VS Code (with the Chrome debugger plugin) and that works like a charm. I don't debug javascript in the browser anymore.
TS provides source mappings to map the compiled javascript back to the source (similar to a .dll's .pdb maybe?).
It took me some time to set up the config file which proved to be a headache (because webpack was screwing with the source maps), but again once that was set up it has been a breeze to debug right in my IDE whenever I want.
Odd, I'm new to vscode, but I tried to set up this plugin and it was completely unusable to me.
Perhaps you can describe the steps you followed? I tried installing the plugin and launching chrome with the debug flag, then setting a breakpoint in vscode. Is there something I am missing there?
Perhaps you can describe the steps you followed? I tried installing the plugin and launching chrome with the debug flag, then setting a breakpoint in vscode. Is there something I am missing there?
That's been my experience too. Also once angular-cli seems more stable, I will probably switch to it and delete webpack (I know angular-cli uses webpack behind-the-scene, but at least I don't have to deal with it directly)
You can tell the Typescript compiler to generate source maps that allow you to debug your Typescript code in the browser with a single configuration item in tsconfig.json. Chrome (and maybe Firefox?) will download them by default when you open up the debugger.
By default angular-cli produces source maps in dev mode. These work transparently when viewing source and using breakpoints in Chrome, Firefox, Safari, Opera. Just install @angular/cli create a project and a few components and check it out: https://github.com/angular/angular-cli
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 presentation contains some scary examples of incorrect code not rejected by Typescript. I'd rather prefer Flow which errs on beeing too strict: https://djcordhose.github.io/flow-vs-typescript/elm-flow-typ...
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 presentation contains some scary examples of incorrect code not rejected by Typescript. I'd rather prefer Flow which errs on beeing too strict: https://djcordhose.github.io/flow-vs-typescript/elm-flow-typ...
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.
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.
>And Flow is also backed by a large company (Facebook instead of Microsoft).
Only Facebook doesn't care much to back or promote Flow, besides the occasional blog post, whereas Microsoft has created a whole IDE / VS Code support for it, great tooling, documentation, etc.
Only Facebook doesn't care much to back or promote Flow, besides the occasional blog post, whereas Microsoft has created a whole IDE / VS Code support for it, great tooling, documentation, etc.
[deleted]
At least in Chrome it'll pick up the mappings and let you directly debug the typescript you wrote. Worst case the javascript isn't nearly as gnarly as you'd think.
But then you need to be good at Typescript, React, AND Javascript to build a feature. And that's not even considering databases, server middle ware, etc.
Great question. This is a cause for concern for me as well.
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 something quickly, I often get annoying compile-time errors along the lines of 'code is unreachable...' among others.
- It requires more planning to do anything (since you have to design the interfaces before you can start to implement). This is also not good if you just want to try something quickly and then roll back later.
- Changes to one class/interface tend to have a large cascading effect on other classes/interfaces so it takes more time to make changes to code - This happens with JS too but to a much lesser extent.
- Adds lots of unnecessary dependencies to my project.
- Complicates setup and DevOps tasks, Dockerizing, (E.g. due to version mismatches and thousands of other potential issues) etc...
The reason why I don't like heavy IDEs is because:
- They're slow and clunky (sometimes they freeze for a long time in order to index content)
- The use up a ton of memory.
- They make your team lazy when it comes to structuring your source code into proper folders (since you start to rely more on search features of the IDE to find things).
- They take ages to install.
- Support fewer operating systems.
- Are usually proprietary and difficult to customize.
- More prone to bugs.
- 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 something quickly, I often get annoying compile-time errors along the lines of 'code is unreachable...' among others.
- It requires more planning to do anything (since you have to design the interfaces before you can start to implement). This is also not good if you just want to try something quickly and then roll back later.
- Changes to one class/interface tend to have a large cascading effect on other classes/interfaces so it takes more time to make changes to code - This happens with JS too but to a much lesser extent.
- Adds lots of unnecessary dependencies to my project.
- Complicates setup and DevOps tasks, Dockerizing, (E.g. due to version mismatches and thousands of other potential issues) etc...
The reason why I don't like heavy IDEs is because:
- They're slow and clunky (sometimes they freeze for a long time in order to index content)
- The use up a ton of memory.
- They make your team lazy when it comes to structuring your source code into proper folders (since you start to rely more on search features of the IDE to find things).
- They take ages to install.
- Support fewer operating systems.
- Are usually proprietary and difficult to customize.
- More prone to bugs.
Your complaints against "heavy" IDE's don't make sense. All of the points you made either aren't valid or don't matter.
- They're slow and clunky Not anything I've used. Eclipse and Visual Studio run nice and smooth on a decent machine.
- The use up a ton of memory. Who cares. Slack and anything based on electron uses hundreds of megabytes. Chrome regularly uses gigs. Most of the IDE's I use take less than 500 megabytes of ram, even phones have plenty.
- They make your team lazy when it comes to structuring your source code into proper folders Absolutely not. Your reasoning is that making things easier = making code worse. The IDE you use has nothing to do with your dev culture
- They take ages to install. Some of them do, notably Visual Studio. All the other ones I've used just take a few minutes. Also, who cares??? You only have to install it once, what is 5 minutes for an app you're going to use for thousands of hours???
- Support fewer operating systems. No. IDE's based on java run on almost anything. Again I think you're speaking from the experience of using visual studio.
- Are usually proprietary and difficult to customize. Also no. Every IDE I've used supports plugins and an unholy amount of configuration options. Every IDE I use is open source, again except visual studio.
- More prone to bugs. What? Why? How?
- They're slow and clunky Not anything I've used. Eclipse and Visual Studio run nice and smooth on a decent machine.
- The use up a ton of memory. Who cares. Slack and anything based on electron uses hundreds of megabytes. Chrome regularly uses gigs. Most of the IDE's I use take less than 500 megabytes of ram, even phones have plenty.
- They make your team lazy when it comes to structuring your source code into proper folders Absolutely not. Your reasoning is that making things easier = making code worse. The IDE you use has nothing to do with your dev culture
- They take ages to install. Some of them do, notably Visual Studio. All the other ones I've used just take a few minutes. Also, who cares??? You only have to install it once, what is 5 minutes for an app you're going to use for thousands of hours???
- Support fewer operating systems. No. IDE's based on java run on almost anything. Again I think you're speaking from the experience of using visual studio.
- Are usually proprietary and difficult to customize. Also no. Every IDE I've used supports plugins and an unholy amount of configuration options. Every IDE I use is open source, again except visual studio.
- More prone to bugs. What? Why? How?
Alot of these things do matter and it seems to me like all you're doing here is excusing bloat via hyperbole. I don't even agree necessarily with a lot of the parent comment, but I disagree with yours.
>The rigid interfaces mean that I need to spend more time researching how to use various modules/libraries
Why, otherwise you'd just throw random parameters in a module's functions and see what sticks?
>Compile time means that it takes more time to debug anything.
Most people compile their JS anyway, TS or not, with Babel et al.
>maybe code completion would offset this problem but this is only possible with a heavy IDE that has intellisense or similar - Not Atom
VS Code has code completion for TS and is similar to Atom. And even Sublime Text has code completion for TS (based on tools MS itself provides for "intellisense" style predictions).
>- It requires more planning to do anything (since you have to design the interfaces before you can start to implement). This is also not good if you just want to try something quickly and then roll back later
Doesn't make any sense. It's not as if you don't need to know the interfaces before you start to implement with regular js. Only there you need to hunt for the documentation to tell you what's expected to pass -- instead of seeing what the types are directly (e.g. with intellisense).
>- Changes to one class/interface tend to have a large cascading effect on other classes/interfaces so it takes more time to make changes to code - This happens with JS too but to a much lesser extent.
It happens to the exact same extend in JS. Only with TS you are shown where the problems are automatically, with JS you have to hunt those places or discover it at runtime.
The rest goes downhill...
Why, otherwise you'd just throw random parameters in a module's functions and see what sticks?
>Compile time means that it takes more time to debug anything.
Most people compile their JS anyway, TS or not, with Babel et al.
>maybe code completion would offset this problem but this is only possible with a heavy IDE that has intellisense or similar - Not Atom
VS Code has code completion for TS and is similar to Atom. And even Sublime Text has code completion for TS (based on tools MS itself provides for "intellisense" style predictions).
>- It requires more planning to do anything (since you have to design the interfaces before you can start to implement). This is also not good if you just want to try something quickly and then roll back later
Doesn't make any sense. It's not as if you don't need to know the interfaces before you start to implement with regular js. Only there you need to hunt for the documentation to tell you what's expected to pass -- instead of seeing what the types are directly (e.g. with intellisense).
>- Changes to one class/interface tend to have a large cascading effect on other classes/interfaces so it takes more time to make changes to code - This happens with JS too but to a much lesser extent.
It happens to the exact same extend in JS. Only with TS you are shown where the problems are automatically, with JS you have to hunt those places or discover it at runtime.
The rest goes downhill...
"It requires more planning to do anything. This is also not good if you just want to try something quickly and then roll back later."
Since you can pretty much type javascript in to a TS file and it will work I don't see this being valid.
Also planning is good, if your not thinking about the structure of your code (which does not take that long) then your just producing diarrhea.
Since you can pretty much type javascript in to a TS file and it will work I don't see this being valid.
Also planning is good, if your not thinking about the structure of your code (which does not take that long) then your just producing diarrhea.
> - 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.
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.
The Typescript compiler is also happy to run directly inside the browser because it is itself written in JS. I've debugged projects where the TS is compiled at runtime inside the browser and F5 refresh is the entire build process.
Though it's just as easy to use a good IDE's build button (VSCode Ctrl+Shift+B for instance) or TS works well as a watch process that watches for saves and compiles them when you save.
Though it's just as easy to use a good IDE's build button (VSCode Ctrl+Shift+B for instance) or TS works well as a watch process that watches for saves and compiles them when you save.
> - It requires more planning to do anything
That's the idea. You think about what you're going to write in a strongly typed language rather than just throwing stuff at the wall hoping that something will stick.
> - The rigid interfaces mean that I need to spend more time researching how to use various modules/libraries
I don't understand this. In one case you have an API where the types of all the functions is available, so you can see almost right away how to use it. In the other case you have to rely on someone providing you really good documentation OR you read the implementation.
> - Changes to one class/interface tend to have a large cascading effect on other classes/interfaces so it takes more time to make changes to code - This happens with JS too but to a much lesser extent.
It's either you find the error at compile time or at run time. Don't kid yourself, there's a 'cascading effect' in both typed and untyped codebases, just in the typed one the compiler will help you find errors.
Granted, I'm not the biggest TS fan, I'd take Elm or Purescript, or even Flow. But your gripes seem to be directed to typed languages in general.
That's the idea. You think about what you're going to write in a strongly typed language rather than just throwing stuff at the wall hoping that something will stick.
> - The rigid interfaces mean that I need to spend more time researching how to use various modules/libraries
I don't understand this. In one case you have an API where the types of all the functions is available, so you can see almost right away how to use it. In the other case you have to rely on someone providing you really good documentation OR you read the implementation.
> - Changes to one class/interface tend to have a large cascading effect on other classes/interfaces so it takes more time to make changes to code - This happens with JS too but to a much lesser extent.
It's either you find the error at compile time or at run time. Don't kid yourself, there's a 'cascading effect' in both typed and untyped codebases, just in the typed one the compiler will help you find errors.
Granted, I'm not the biggest TS fan, I'd take Elm or Purescript, or even Flow. But your gripes seem to be directed to typed languages in general.
>> - It requires more planning to do anything
> That's the idea. You think about what you're going to write in a strongly typed language rather than just throwing stuff at the wall hoping that something will stick.
I think this is a valid point for developers who only have a few years of experience but I've been coding professionally for over a decade now - I don't need the compiler to artificially slow me down - I'd rather spend my mental energy thinking about the algorithm/architecture in its purest form without getting caught up in trying to satisfy the compiler's tedious requirements.
For me programming in a typed language is like using software that always asks you "are you sure you want to do this?" every time you tell it to do something. It's OK if you're a beginner, but I just find it frustrating.
I spent many years programming in ActionScript 3 and then Java so I feel like I've given typed languages a fair shot.
> That's the idea. You think about what you're going to write in a strongly typed language rather than just throwing stuff at the wall hoping that something will stick.
I think this is a valid point for developers who only have a few years of experience but I've been coding professionally for over a decade now - I don't need the compiler to artificially slow me down - I'd rather spend my mental energy thinking about the algorithm/architecture in its purest form without getting caught up in trying to satisfy the compiler's tedious requirements.
For me programming in a typed language is like using software that always asks you "are you sure you want to do this?" every time you tell it to do something. It's OK if you're a beginner, but I just find it frustrating.
I spent many years programming in ActionScript 3 and then Java so I feel like I've given typed languages a fair shot.
> I don't need the compiler to artificially slow me down
It's slowing you down because you've written code with errors. Those type errors are still in your dynamic code, you just can't see them.
> I spent many years programming in ActionScript 3 and then Java so I feel like I've given typed languages a fair shot.
I don't think you have, you've missed many wonderful modern type system features.
Algebraic types, for one, aren't present in either of those languages and are massively useful, replacing 'null' (with a type like Option/Maybe) and exceptions (with a Result/Either concept) in many languages that have them.
Not to mention, with a language that has type inference, you don't even have to write the type in many cases, and yet you keep the guarantees of a strongly typed language.
It's slowing you down because you've written code with errors. Those type errors are still in your dynamic code, you just can't see them.
> I spent many years programming in ActionScript 3 and then Java so I feel like I've given typed languages a fair shot.
I don't think you have, you've missed many wonderful modern type system features.
Algebraic types, for one, aren't present in either of those languages and are massively useful, replacing 'null' (with a type like Option/Maybe) and exceptions (with a Result/Either concept) in many languages that have them.
Not to mention, with a language that has type inference, you don't even have to write the type in many cases, and yet you keep the guarantees of a strongly typed language.
>I think this is a valid point for developers who only have a few years of experience but I've been coding professionally for over a decade now - I don't need the compiler to artificially slow me down
You'd be surprised.
There's a reason that developers after decades of dynamic languages turn increasingly to types (of which Flow and TS are examples in the JS world).
You'd be surprised.
There's a reason that developers after decades of dynamic languages turn increasingly to types (of which Flow and TS are examples in the JS world).
VS Code (equivalent to Atom in power and scope) has the best intellisense for typescript. I use it over full-fledged IDEs (Intellij IDEA) all the time.
> 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).
Obviously, to each his own.
I'd encourage you try Typescript again though. Your given reason doesn't make much sense. Regardless of whether the language is strongly typed or weakly typed, you still need to use modules and libraries correctly. "Not having to research" means you're just going to end up throwing data at a library without knowing what it's expecting. The research has to happen in both scenarios, but with typed languages it's easier. The research is just in the code already. (Try VS Code, not a "heavy" IDE by any means, but it has native support for TS code completion.)
If I have any modular interface, you need to know what to pass me. If you're receiving data from me, you need to know the structure of what I'm sending back to you.
In a weakly typed language, you can guess at what data structure I'm going to want. You can fish around in my returned data for what you're looking for with no guarantees. You have to look for docs, which may or may not be up to date.
But in a strongly typed language, the code is the doc. You and I and your IDE and my IDE are all on the same page. And the docs are always up to date. You can't pass me data that I'm not expecting and you always know how to access the data I'm returning to you.
Obviously, to each his own.
I'd encourage you try Typescript again though. Your given reason doesn't make much sense. Regardless of whether the language is strongly typed or weakly typed, you still need to use modules and libraries correctly. "Not having to research" means you're just going to end up throwing data at a library without knowing what it's expecting. The research has to happen in both scenarios, but with typed languages it's easier. The research is just in the code already. (Try VS Code, not a "heavy" IDE by any means, but it has native support for TS code completion.)
If I have any modular interface, you need to know what to pass me. If you're receiving data from me, you need to know the structure of what I'm sending back to you.
In a weakly typed language, you can guess at what data structure I'm going to want. You can fish around in my returned data for what you're looking for with no guarantees. You have to look for docs, which may or may not be up to date.
But in a strongly typed language, the code is the doc. You and I and your IDE and my IDE are all on the same page. And the docs are always up to date. You can't pass me data that I'm not expecting and you always know how to access the data I'm returning to you.
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 much easier. It uses a one-way data flow concept like React+Flux. Vue even has it's own competitor to redux/mobX called Vuex, and what makes it easier is that Vue is cognizant of Vuex's existence. There are really solid dev tools for Chrome as well (Vue and Vuex are aware of the dev tools as well).
I run a dev meetup, and I had planned to give a talk there on Angular 2. I even gave talks on JS tooling a year ago and TS last summer in preparation. Instead, I gave a talk on Vue this month, and people loved it. Here are the slides if you want to check it out (there are even embedded Vue apps!): https://azurelogic.github.io/vue-js-2.x-talk/#/
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 much easier. It uses a one-way data flow concept like React+Flux. Vue even has it's own competitor to redux/mobX called Vuex, and what makes it easier is that Vue is cognizant of Vuex's existence. There are really solid dev tools for Chrome as well (Vue and Vuex are aware of the dev tools as well).
I run a dev meetup, and I had planned to give a talk there on Angular 2. I even gave talks on JS tooling a year ago and TS last summer in preparation. Instead, I gave a talk on Vue this month, and people loved it. Here are the slides if you want to check it out (there are even embedded Vue apps!): https://azurelogic.github.io/vue-js-2.x-talk/#/
i've built large applications in both Vue and Angular 2 and i still prefer Angular. don't get me wrong, Vue 2 is really nice, but i strongly prefer TypeScript over any JavaScript revision. Flow is helpful, and Vue 2 has typings, but it isn't quite as powerful as working with a TypeScript framework building a TypeScript app.
to each their own, of course.
to each their own, of course.
I'm on the fence about TS. I see the value in it, but it can be a lot of trouble to use, and I have found that the mistakes I make are almost all caught by a ESLint (and the remaining mistakes aren't type system mistakes).
Coming from Angular 1, having tried and enjoyed React, Vue is godsend! I've been working with it for a few weeks and my productivity has skyrocketed. Debugging is amazing and their webpack templates just work. The learning curve with an angular background is almost flat, and the ecosystem is surprisingly mature already.
I don't care about templates being "bad" a as long as it works for us. I'm sold.
I don't care about templates being "bad" a as long as it works for us. I'm sold.
Thanks to this comment I'm looking at it now. The only thing I hate is 'v-for="todo in todos"' as an html attribute. I would personally prefer a mustache-like syntax.
Other than that, this looks awesome. Time to develop a todo app.
Other than that, this looks awesome. Time to develop a todo app.
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 <script> 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.
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.
I find them to be helpful in being able to see the markup as a complete chunk, without code getting in the way. In teams with "coders" and "designers", this also makes it easier for the designers to understand the components and do their work.
You don't even have to know use them. You can use render functions or JSX like React.
I'm glad that Angular 2 is the way it is because it allows to build enterprise-sized applications more easily that using Vue.js.
I love Vue.js too, but just for small projects or when I need to add some complex functionality to an existing site that is not SPA.
I guess it comes down with the saying "the right tool for the job".
I love Vue.js too, but just for small projects or when I need to add some complex functionality to an existing site that is not SPA.
I guess it comes down with the saying "the right tool for the job".
> I'm glad that Angular 2 is the way it is because it allows to build enterprise-sized applications more easily that using Vue.js.
That's just FUD, there is nothing in Angular that makes it more oriented toward Enterprise than Vue.js, unless you consider bloat an necessary component of any enterprise oriented solution, which is obviously a lie. What will decide which framework is "enterprise" is the ecosystem, the amount of widgets, not the bloat.
> I guess it comes down with the saying "the right tool for the job".
Exactly, the right tool for the job, AKA using a library that does only what it should do instead of trying to be anything and everything because its creators think the complex it looks, the more enterprisey it sounds. They will learn the hard way, and so will you.
That's just FUD, there is nothing in Angular that makes it more oriented toward Enterprise than Vue.js, unless you consider bloat an necessary component of any enterprise oriented solution, which is obviously a lie. What will decide which framework is "enterprise" is the ecosystem, the amount of widgets, not the bloat.
> I guess it comes down with the saying "the right tool for the job".
Exactly, the right tool for the job, AKA using a library that does only what it should do instead of trying to be anything and everything because its creators think the complex it looks, the more enterprisey it sounds. They will learn the hard way, and so will you.
[deleted]
[deleted]
I have built multi-10k+ line applications in angular 1, 2 and react. My personal preference is react by a mile.
The concept of modules and dependency injection was nice before we had any sort of module systems, but at this point it's essentially entirely busy work, given tools like proxyquire when testing.
Template compilation errors are a nice step up from 1, but those that I've seen have been very misleading and have been the cause of wasted hours debugging.
Angular 2 makes extensive use of the Reflection API for metadata, which combined with the fact that angular-cli is hard-coded to perform static analysis (even if you disable AOT) is another pain point. I'm trying to build the equivalent to "react storybook" for our platform, and it's taken me about 3x the time it would have with React.
With all of that said, if you need a "think-inside-the-box" tool for a large, decentralized dev team, angular can win out- there are fewer places to look for documentation, which will be nice when angulars documentation improves.
I actually find that React better encourages smaller, cleaner components with fewer responsibilities, but that's also likely due to being very familiar with the redux paradigm.
Finally, if you want very flexible components, react wins hands down, because components can be used as properties to other components; dynamically rendering components in angular has always had an inversion of control issue.
That's been my experience; ymmv.
The concept of modules and dependency injection was nice before we had any sort of module systems, but at this point it's essentially entirely busy work, given tools like proxyquire when testing.
Template compilation errors are a nice step up from 1, but those that I've seen have been very misleading and have been the cause of wasted hours debugging.
Angular 2 makes extensive use of the Reflection API for metadata, which combined with the fact that angular-cli is hard-coded to perform static analysis (even if you disable AOT) is another pain point. I'm trying to build the equivalent to "react storybook" for our platform, and it's taken me about 3x the time it would have with React.
With all of that said, if you need a "think-inside-the-box" tool for a large, decentralized dev team, angular can win out- there are fewer places to look for documentation, which will be nice when angulars documentation improves.
I actually find that React better encourages smaller, cleaner components with fewer responsibilities, but that's also likely due to being very familiar with the redux paradigm.
Finally, if you want very flexible components, react wins hands down, because components can be used as properties to other components; dynamically rendering components in angular has always had an inversion of control issue.
That's been my experience; ymmv.
You've build multi 10k+ line applications in Angular 2?
It was released 5 months ago.
It was released 5 months ago.
With my team, we have developed using Angular 2.0 beta candidate mid-size banking application for one of the biggest swiss banks, plus complex hypothec management and transfer application which is public on the bank website. We pretty much managed to release the apps before actual Angular 2 official release, and then we upgraded apps to official versions. It was really interesting to experience and it all went really smooth but we had to use Redux (just a note). So yes, there are some of us who are doing production ready code before the actual frameworks are released. Bold move, but a smart one in our case. Apps are almost bug-free (really edge cases are minor bugs). I do have to note that we are all Full Stack Java devs who have experience in banking and complex applications for a long time, plus we focused a lot on Angular in the past, so this transition with Typescript and Angular 2 syntax was a charm for us.
One in angular 2, two in 1, and another that was a maaasive project in react. Team sizes varied from 3 devs to 12 or 16 (I forget which)
Not GP, but it's been publicly available long before that.
There is probably a non-trivial amount of astroturfing here, but also software developers are people too, and people get dogmatic about their opinions.
I probably won't ever use Angular unless I find myself desperate for work and can't find anything else. The problem I see inherent in frameworks is that they are all dogmatic about their opinions, and thus criticism of frameworks often do boil down to "I don't agree with their opinion", sometimes with rationalizations mixed in.
Preferences aside, Angular is objectively one of, if not the most, heaviest frameworks for web front-ends. It is not just a matter of bandwidth to the end user, but also a lot of magic under the hood that developers have to deal with. Consider the Java mindset that may have inspired Angular, people don't want to deal with that level of verbosity and enterprise mentality.
Unfortunately, there are increasingly few employment options if you want to use anything other than React or Angular. So rather than framing this argument in terms of framework hate, consider it a problem that lots of developers are forced to use these frameworks in order to be more like easily replaceable cogs in a machine, or be unemployed.
I probably won't ever use Angular unless I find myself desperate for work and can't find anything else. The problem I see inherent in frameworks is that they are all dogmatic about their opinions, and thus criticism of frameworks often do boil down to "I don't agree with their opinion", sometimes with rationalizations mixed in.
Preferences aside, Angular is objectively one of, if not the most, heaviest frameworks for web front-ends. It is not just a matter of bandwidth to the end user, but also a lot of magic under the hood that developers have to deal with. Consider the Java mindset that may have inspired Angular, people don't want to deal with that level of verbosity and enterprise mentality.
Unfortunately, there are increasingly few employment options if you want to use anything other than React or Angular. So rather than framing this argument in terms of framework hate, consider it a problem that lots of developers are forced to use these frameworks in order to be more like easily replaceable cogs in a machine, or be unemployed.
[deleted]
given that both frameworks are open source I highly doubt any astroturfing on either side. I think what you're seeing is a bunch of developers riled up :)
How ironic is that comment coming from a throwaway account... Given that both frameworks are products of multi-billion-dollar corporations, used mostly in commercial applications, and keep a fair number of people employed, I think it's a bit more than just getting riled up.
I've got experience with Angular 1, 2, React+Redux, with teams of 5+
For me, the real problems in web app development are
1. State management
2. Side effects
3. View layer performance
Angular pales by comparison to things like React+Redux which were born out of necessity, and as such, tackle those issues with laser like focus.
Angular doesn't feel like it was born out of necessity, but out of some desire to just build a framework. As such, it's complicated and magical feels clumsy by comparison.
When combined with things like Immutable, Sagas, and ReSelect, the Redux/React style of architecture (feel free to swap out Redux or React for whatever you prefer) is so much more practical and useful compared to Angular.
I don't know what it is that makes Angular popular with back end developers, but they seem to be Angular's biggest supporters. I consider my self full stack, but front end first, and I've noticed that people like me tend to favour libraries over frameworks. There's obviously something that is informing each groups opinions on this matter, but I don't know what it is.
For me, the real problems in web app development are
1. State management
2. Side effects
3. View layer performance
Angular pales by comparison to things like React+Redux which were born out of necessity, and as such, tackle those issues with laser like focus.
Angular doesn't feel like it was born out of necessity, but out of some desire to just build a framework. As such, it's complicated and magical feels clumsy by comparison.
When combined with things like Immutable, Sagas, and ReSelect, the Redux/React style of architecture (feel free to swap out Redux or React for whatever you prefer) is so much more practical and useful compared to Angular.
I don't know what it is that makes Angular popular with back end developers, but they seem to be Angular's biggest supporters. I consider my self full stack, but front end first, and I've noticed that people like me tend to favour libraries over frameworks. There's obviously something that is informing each groups opinions on this matter, but I don't know what it is.
>When combined with things like Immutable, Sagas, and ReSelect, the Redux/React style of architecture (feel free to swap out Redux or React for whatever you prefer) is so much more practical and useful compared to Angular.
You can use all that with angular 2. I am.
Redux -> @ngrx/store
Immutable -> same
Sagas -> @ngrx/effects
ReSelect -> same
Example here: https://github.com/ngrx/example-app
You can use all that with angular 2. I am.
Redux -> @ngrx/store
Immutable -> same
Sagas -> @ngrx/effects
ReSelect -> same
Example here: https://github.com/ngrx/example-app
I can only speak from personal experience, but I've worked on 2 SPA angular apps that were both a nightmare.
The react apps I've worked on have been much more successful; we haven't had to throw the whole thing away (unlike one of those angular ones...)
I'm sure other people have had other experiences, but after two terrible experiences, the questions I would ask are:
- Why would I bother looking at angular again?
- What has significantly changed in the last year to reduce the complexity, increase the component ecosystem or increase the quality and quantity of the documentation?
If you can't answer either of those with meaningful answers, I don't see any reason, given the other alternatives to angular that are around, to try using it again.
The react apps I've worked on have been much more successful; we haven't had to throw the whole thing away (unlike one of those angular ones...)
I'm sure other people have had other experiences, but after two terrible experiences, the questions I would ask are:
- Why would I bother looking at angular again?
- What has significantly changed in the last year to reduce the complexity, increase the component ecosystem or increase the quality and quantity of the documentation?
If you can't answer either of those with meaningful answers, I don't see any reason, given the other alternatives to angular that are around, to try using it again.
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 output (the HTML).
That being said, Angular is still a valid option (haven't tried Angular 2, but from what I've read it's a nice upgrade over Angular 1). I'd still take React any day of the week over it, just for the simplicity it brings. Of course there are other drawbacks to using it, but nothing's perfect.
That being said, Angular is still a valid option (haven't tried Angular 2, but from what I've read it's a nice upgrade over Angular 1). I'd still take React any day of the week over it, just for the simplicity it brings. Of course there are other drawbacks to using it, but nothing's perfect.
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
What else have you used? Having spent time in both Angular and React, I can say from experience I'm more productive and less angry while working in React. Less to learn, much simpler, yet no less powerful.
I started using Aurelia for one of our projects back in January 2016 and I find it both straightforward and powerful. I've been building web apps for 14 years and Aurelia is big on following web standards. I had used Angular for a project back in 2012 and found it very Java-esque and not so intuitive. The founder of Aurelia left the Angular 2 team because he felt they weren't choosing to follow standards. Aurelia's community is growing and has an active Gitter channel, so drop by and check it out!
Angular is a huge framework with a very OO style written by java devs. You have to learn many things to be productive with it, including a really weird string templating language.
The most funny thing probably is the typescript sale pitch (I use and like typescript) where you actually don't beneficiate from typescript at all with half of angular (string templates means no type checking or intelliSense on component names, model properties, component apis, etc)
It's also pretty fat and not exactly performant. It's simply a no-no on mobile. Its niche use case seems to be backend developers who know OO well, FP not so much, developing low/average quality back-office apps quickly without having to care about what's going on behind the scene.
The angular core devs always favor magic and shortcuts over simplicity. Its API surface is enormous, so have fun keeping up with the versions. It's optimized to get started quickly and be decently productive as long as you only use the core directives.
It's not terrible, but it's just not good if you care about the UX and maintainability of your app.
The most funny thing probably is the typescript sale pitch (I use and like typescript) where you actually don't beneficiate from typescript at all with half of angular (string templates means no type checking or intelliSense on component names, model properties, component apis, etc)
It's also pretty fat and not exactly performant. It's simply a no-no on mobile. Its niche use case seems to be backend developers who know OO well, FP not so much, developing low/average quality back-office apps quickly without having to care about what's going on behind the scene.
The angular core devs always favor magic and shortcuts over simplicity. Its API surface is enormous, so have fun keeping up with the versions. It's optimized to get started quickly and be decently productive as long as you only use the core directives.
It's not terrible, but it's just not good if you care about the UX and maintainability of your app.
The ionic developers are using angular 2. http://ionicframework.com/docs/v2/intro/installation/ . So it it isn't a 'no-no' on mobile as you put it. Angular 2 AOT produces very lean JS.
I still need a good reason why I need DI built into a framework and the following is not sufficient:
SomeClass.SomeDep = MockDep;
Angular 1 was great. It was first of its kind. And it was just a bit complex - but not too much.
Ng2 felt too different. Ng1 to Ng2 made me look outside and there was React gaining ground - perfect timing. In its original state React is so much simpler than Angular. But then React with just the basics can make you create bad code - that's what happened to me. React with best practices - is hard to digest.
So I went back to Ng2 - soon enough I was craving to go back to React. Suddenly I started hating Angular2 (but loved TypeScript).
I spent time learning React best practices - that require some patience. But one thing I brought on from Ng2 was TypeScript. TS makes you a lot more productive. Now React and TS is not a widely accepted combination - but its very productive as your app grows.
Ng2 felt too different. Ng1 to Ng2 made me look outside and there was React gaining ground - perfect timing. In its original state React is so much simpler than Angular. But then React with just the basics can make you create bad code - that's what happened to me. React with best practices - is hard to digest.
So I went back to Ng2 - soon enough I was craving to go back to React. Suddenly I started hating Angular2 (but loved TypeScript).
I spent time learning React best practices - that require some patience. But one thing I brought on from Ng2 was TypeScript. TS makes you a lot more productive. Now React and TS is not a widely accepted combination - but its very productive as your app grows.
Please take a look at Vue.js. I'm being redundant, intentionally.
There's something about it -- feels clean and minimal, works really well with my ruby- and rails- influenced mind, organizes my thinking about an app and makes it easy to have things in their right places, at a correct level of abstraction, effortlessly.
My reaction after encountering vuejs was one of relief -- finally seeing an option I resonate with, a vision driven by someone whose thinking is aligned with my desire to avoid confusion, complexity and frustration.
The free screencasts at laracasts and egghead.io are quick and fantastic.
https://laracasts.com/series/learn-vue-2-step-by-step
There's something about it -- feels clean and minimal, works really well with my ruby- and rails- influenced mind, organizes my thinking about an app and makes it easy to have things in their right places, at a correct level of abstraction, effortlessly.
My reaction after encountering vuejs was one of relief -- finally seeing an option I resonate with, a vision driven by someone whose thinking is aligned with my desire to avoid confusion, complexity and frustration.
The free screencasts at laracasts and egghead.io are quick and fantastic.
https://laracasts.com/series/learn-vue-2-step-by-step
I loved working with angular. They lost us when they released angular 2. It was complete breaking changes and the upgrade path was a nightmare. They basically were forcing users to completely rewrite their front-end if they wanted to upgrade. So the team figured if we have to rewrite our front-end, what's keeping us on angular and why would we stick with a framework that doesn't seem to have any issues forcing it's users to do complete rewrites just to use the newest version?
I wrote https://www.smsforecast.com using Angular2 and personally love the changes made from 1.X, I'm happy to see 4.0 come out along with it's bug fixes and features.
1.X felt messy, but writing web apps in Angular > 2 feels really clean when done right.
1.X felt messy, but writing web apps in Angular > 2 feels really clean when done right.
I would recommend CxJS as an alternative. It has the best mix of Angular and React features such as JSX based view, two-way data-binding, controllers. On top of that, a large collection of widgets and charts is included out of the box and we're soon to release a Material Design based theme.
https://cxjs.io/examples
Disclaimer: It's a commercial product and I'm the lead developer.
https://cxjs.io/examples
Disclaimer: It's a commercial product and I'm the lead developer.
I have been leading a good sized Angular app for work for the past 8 months, and upgrading from v2 to v4 has been painless, even while having an AOT compilation build pipeline set up - the only modifications we had to do was switch OpaqueToken to InjectorToken, <template> to <ng-template>, and Renderer usage to Renderer2, and these weren't required to be done yet. We only did those changes to get ahead of the curve from the deprecation messages.
On first note, the codegen size decreased dramatically for AOT compiled builds - we went from ~600 KB vendor + app minified and gzipped (not counting 50 KB of polyfills) to ~400 KB. This is huge, and the boot speed feels even faster on first user load of the page!
Thanks to the Angular team for this fantastic work!
On first note, the codegen size decreased dramatically for AOT compiled builds - we went from ~600 KB vendor + app minified and gzipped (not counting 50 KB of polyfills) to ~400 KB. This is huge, and the boot speed feels even faster on first user load of the page!
Thanks to the Angular team for this fantastic work!
I also had a painless upgrade from 2.4 to 4.0.
With angular-cli ng2 is now usable and in my opinion the best Javacript/typescript framework.
With angular-cli ng2 is now usable and in my opinion the best Javacript/typescript framework.
absolutely same experience in our case. Painless update with few template to ng-template ctrl+f changes.
Angular CLI stabilization is a much more important news, actually. One of mistakes of Angular team - Angular CLI had to be ready before Angular itself.
Angular CLI stabilization is a much more important news, actually. One of mistakes of Angular team - Angular CLI had to be ready before Angular itself.
Not an angular programmer, but I felt the API docs page didn't load quickly enough.
I forgot to mention one other change we had to do - we had to switch to the new @angular/animations package, but that was also a pretty simple switch.
Angular core team here, we're pretty excited about this release.
Main change, as noted, is the new View Engine. The design doc[0] is worth a read if you're interested in front-end at all.
Happy to answer any questions!
[0] https://docs.google.com/document/d/195L4WaDSoI_kkW094LlShH6g...
Main change, as noted, is the new View Engine. The design doc[0] is worth a read if you're interested in front-end at all.
Happy to answer any questions!
[0] https://docs.google.com/document/d/195L4WaDSoI_kkW094LlShH6g...
1) I'm still new to this, but why would someone not use Angular Universal/why is it not default? I have only read positives, but am sure there must be a reason.
2) Why do we need Angular Material 2, when Google's official Material Components Web project is meant to be used with all kinds of frameworks and even has framework integration examples with Angular2: https://github.com/material-components/material-components-w...
3) Should I follow Quickstart or CLI Quickstart in the docs to get started? I have heard that the CLI is recommended nowadays, but the Angular 4.0 release blog says the CLI isn't even stable.
2) Why do we need Angular Material 2, when Google's official Material Components Web project is meant to be used with all kinds of frameworks and even has framework integration examples with Angular2: https://github.com/material-components/material-components-w...
3) Should I follow Quickstart or CLI Quickstart in the docs to get started? I have heard that the CLI is recommended nowadays, but the Angular 4.0 release blog says the CLI isn't even stable.
1) the core of Angular Universal "graduated" into @angular/platform-server with 4.0 - previously it was a more experimental project. We're officially supporting a "renderToString()" API that can be used however you like.
So really, it's brand new, and we're excited to see what the community does with it.
Philosophically, pre-rendering every SPA server side isn't a silver bullet. For a ton of cases it makes a lot of sense, but we want to avoid the impression that we're positioning SSR as a replacement for making your app fast.
2) The expectation of the Material Components Web project is that everything be "wrapped" for the specific framework. Angular Material is native Angular, and we have a team dedicated to that. Polymer has a material suite as well, and most of those components can work in Angular apps too. Components for everyone!
2a) you're asking a Googler that question. We have like, 11 messaging apps. I don't know what to tell you.
3) CLI went stable today, with its 1.0 release. We'll be moving the docs over to use the CLI everywhere soon - personally, i'd use the CLI to generate a new project and then follow along the tutorials.
So really, it's brand new, and we're excited to see what the community does with it.
Philosophically, pre-rendering every SPA server side isn't a silver bullet. For a ton of cases it makes a lot of sense, but we want to avoid the impression that we're positioning SSR as a replacement for making your app fast.
2) The expectation of the Material Components Web project is that everything be "wrapped" for the specific framework. Angular Material is native Angular, and we have a team dedicated to that. Polymer has a material suite as well, and most of those components can work in Angular apps too. Components for everyone!
2a) you're asking a Googler that question. We have like, 11 messaging apps. I don't know what to tell you.
3) CLI went stable today, with its 1.0 release. We'll be moving the docs over to use the CLI everywhere soon - personally, i'd use the CLI to generate a new project and then follow along the tutorials.
Thank you, that was really helpful!
I have a question.
Who thought it was a good idea to make Angular 2 incompatible with Angular 1?
You had it, and you blew it. Most people aren't going to use any version of Angular, now, and have switched to React and Vue.
Who thought it was a good idea to make Angular 2 incompatible with Angular 1?
You had it, and you blew it. Most people aren't going to use any version of Angular, now, and have switched to React and Vue.
"Who thought it was a good idea to make Angular 2 incompatible with Angular 1?"
This is so much discussed that I am not going to answer that. Google it.
But according to the latest StackOverflow survey [1] Angular is still bigger than you think: AngularJS 44.3%, React 19.5%
[1] http://stackoverflow.com/insights/survey/2017/
This is so much discussed that I am not going to answer that. Google it.
But according to the latest StackOverflow survey [1] Angular is still bigger than you think: AngularJS 44.3%, React 19.5%
[1] http://stackoverflow.com/insights/survey/2017/
Most companies don't switch quickly.
We have a huge Angular 1.x app, but after hiring some new developers for our team we found the pool of React devs was huge compared to Angular devs. So much developer goodwill and mindshare has been lost.
After carefully evaluating the technical aspects of Angular and React and externalities like the above, we decided to start building new software with React.
Angular won't go away overnight, it will see a very steady and slow attrition, with developers themselves leading the way.
We have a huge Angular 1.x app, but after hiring some new developers for our team we found the pool of React devs was huge compared to Angular devs. So much developer goodwill and mindshare has been lost.
After carefully evaluating the technical aspects of Angular and React and externalities like the above, we decided to start building new software with React.
Angular won't go away overnight, it will see a very steady and slow attrition, with developers themselves leading the way.
I also skipped Angular 2 and moved to VueJS. Never been happier.
But I was responding to "You had it, and you blew it. Most people aren't going to use any version of Angular, now, and have switched to React and Vue."
When you look at the stats and look at other places online there are still very much people liking and using Angular. So it's not going away soon.
Also take a look at Google trends: https://trends.google.com/trends/explore?q=angular,react Both Angular and React are growing at an equal pace.
So the claim that developing new versions of Angular is a waste of time is nonsense.
But I was responding to "You had it, and you blew it. Most people aren't going to use any version of Angular, now, and have switched to React and Vue."
When you look at the stats and look at other places online there are still very much people liking and using Angular. So it's not going away soon.
Also take a look at Google trends: https://trends.google.com/trends/explore?q=angular,react Both Angular and React are growing at an equal pace.
So the claim that developing new versions of Angular is a waste of time is nonsense.
Better trend comparison (the other one the first example query for react was "Youtubers react")
https://trends.google.com/trends/explore?q=%2Fm%2F0j45p7w,%2...
https://trends.google.com/trends/explore?q=%2Fm%2F0j45p7w,%2...
These fad shifts are inherent because there is little point in competing with 0 years experience in an established tech if the market will allow breaking changes.
Angular is actually better off with the break as new graduates may use it to replace vue as the new fad once vue has replaced react.
Angular is actually better off with the break as new graduates may use it to replace vue as the new fad once vue has replaced react.
Similar to what happened with backbone when angular gained traction.
Because Angular was the only real choice for awhile. That's like saying PHP is still bigger than you think because half the web runs on PHP but that is old legacy shit. Almost othing new and serious is using it.
What do you consider "serious"? Plenty of large applications are being built right now in PHP 7.
"Serious" means it was started by a person who regularly blogs or tweets about how to choose a technology.
There was Ember.
Discourse uses Ember. It's pretty successful. http://www.discourse.org/
Ember has bad performance on Android[0]. The Discourse team had to write their own Virtual DOM renderer to work around this[1].
[0] https://discuss.emberjs.com/t/why-is-ember-3x-5x-slower-on-a...
[1]https://eviltrout.com/2016/02/25/fixing-android-performance....
[0] https://discuss.emberjs.com/t/why-is-ember-3x-5x-slower-on-a...
[1]https://eviltrout.com/2016/02/25/fixing-android-performance....
That was over 2 years ago.
That's legacy projects I bet. Of course, big projects have to stay with a technology for at least 2 years, can't keep rewriting things every time a new framework comes out. In this case, they unfortunately picked a framework that was discontinued.
I talked to many devs who didn't accept a job because it was Angular instead of React.
I talked to many devs who didn't accept a job because it was Angular instead of React.
That is purely anecdotal. There are a lot of companies and devs outside your circles that don't jump on the new shiny, and will continue to use Angular going forward.
No answer is better than arrogant answer.
I didn't want to sound arrogant. But when Angular 2 was released the whole web broke down in anger and had questions like this. So there are a lot of good answers on StackOverflow and other sites.
So my answer to the question was something like: "You can find a lot of info by Googling it".
But I am not able to change my comment anymore.
So my answer to the question was something like: "You can find a lot of info by Googling it".
But I am not able to change my comment anymore.
It was a rhetorical question...
If you are not going to answer it, don't add noise to the discussion.
Angular 2 is a different framework, plain and simple. You can continue to use AngularJS 1.x if you were on that framework.
I understand the frustration of someone who has used AngularJS 1.x. There is not really a straightforward and low risk path to upgrading a production app.
But that is like saying there is not really a straightforward risk to switching from AngularJS 1.x to React. They're different frameworks. AngularJS is different from Angular.
In my opinion the Angular team has created something really special with this new framework. I think it falls into a category of its own, very difficult to compare it to something like Vue.
I understand the frustration of someone who has used AngularJS 1.x. There is not really a straightforward and low risk path to upgrading a production app.
But that is like saying there is not really a straightforward risk to switching from AngularJS 1.x to React. They're different frameworks. AngularJS is different from Angular.
In my opinion the Angular team has created something really special with this new framework. I think it falls into a category of its own, very difficult to compare it to something like Vue.
> Angular 2 is a different framework, plain and simple.
I wonder if, strategically, it would have been a better idea to give it a new name rather than a subsequent version number?
I wonder if, strategically, it would have been a better idea to give it a new name rather than a subsequent version number?
I always figured it was to give the illusion of stability and continuity (ironically). Like "Angular has been out since 2010, before React and Ember" especially since a common criticism of Google is that they frequently abandon their projects.
This is ridiculous.
Give it another name, then.
You can't get people to adopt your framework, stop developing it leaving millions of projects in shit, and then expect people to do it all over again.
I'm glad that Google paid this strategic error dearly, having a huge percentage of people switching to React. Perhaps next time they'll think about it more deeply.
Give it another name, then.
You can't get people to adopt your framework, stop developing it leaving millions of projects in shit, and then expect people to do it all over again.
I'm glad that Google paid this strategic error dearly, having a huge percentage of people switching to React. Perhaps next time they'll think about it more deeply.
> Angular 2 is a different framework, plain and simple.
Yes. Retaining the Angular name is just a way to slightly disguise that they've dropped a framework altogether and left its user high and dry.
Yes. Retaining the Angular name is just a way to slightly disguise that they've dropped a framework altogether and left its user high and dry.
Good to read this comment because I definitely feel this way too. Angular 2 just made things weird and confusing for everyone, experts and newbies.
Even though there are some things common but the differences are just too many. It would have been better if it was just release under a different banner altogether.
Even though there are some things common but the differences are just too many. It would have been better if it was just release under a different banner altogether.
We're using the universal fork of the CLI with the recent AOT (client side) patch for a current project. Will my upgrade path be straightforward? The project is a simple content based website which consumes a ruby API that we had built earlier. We use universal for setting up meta tags, crawlability, etc.
https://github.com/devCrossNet/universal-cli/issues/101#issu...
looks like the fork is going to be deprecated soon. I find the lack of documentation on universal a little bit frustrating, the only documentation I found is a blog post https://www.softwarearchitekt.at/post/2017/03/07/server-side... but the whole process is built on ng eject which removes some cli automations.
Can we expect Angular 4 best practices before 2020?
By their plan, in 2020 it will be Angular 10.
The next release is Angular 8. As every other major release is not backwards compatible, it is advised to wait until Angular 16 in 2024. /s
And we will at least have angular 4 best practices consolidated? Because ng2 is in the past now and don't have.
is it really smaller and faster. i got the impression the payload size reduction might come at a cost to render performance?
That's discussed in the doc (and there's some metrics). Update speed takes a (minimal) performance hit, in exchange for code size reductions.
We (and our colleagues at Google working on the web in general) find that the largest impact on performance comes from simply shipping less code.
Edit: correction: turns out our tests show we didn't take a perf hit on updates at all, and in fact ever-so-slightly improved. So win win :D
We (and our colleagues at Google working on the web in general) find that the largest impact on performance comes from simply shipping less code.
Edit: correction: turns out our tests show we didn't take a perf hit on updates at all, and in fact ever-so-slightly improved. So win win :D
"If you're interested in front-end at all"
Am I being dense? Shouldn't that be everyone reading this thread?
Am I being dense? Shouldn't that be everyone reading this thread?
Community here has been pretty negative on this lately. So I'll just add I've been using Angular 2x and also Ionic 2 the last year or so with great success.
One real benefit we saw was the ability to take a lot of Backbone code and just quickly port it (models to services, templates just back to html for a component, etc). This is helping us help our enterprise clients in conversions of both older front end code and older Java EE code (for example JSP + Struts => Restful + NG2X).
This is good to know, cheers!
VueJS is the only of these JavaScript UI Libraries/Frameworks I can stand... The only one whose syntax doesn't make my eyes bleed!... I can't wait for Alibaba's Weex to be officially released so Vue can be used for developing mobile apps too. Reusing components across platforms and the web is the only reason why I would like to jump into the JS wagon!
> VueJS is the only of these JavaScript UI Libraries/Frameworks I can stand...
Agreed. I just can't stand Angular's bloat, especially its IoC container. If I want to use one, then let me choose the one I want. A UI framework shouldn't come with it's own container it makes no sense. If this UI framework is too complicated to boostrap manually then it's too complicated at first place.
To make things clear I actually liked Angular 1 since it allows people to easily upgrade from jQuery and raw DOM.
Agreed. I just can't stand Angular's bloat, especially its IoC container. If I want to use one, then let me choose the one I want. A UI framework shouldn't come with it's own container it makes no sense. If this UI framework is too complicated to boostrap manually then it's too complicated at first place.
To make things clear I actually liked Angular 1 since it allows people to easily upgrade from jQuery and raw DOM.
>A UI framework shouldn't come with it's own container it makes no sense. If this UI framework is too complicated to boostrap manually then it's too complicated at first place.
I don't think Angular is just a UI framework though.
I don't think Angular is just a UI framework though.
Any word on when Weex will be released?
I've messed around with Quasar Framework[0], which lets you build mobile apps in Vue (Electron too). Seems like its inspired by Ionic. Still in dev, but I liked what I saw.
[0] http://quasar-framework.org/
I've messed around with Quasar Framework[0], which lets you build mobile apps in Vue (Electron too). Seems like its inspired by Ionic. Still in dev, but I liked what I saw.
[0] http://quasar-framework.org/
The only one whose syntax doesn't make my eyes bleed.
To me that sounds like choosing a tool based on the experience it gives the developer rather than the experience it gives the user. That's entirely the wrong way to pick what to build an app with. User experience is far more important.
(That's not a comment about Angular or Vue. They're both great, and you should use whichever is best for the web app you're writing.)
To me that sounds like choosing a tool based on the experience it gives the developer rather than the experience it gives the user. That's entirely the wrong way to pick what to build an app with. User experience is far more important.
(That's not a comment about Angular or Vue. They're both great, and you should use whichever is best for the web app you're writing.)
I assume you can create almost any ui with any framework. Some combinations will be a bit easier.
I agree that "beautiful" is not a very precise or important metric but easy to read and update is important. That said I think React is really good.
I agree that "beautiful" is not a very precise or important metric but easy to read and update is important. That said I think React is really good.
> rather than
i don't know that this is strictly true, nor that these notions are mutually exclusive.
i don't know that this is strictly true, nor that these notions are mutually exclusive.
I'll be that guy.
I'm sure the Angular team are great people, and they're clearly talented devs... but stay away from Angular.
It doesn't help with the problems you will actually face. Typed Javascript is a cargo cult. Angular just plain confusing for no apparent benefit. Dependency injection is bizarre. The distinction between modules, components, and directive is unnecessary. The Javascript community in general is moving away from OOP towards functional programming, but Angular has hitched it's wagon to OOP. It's reliance on the decorator pattern is maddening. It's view layer performance is sub standard. It's opinionated in all the wrong ways.
And I say this as someone with a lot of experience with Angular 1, Angular 2.
Trust me, go for libraries over frameworks every time. Redux, React, Immutable, Sagas, and reSelect. That's the future of web app development.
I'm sure the Angular team are great people, and they're clearly talented devs... but stay away from Angular.
It doesn't help with the problems you will actually face. Typed Javascript is a cargo cult. Angular just plain confusing for no apparent benefit. Dependency injection is bizarre. The distinction between modules, components, and directive is unnecessary. The Javascript community in general is moving away from OOP towards functional programming, but Angular has hitched it's wagon to OOP. It's reliance on the decorator pattern is maddening. It's view layer performance is sub standard. It's opinionated in all the wrong ways.
And I say this as someone with a lot of experience with Angular 1, Angular 2.
Trust me, go for libraries over frameworks every time. Redux, React, Immutable, Sagas, and reSelect. That's the future of web app development.
Is ironic just yesterday I read almost the same thing but trashtalking pseudofunctional programming in js, declarative components, microframeworks and dependency hell over all-in solutions, etc etc...
The reality is you don't really have any idea of what future of web development is, as anyone has. The community is not oriented in any way... rather we are probably in the time of biggest uncertainty and most frequent change of ideas of the whole web dev history.
Honestly the only and best suggestion I can make is "ignore everyone who try to say * this is how you should do things, the rest is shit * ", for the big part of the time they are just trying to self-justify an over investment on their own solution (or worst, ego), telling themselves they for sure had understood everything and the others are just wrong or "not there yet". They don't even know that they don't know.
The reality is you don't really have any idea of what future of web development is, as anyone has. The community is not oriented in any way... rather we are probably in the time of biggest uncertainty and most frequent change of ideas of the whole web dev history.
Honestly the only and best suggestion I can make is "ignore everyone who try to say * this is how you should do things, the rest is shit * ", for the big part of the time they are just trying to self-justify an over investment on their own solution (or worst, ego), telling themselves they for sure had understood everything and the others are just wrong or "not there yet". They don't even know that they don't know.
All good points, but FP has been a solid paradigm for a very long time, from people that had time and wisdom. It reduces very quantifiable issues like shared mutations, lines of code.
Now that doesn't make js revisitation of fp pristine but still it's quite a refreshing thing.
I never used Ang2+ but Ang1 was such a heavy thing; it was a OOP theory in itself, flipped around the DOM (I forgot their terminology but basically, the DOM tree became the inheritance tree).
Now that doesn't make js revisitation of fp pristine but still it's quite a refreshing thing.
I never used Ang2+ but Ang1 was such a heavy thing; it was a OOP theory in itself, flipped around the DOM (I forgot their terminology but basically, the DOM tree became the inheritance tree).
Never forget "Transclusion" and "Prototypical Scope Inheritance"
The angular team seems to hate simplicity and love made up words.
The angular team seems to hate simplicity and love made up words.
PSI looks like a fabulous alias for inheritance.
[deleted]
Totally agree. I really don't get how anybody can take a look at the mess at https://angular.io/docs/js/latest/api/ and think to themselves, yep - that's for me! Our first version was done in Angular v1 and we bit the bullet and converted over to React and never looked back.
No more factories, or dependency injection, or crazy template language that is never quite expressive enough, and no more digest cycles to optimize.
No more factories, or dependency injection, or crazy template language that is never quite expressive enough, and no more digest cycles to optimize.
> I really don't get how anybody can take a look at the mess at https://angular.io/docs/js/latest/api/ and think to themselves, yep - that's for me!
ANY web developer is someone that once upon a time looked at an api that was a complete mess (javascript, dom, ...) and still said to himself - that's for me!
Update : absolutely not saying they wrong to think so. Building the right things is more important than building the things right.
ANY web developer is someone that once upon a time looked at an api that was a complete mess (javascript, dom, ...) and still said to himself - that's for me!
Update : absolutely not saying they wrong to think so. Building the right things is more important than building the things right.
Angular 2+ is very different than Angular 1.X. The single directional data flow removes the need for digest cycle tweaking. You only need services for data and components for rendering and business logic.
The benefit over react is how you don't need anything additional to manage your workflow. It's nice to set up a project and not need to glue together libraries.
The benefit over react is how you don't need anything additional to manage your workflow. It's nice to set up a project and not need to glue together libraries.
The website seems like a mess. The title of linked page changes from `(v4.X.Y)` to `(v)` to `(v4.0.0)`. At the start it displays empty page shell, then fires two ajax request, each causing the page to redraw. This all could have just been statically generated web page.
I agree with this, few months ago I was trying to learn AJAX, I tried Angular (because it is backed by Google), few weeks into reading more about it, I was still reading the docs.
Then, I read that VueJS was a somewhat better and lean version of React, so I skipped React and started with Vue, I was surprised that I wrote the complete app within a week of starting to learn Vue (https://github.com/thewhitetulip/Tasks-vue) , of course, there were issues I faced, but they were solved quickly thanks to the amazing vue community.
I saw that many many people who are trying Vue are facing the same problems as I was, thus, I started writing this guide (https://github.com/thewhitetulip/intro-to-vuejs/).
Vue is amazing.
edit: link
Then, I read that VueJS was a somewhat better and lean version of React, so I skipped React and started with Vue, I was surprised that I wrote the complete app within a week of starting to learn Vue (https://github.com/thewhitetulip/Tasks-vue) , of course, there were issues I faced, but they were solved quickly thanks to the amazing vue community.
I saw that many many people who are trying Vue are facing the same problems as I was, thus, I started writing this guide (https://github.com/thewhitetulip/intro-to-vuejs/).
Vue is amazing.
edit: link
I really don't want to sound like an ass, but if you were at the stage of 'learning AJAX' a couple of months ago you are probably not in a position to judge the merits of JS frameworks like React, Vue or Angular.
As someone who is new to React, Angular, Vue, etc., he/she is in the PERFECT position to judge them. Libraries/frameworks are not just about performance, but how you learn them as well.
Those frameworks/libraries don't write themselves.
Those frameworks/libraries don't write themselves.
Frameworks are also about comprehensiveness. The start of the learning curve is not the sine qua non. That always reminds me of those complaints that writing a "Hello World" application in your GUI library of choice requires plenty of boiler plate etc., but you're probably not going to spend your developer life doing that. Often benefits for larger apps aren't obvious for the neophyte.
This is really aggravated that -- as opposed to native GUI libraries -- frontend requirements vary wildly. You might just need it to embellish some elements (i.e. the jquery level), you might also use it to build some large desktop app replacement.
Which is why I take most comparisons with a large grain of salt. In this regard, "JS framework XYZ sucks/rules" is the new "PHP is great/awful".
This is really aggravated that -- as opposed to native GUI libraries -- frontend requirements vary wildly. You might just need it to embellish some elements (i.e. the jquery level), you might also use it to build some large desktop app replacement.
Which is why I take most comparisons with a large grain of salt. In this regard, "JS framework XYZ sucks/rules" is the new "PHP is great/awful".
I agree with your points, I'd like to make one small point, Vue is not a framework per se, it is a library. That puts the responsibility of everything else on the programmers shoulders.
Well, with a lot of the light ones, you're buying into an ecosystem, not a framework.
Which often has the same end result, with a bit of added customization and some hard choices way too early.
Which often has the same end result, with a bit of added customization and some hard choices way too early.
[deleted]
Despite being new to AJAX, I wrote a Vue app within a week, 4-5 weeks into reading Angular, I was still reading the docs.
Edit: removed a brash statement.
Edit: removed a brash statement.
Yes and no. It says as much about you as it says about Angular or Vue. Look, Angular is far from being my favorite framework, and I have nothing against Vue, I'm more of a ClojureScript / om.next guy myself. I'm just really allergic to brash statements about frameworks, or hype in general.
How easy it is to get up and running with a framework doesn't actually tell me that much about the framework. Is the apparent simplicity simply an artefact of a huge layer of magic that I will end up fighting 4 months down the row?
A good example for this is actually the much maligned Angular 1, two-way data binding looks easy on the surface, but it comes with a cost. And guess what, two-way data binding was all the rage for a while in the HN echo chamber during the early days of Ember, Angular and Knockout.
In the end, whether you use Angular, React or Vue is really secondary to what you build with it. You can create shitty and good code with all of them.
Now, specifically about Angular2+. People act as if its approach was this awful, monstrous abomination. This all really depends on your circumstance tho, or not? There are instances where it makes perfect sense to tailor your setup and use a libraries-first approach. But if you do this, let's say in React, you need to make a lot of decisions up front. Do you want manage state? How? Redux? MobX? What about message buses? Do you want to use Flow? Just ES6 / Babel? TypeScript? What about routing? Lazy-loading? What about bundling? Webpack? Rollup? And so on.
Now, if you are part of a heterogenous developer team working in an enterprise shop, maybe you are happy to know that there is a framework that has made a lot of decisions already for you and prevents you from having to discuss the initial setup for 2 months, but at the same time is flexible enough to be adapted to your needs (I mean, this even applies to experienced front-end shops, there's nothing more horrible than endless discussions about shit like pure ES6 vs Flow vs TypeScript from senior devs). On top of that it uses patterns that you already know, such as dependency injection and annotations. While you personally might not feel at ease with this, many developers do.
How easy it is to get up and running with a framework doesn't actually tell me that much about the framework. Is the apparent simplicity simply an artefact of a huge layer of magic that I will end up fighting 4 months down the row?
A good example for this is actually the much maligned Angular 1, two-way data binding looks easy on the surface, but it comes with a cost. And guess what, two-way data binding was all the rage for a while in the HN echo chamber during the early days of Ember, Angular and Knockout.
In the end, whether you use Angular, React or Vue is really secondary to what you build with it. You can create shitty and good code with all of them.
Now, specifically about Angular2+. People act as if its approach was this awful, monstrous abomination. This all really depends on your circumstance tho, or not? There are instances where it makes perfect sense to tailor your setup and use a libraries-first approach. But if you do this, let's say in React, you need to make a lot of decisions up front. Do you want manage state? How? Redux? MobX? What about message buses? Do you want to use Flow? Just ES6 / Babel? TypeScript? What about routing? Lazy-loading? What about bundling? Webpack? Rollup? And so on.
Now, if you are part of a heterogenous developer team working in an enterprise shop, maybe you are happy to know that there is a framework that has made a lot of decisions already for you and prevents you from having to discuss the initial setup for 2 months, but at the same time is flexible enough to be adapted to your needs (I mean, this even applies to experienced front-end shops, there's nothing more horrible than endless discussions about shit like pure ES6 vs Flow vs TypeScript from senior devs). On top of that it uses patterns that you already know, such as dependency injection and annotations. While you personally might not feel at ease with this, many developers do.
Having used Vue for a month or so and Angular now for only a short period, I can easily say Vue is easier to learn for two reasons (neither of them being magic):
1. The documentation is excellent. It's short enough to read in one sitting and comprehensive in that every option is documented without needing to resort to third party websites. When a new feature is added even in a minor version upgrade, that new feature is in the documentation (and marked as NEW). The search is also great and separates results into "Guide" and "API" categories.
2. Vue itself is extremely cohesive and user friendly. User friendly can mean many things. One of those is simply terminology. For example, in both Angular and Vue, templates can have child content. AngularJS and Angular use the terms Transclusion and Content Projection while Vue templates can have "slots": a term which doesn't require a CS degree to understand the intent.
The Angular documentation is simply not good: the organization, navigation, search, and writing style are vastly inferior to Vue's docs. Many sections are written in tutorial form repeating the same information (or mentioning important information in an unrelated section). It's hard to find what you're looking for and in many cases things simply aren't documented. For instance, speaking of Content Projection, it's a major feature and it's nearly impossible to find in the docs unless you already know ahead of time that it's called "Content Projection". I had to learn about it from a third party blog which made me question if it was even safe to use. There's even an open JIRA item noting this:
https://github.com/angular/angular.io/issues/3099
Other things that bit me recently were key modifiers in which the possible options are only mentioned on the github issue page (not in the docs).
1. The documentation is excellent. It's short enough to read in one sitting and comprehensive in that every option is documented without needing to resort to third party websites. When a new feature is added even in a minor version upgrade, that new feature is in the documentation (and marked as NEW). The search is also great and separates results into "Guide" and "API" categories.
2. Vue itself is extremely cohesive and user friendly. User friendly can mean many things. One of those is simply terminology. For example, in both Angular and Vue, templates can have child content. AngularJS and Angular use the terms Transclusion and Content Projection while Vue templates can have "slots": a term which doesn't require a CS degree to understand the intent.
The Angular documentation is simply not good: the organization, navigation, search, and writing style are vastly inferior to Vue's docs. Many sections are written in tutorial form repeating the same information (or mentioning important information in an unrelated section). It's hard to find what you're looking for and in many cases things simply aren't documented. For instance, speaking of Content Projection, it's a major feature and it's nearly impossible to find in the docs unless you already know ahead of time that it's called "Content Projection". I had to learn about it from a third party blog which made me question if it was even safe to use. There's even an open JIRA item noting this:
https://github.com/angular/angular.io/issues/3099
Other things that bit me recently were key modifiers in which the possible options are only mentioned on the github issue page (not in the docs).
True, I didn't mean to sound brash, I have edited out the statement, I wasn't belittling Angular, neither did I intend to say that Vue is the way better in it's internals over Angular. I wanted to share my experience that learning how to write an app in Vue was faster than Angular.
> In the end, whether you use Angular, React or Vue is really secondary to what you build with it.
yes and no, you are also making a tradeoff at the learning curve of the chosen framework.
> In the end, whether you use Angular, React or Vue is really secondary to what you build with it.
yes and no, you are also making a tradeoff at the learning curve of the chosen framework.
Meh, it says something, but not a lot.
Some tools are harder than others, sometimes because they accomplish more.
Imagine if you'd said "one day into learning about homeopathy, I was able to prescribe homeopathy-things, but after 4-5 weeks of med school I was still taking classes about blood cells."
I'm not actually defending Angular as such, because I am super ignorant about it. Perhaps Angular is a byzantine mess. But there are many great tools which do not have smooth onboarding procedures, which are still valuable because of how they work on complicated projects.
Of course, the BEST tools make easy things easy and hard things possible. Angular might (or might not) make hard things possible, but I think everyone agrees it's not particularly good at making easy things easy.
Some tools are harder than others, sometimes because they accomplish more.
Imagine if you'd said "one day into learning about homeopathy, I was able to prescribe homeopathy-things, but after 4-5 weeks of med school I was still taking classes about blood cells."
I'm not actually defending Angular as such, because I am super ignorant about it. Perhaps Angular is a byzantine mess. But there are many great tools which do not have smooth onboarding procedures, which are still valuable because of how they work on complicated projects.
Of course, the BEST tools make easy things easy and hard things possible. Angular might (or might not) make hard things possible, but I think everyone agrees it's not particularly good at making easy things easy.
>Imagine if you'd said "one day into learning about homeopathy, I was able to prescribe homeopathy-things, but after 4-5 weeks of med school I was still taking classes about blood cells."
I get your point, I removed the last statement, it was incorrect. the thing is, I wanted to state that Vue is super easy to use, now, if it is a toy or a serious framework is upto the programmer to decide :-)
I get your point, I removed the last statement, it was incorrect. the thing is, I wanted to state that Vue is super easy to use, now, if it is a toy or a serious framework is upto the programmer to decide :-)
It says nothing more than Angular has a lot more documentation. Perhaps because Angular has a lot more features.
Please note that I didn't say Angular sucks. I merely pointed out that Vue is easy to learn.
I am hardly an expert on either Angular/Vue to recommend them based on their internals, I stated my experience, of course, the final decision depends on those who choose one framework over another.
I am hardly an expert on either Angular/Vue to recommend them based on their internals, I stated my experience, of course, the final decision depends on those who choose one framework over another.
Try jQuery - even more simple.
I tried jQuery and found it to be more difficult to manage a single page app.
[deleted]
Same story with other "simple" frameworks - they are only simple while apps are simple.
[deleted]
Some clarifications:
1. Angular 2 is not object oriented in the standard meaning of the term: it does not rely on inheritance or polymorphism that much.
But it does rely on classes as the backing structure of your UI components. In other words, they tried to create a platform for creating widgets that compose. And more or less succeeded.
This is a tried and true pattern that has been used to create complex user interfaces since forever. I would wait a while before claiming that this stile is obsolete.
2. Angular 2 is quite functional.
Decorators in Javascript are just higher order functions (like python I guess). They look like like Java's annotations, but work in a completely different way.
They made streams (RxJs) the standard way of working with data.
And pipes are also a functional construct.
3. There are some good things to say about their routing module too, but I have to go.
Anyway, my opinion is that Angular and React address different needs and there is definitely room for both of them.
1. Angular 2 is not object oriented in the standard meaning of the term: it does not rely on inheritance or polymorphism that much.
But it does rely on classes as the backing structure of your UI components. In other words, they tried to create a platform for creating widgets that compose. And more or less succeeded.
This is a tried and true pattern that has been used to create complex user interfaces since forever. I would wait a while before claiming that this stile is obsolete.
2. Angular 2 is quite functional.
Decorators in Javascript are just higher order functions (like python I guess). They look like like Java's annotations, but work in a completely different way.
They made streams (RxJs) the standard way of working with data.
And pipes are also a functional construct.
3. There are some good things to say about their routing module too, but I have to go.
Anyway, my opinion is that Angular and React address different needs and there is definitely room for both of them.
Observables are the most functional JavaScript library/mechanism I've worked with.
I have about two years of experience with both Angular 1 and React. What was truly astounding to me was how while Angular required months of continually poring docs and Stack Overflow threads for every new thing I wanted to do, React took all of a week or two to get pretty comfortable with, and after that minor investment of time I was rewarded with dramatically increased development speed.
I will never go back to using a framework with an approach like Angular. Trying to abstract away the browser environment and have developers learn a whole new set of APIs with nearly the same level of complexity is just a fundamentally bad idea.
I will never go back to using a framework with an approach like Angular. Trying to abstract away the browser environment and have developers learn a whole new set of APIs with nearly the same level of complexity is just a fundamentally bad idea.
Euhm. Jsx and vdom are exactly About abstracting away the browser environment...
Erm, what?
JSX doesn't do any abstraction. Unless you're using React Native, you're writing HTML, just that JSX turns it into `React.createElement(...)` calls.
The VDOM is kind of an abstraction, as React Native can use the same reconciler as React, but the React (web) VDOM is just a tree of HTML DOM nodes that gets diffed against the component rerender output and the changes are applied to the DOM.
JSX doesn't do any abstraction. Unless you're using React Native, you're writing HTML, just that JSX turns it into `React.createElement(...)` calls.
The VDOM is kind of an abstraction, as React Native can use the same reconciler as React, but the React (web) VDOM is just a tree of HTML DOM nodes that gets diffed against the component rerender output and the changes are applied to the DOM.
Ummm.. kabes is right. React is an even bigger abstraction on the browser than angular 1 is. Its just that with React the abstractions are mostly opaque - and with Angular the abstractions are not so opaque ( and maybe sometimes leaky! ).
I think you got that backwards. React's abstractions are transparent, as in the developer doesn't need to "see" them or be aware of them. Your existing web dev knowledge largely applies.
> I think you got that backwards. React's abstractions are transparent, as in the developer doesn't need to "see" them or be aware of them.
He doesn't have it backwards.
He means they're "opaque" abstractions, in the sense that they're the opposite of a "Leaky Abstraction"[0]. A leaky abstraction is one wherein the abstractions below it "leak" up and you have to keep multiple abstractions in your head at once. This happens more with Angular than React.
I see what you mean by calling it a transparent abstraction though, since React's abstractions get out of your way and let you directly think about the lower level. This doesn't really fit with the Leaky abstraction analogy though, but it's a great point.
[0] https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
He doesn't have it backwards.
He means they're "opaque" abstractions, in the sense that they're the opposite of a "Leaky Abstraction"[0]. A leaky abstraction is one wherein the abstractions below it "leak" up and you have to keep multiple abstractions in your head at once. This happens more with Angular than React.
I see what you mean by calling it a transparent abstraction though, since React's abstractions get out of your way and let you directly think about the lower level. This doesn't really fit with the Leaky abstraction analogy though, but it's a great point.
[0] https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
I have to agree with your general point.
However, to me it's not really that Angular is bad in itself, it's more that the alternatives (React/Inferno/Preact combined with redux or MobX) are just superior in so many ways, and by a huge margin.
Once you've done React with TS/TSX, with type checked components all the way, great code completion, incredible performance...it's hard to go back.
Angular's components would be ok if React didn't allow you to declare functional components in just a few lines of code, create HOC to decorate exiting components, etc. Angular's components are certainly better than Angular 1's but when you compare it with what you can do with React it just can't compete.
Honestly, from my experience, there is not a single thing that Angular does better than React and friends. Not a single one. It does things better than Angular 1/Ember/Backbone but that's it.
I think this is a bit like the solar/renewables revolution that is happening in energy. There are more efficient combustion engines, filters and whatnot, but when you compare them with the other paradigm, it falls short.
However, to me it's not really that Angular is bad in itself, it's more that the alternatives (React/Inferno/Preact combined with redux or MobX) are just superior in so many ways, and by a huge margin.
Once you've done React with TS/TSX, with type checked components all the way, great code completion, incredible performance...it's hard to go back.
Angular's components would be ok if React didn't allow you to declare functional components in just a few lines of code, create HOC to decorate exiting components, etc. Angular's components are certainly better than Angular 1's but when you compare it with what you can do with React it just can't compete.
Honestly, from my experience, there is not a single thing that Angular does better than React and friends. Not a single one. It does things better than Angular 1/Ember/Backbone but that's it.
I think this is a bit like the solar/renewables revolution that is happening in energy. There are more efficient combustion engines, filters and whatnot, but when you compare them with the other paradigm, it falls short.
The definitive answer to this question is: it sells itself better to managers. The truth is that for many good and bad reasons, people with decision-making power are scared of dependencies.
My company uprooted a few months of React development because Angular (2) comes with batteries included and we wouldn't have to rely on third-party stuff to fill in the gaps. The amount of stuff you get is... not actually that much, but it's enough to sell it. Of course, our new package.json is just as long, if not longer using Angular than it was before, and I've spent arguably more time doing setup (before @angular/cli stabilised) than I ever did with React. The whole @angular/router situation with module loading is silly, who wants to load modules via strings? Yes, the default batteries-included parts work with each other very well for the basics, but what about power and flexibility?
React could go a long way in this regard just by having a few more official ways of doing things and offering a few tools straight up (a @react/router for instance) while still selling the just-part-of-a-wonderful-ecosystem thing. React is so much better at satisfying real development needs, like the hyper-extensibility via functional composition and the super-DRY code you can get out of it very quickly, that proving its worth in ways that are only superficially important would be well worth it.
My company uprooted a few months of React development because Angular (2) comes with batteries included and we wouldn't have to rely on third-party stuff to fill in the gaps. The amount of stuff you get is... not actually that much, but it's enough to sell it. Of course, our new package.json is just as long, if not longer using Angular than it was before, and I've spent arguably more time doing setup (before @angular/cli stabilised) than I ever did with React. The whole @angular/router situation with module loading is silly, who wants to load modules via strings? Yes, the default batteries-included parts work with each other very well for the basics, but what about power and flexibility?
React could go a long way in this regard just by having a few more official ways of doing things and offering a few tools straight up (a @react/router for instance) while still selling the just-part-of-a-wonderful-ecosystem thing. React is so much better at satisfying real development needs, like the hyper-extensibility via functional composition and the super-DRY code you can get out of it very quickly, that proving its worth in ways that are only superficially important would be well worth it.
This makes me feel sad. As you said, maybe React could do more when it comes to packaging things up. I think Create React App is a good step in that direction but there is still work to be done.
React is a framework. You can call it a library as much as you like, but that doesn't make it a fact.
It comes down to this: What is the relationship between your code and the 3rd party code? Are you calling it, or is it calling you?
If most of the code you write is extending some 3rd party code, e.g. React.Component, and most of the time your code is being executed by the 3rd party code, e.g. as render() calls, then what you have is a framework.
React and its myriad extensions may be as great as people are saying, but this insistence that it is a "library" only serves to make the community look delusional.
It comes down to this: What is the relationship between your code and the 3rd party code? Are you calling it, or is it calling you?
If most of the code you write is extending some 3rd party code, e.g. React.Component, and most of the time your code is being executed by the 3rd party code, e.g. as render() calls, then what you have is a framework.
React and its myriad extensions may be as great as people are saying, but this insistence that it is a "library" only serves to make the community look delusional.
Having toyed with React and Angular for similar amounts of time (~3 weeks of each), I found React whole lot simpler and more understandable. Probably because it only covers the V in MVC. There is so much stuff in Angular that seems like it belongs in the back end and is just duplicated unnecessary on the front end. (It's not like you are likely to write an application in Angular without a server based back end are you?).
We went from jquery to backbone to angular to react and every single time there is a post like yours telling everyone that the future of web development is this new thing. Get real... The future changes every 3 months.
That used to be the case, but now the onus is on you to prove that it is still so.
React is 4 years old.
Vue is 3 years old.
React is 4 years old.
Vue is 3 years old.
As a longtime redux user i am all into Mobx now. It is simpler then redux.
Just mentioning, there is ngrx^1 which is the redux pattern for Angular 2 apps. It also integrates with Observables.
[1]: https://github.com/ngrx/store
[1]: https://github.com/ngrx/store
Problem is you get a cumbersome templating language, extremely verbose component declarations, even more verbose dynamic components and a bunch of other horrible stuff.
In React it is a breeze to make Higher Order Components to connect to a store and it also makes it much easier to separate those smart components from small reusable presentation components.
I have seen people shy away from making smaller components just because Angular makes it so damned painful to make components. It is just easier to stuff everything in a template and copy paste everything around, which leads to a serious case of spaghetti code. I am happy for you if you don't have to work with something like that. I do, and I can tell you it is not nice in any way.
In React it is a breeze to make Higher Order Components to connect to a store and it also makes it much easier to separate those smart components from small reusable presentation components.
I have seen people shy away from making smaller components just because Angular makes it so damned painful to make components. It is just easier to stuff everything in a template and copy paste everything around, which leads to a serious case of spaghetti code. I am happy for you if you don't have to work with something like that. I do, and I can tell you it is not nice in any way.
For most apps, yes I think MobX is easier. However, both of them, combined with React/Preact are hugely superior to Angular.
Angular isn't really OOP. ES6 made JavaScript more like OOP. Typescript just applies types so you can lint your code better.
I am rewriting a React/Redux app I wrote to Angular 2. It's more readable, the control flow is easier to understand, and it's better to work on as a team. Instead of reducers and action creators, I have services separated into their own files. It's much easier for me to manage the work of others on the team.
I am rewriting a React/Redux app I wrote to Angular 2. It's more readable, the control flow is easier to understand, and it's better to work on as a team. Instead of reducers and action creators, I have services separated into their own files. It's much easier for me to manage the work of others on the team.
> Redux, React
Golden cage then eh?
Nah, I'd rather go with polymer instead which is much closer to DOM and is a small library indeed (It's not like redux is working only for react).
And without polyfills I'm looking into 15kb download for users, instead of react + reactDOM behmoth.
I can't wait for someone to add JSX+VDom support for polymer (for the folks who like that approach).
Golden cage then eh?
Nah, I'd rather go with polymer instead which is much closer to DOM and is a small library indeed (It's not like redux is working only for react).
And without polyfills I'm looking into 15kb download for users, instead of react + reactDOM behmoth.
I can't wait for someone to add JSX+VDom support for polymer (for the folks who like that approach).
Agree generally, but the future of web app development is looking more and more like a hundred languages and frameworks. Here's someone who built a 50k LoC web app in Haskell - both client and server in the same codebase - and very happy about it: https://www.reddit.com/r/haskell/comments/610qp7/hiring_pure...
F# has Fable that compiles down to Javascript, OCaml has BuckleScript, and the new kid on the block, ReasonML. I've read about one or more production websites running in these what we'd call esoteric choices. (Add Elm and PureScript to the mix)
There is increasing adoption in the web for both Typed FP through these languages and Untyped FP through ClojureScript. Non-FP communities on the other hand don't seem too keen on the web. Ruby for example has Opal, but with the pace at which Javascript is getting better, porting similar languages just for their familiarity doesn't seem to generate the same kind of excitement as transpiling from a more powerful one.
And once Web Assembly becomes viable and browsers are free from Javascript (except for being the lowest common mass adoption denominator), we'll be able to choose our languages just like we can when programming for any other environment. It'll be a Wild West out there, but in a nice kind of way.
F# has Fable that compiles down to Javascript, OCaml has BuckleScript, and the new kid on the block, ReasonML. I've read about one or more production websites running in these what we'd call esoteric choices. (Add Elm and PureScript to the mix)
There is increasing adoption in the web for both Typed FP through these languages and Untyped FP through ClojureScript. Non-FP communities on the other hand don't seem too keen on the web. Ruby for example has Opal, but with the pace at which Javascript is getting better, porting similar languages just for their familiarity doesn't seem to generate the same kind of excitement as transpiling from a more powerful one.
And once Web Assembly becomes viable and browsers are free from Javascript (except for being the lowest common mass adoption denominator), we'll be able to choose our languages just like we can when programming for any other environment. It'll be a Wild West out there, but in a nice kind of way.
My guess would be that static-typing is what they're trying to add albeit in an OOP form.
Javascript is more of a 'Prototype' based language. They call things 'Object's but I've seen few portions of JS code that actually use OOP in the traditional sense (encapsulation, polymorphism, etc)[0]. Mostly objects are just used for namespaces for finding vars and functions.
Agreed on the frameworks versus libs.
I would recommend that you work on a large codebase in a statically-typed language for a spell. Duck-typing is great for a shell script or blog post but things may be different when refactoring 100k lines of code, finding references, etc.
[0] Yes I know about the JS 'library' 'pattern'. That's more gymnastics than encapsulation.
Javascript is more of a 'Prototype' based language. They call things 'Object's but I've seen few portions of JS code that actually use OOP in the traditional sense (encapsulation, polymorphism, etc)[0]. Mostly objects are just used for namespaces for finding vars and functions.
Agreed on the frameworks versus libs.
I would recommend that you work on a large codebase in a statically-typed language for a spell. Duck-typing is great for a shell script or blog post but things may be different when refactoring 100k lines of code, finding references, etc.
[0] Yes I know about the JS 'library' 'pattern'. That's more gymnastics than encapsulation.
Sorry, but this is one of my technical pet peeves. Polymorphism isn't solely an OOP concept. Every language has polymorphism of some sort. Most have several. Duck typing is an example of polymorphism actually.
You probably mean "inheritance", which is a way to achieve polymorphism, not a synonym for it.
You probably mean "inheritance", which is a way to achieve polymorphism, not a synonym for it.
I think something must have a form before you can say it has many. By your definition a cloud is a polymorph instead of a random shape. If you weaken the definition that much, it takes on a lot less meaning.
The wikipedia page lists three types of polymorphism. Duck typing is linked in the page as another kind of polymorphism. I've seen several other types in the wild, such as link-time polymorphism.
https://en.wikipedia.org/wiki/Polymorphism_(computer_science...
The general idea is that you can have one expression dispatch to many different concrete implementations depending on the context. Virtual function calls is one approach, but C uses function pointers, C++ uses templates, dynamic languages use duck typing, several languages use message passing, and so on.
https://en.wikipedia.org/wiki/Polymorphism_(computer_science...
The general idea is that you can have one expression dispatch to many different concrete implementations depending on the context. Virtual function calls is one approach, but C uses function pointers, C++ uses templates, dynamic languages use duck typing, several languages use message passing, and so on.
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 typescript it makes sense, it looks almost like JavaScript written by somebody that knows what they're doing.
Contrast that to Babel, Closure compiler, and countless others that produce "JavaScript" that reads more like assembler.
Typescript is easy to make back into human readable JS and it's equally easy to slowly transform your JavaScript into typescript.
It's the most forward and backward compatible language transformer I've ran across so I don't appreciate you shitting on it :)
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 typescript it makes sense, it looks almost like JavaScript written by somebody that knows what they're doing.
Contrast that to Babel, Closure compiler, and countless others that produce "JavaScript" that reads more like assembler.
Typescript is easy to make back into human readable JS and it's equally easy to slowly transform your JavaScript into typescript.
It's the most forward and backward compatible language transformer I've ran across so I don't appreciate you shitting on it :)
I agree 100%.
TypeScript is an invaluable, mature technology that provides large productivity boosts to any team that maintains a mid-sized code base.
It plays extremely well with React too, and it's benefits are independent of the tech stack. If you are used to typed components/templates, you will NEVER want to go back.
I would argue that is more important to have static typing in the front-end compared to the back-end in a web-application context. There is more state, lot's of shared entities and unit tests are expensive to write and maintain.
TypeScript is an invaluable, mature technology that provides large productivity boosts to any team that maintains a mid-sized code base.
It plays extremely well with React too, and it's benefits are independent of the tech stack. If you are used to typed components/templates, you will NEVER want to go back.
I would argue that is more important to have static typing in the front-end compared to the back-end in a web-application context. There is more state, lot's of shared entities and unit tests are expensive to write and maintain.
> There is more state, lot's of shared entities and unit tests are expensive to write and maintain.
Good point, but only to an extent: Unit tests boilerplate in dynamic languages that is redundant with static typing is only a (minor) subset of unit tests that you should be writing for your code. Static typing is not an excuse to skip unit tests altogether. I've unfortunately met people claiming exactly that...
Good point, but only to an extent: Unit tests boilerplate in dynamic languages that is redundant with static typing is only a (minor) subset of unit tests that you should be writing for your code. Static typing is not an excuse to skip unit tests altogether. I've unfortunately met people claiming exactly that...
In 2014 I used Typescript on a four month long project. I liked it alot compared to using just JS, however compiling was slow.
I retried using Typescript 1 month ago. Compiling took 6-7 seconds for about 8 files. I could not find a solution and gave up using TS. I hope that's just me doing not good enough research.
I retried using Typescript 1 month ago. Compiling took 6-7 seconds for about 8 files. I could not find a solution and gave up using TS. I hope that's just me doing not good enough research.
Definitely something up with your environment. We compile hundreds of .ts files at my job each build and it only takes a few seconds
Must be something with your setup, tsc is known to be quite fast. Maybe try using it with the watcher? "tsc -w" and you'll never need to compile more than one file at a time.
Typescript with React is necessary for me. I feel like it highly increases my productivity when coding, and it makes it easy to refactor the code.
Plus you can do some cool things like Component inheritance.
I've never tried Flow, but I guess it's practically the same.
Plus you can do some cool things like Component inheritance.
I've never tried Flow, but I guess it's practically the same.
I want to move on from Jquery... Have been learning C# on the back end for the past year and a bit, but now it's time to do the front end.
Looking at both A1 and A2 has confused me, so might just try React and see if that is more compatible with my ageing me. :) Nevertheless, I also really like the looks of Typescript. Could your possibly recommend a(n opinionated) way to get started with the two?
Looking at both A1 and A2 has confused me, so might just try React and see if that is more compatible with my ageing me. :) Nevertheless, I also really like the looks of Typescript. Could your possibly recommend a(n opinionated) way to get started with the two?
I came from C# WPF/Winforms and have to say that Angular 2 is more familiar to me than react.
Of course the whole web stack is a new thing. Angular makes web app development much more productive.
Of course the whole web stack is a new thing. Angular makes web app development much more productive.
Interesting; perhaps I ought to learn both, at least to a certain minimum level - to assess where I'm at with each as such.
I have heard the same from many people. Angular takes the web and makes it look like traditional event driven UI. This is not a bad thing at all, it's how UI works in everything that isn't web.
React is a lot less abstraction and feels more natural to people that started out making UI with plain HTML.
Each has its merits but Angular uses way too much magic for my taste to make the web seem like something it's not. Much like a client side re-imagination of webforms
React is a lot less abstraction and feels more natural to people that started out making UI with plain HTML.
Each has its merits but Angular uses way too much magic for my taste to make the web seem like something it's not. Much like a client side re-imagination of webforms
Thanks - that looks good, will check it out.
It's interesting how OP says people are moving towards more functional-style Javascript, but also dismisses statically typed Javascript. The two work really well together.
I'm convinced functional style is a fad and nothing will change my mind. The style has been around for forever and there's a good reason most languages are still OOP.
We're in the phase of the hype loop where everyone assumes language designers from 15 years ago are idiots. In another few years everyone will be talking about the revival of OOP
We're in the phase of the hype loop where everyone assumes language designers from 15 years ago are idiots. In another few years everyone will be talking about the revival of OOP
Functional style programming is not a fad so much as a different taste. Not everyone will always have the same tastes. It's like peanut butter and chocolate: you can love only one or the other, you can also love both or know that each has different strengths for different needs (projects/desserts).
I can understand if people think it's a fad, but I would expect people who _do_ like it to also like TypeScript :)
That said, if someone thinks language designers from the past are idiots, then they also shouldn't like functional programming, as it's at least as old.
That said, if someone thinks language designers from the past are idiots, then they also shouldn't like functional programming, as it's at least as old.
> nothing will change my mind
you seem a bit committed. is this an emotional thing?
> there's a good reason most...
is there? is this reason related to languages themselves or their use? does it necessarily imply anything specific about "functional style"?
you seem a bit committed. is this an emotional thing?
> there's a good reason most...
is there? is this reason related to languages themselves or their use? does it necessarily imply anything specific about "functional style"?
> nothing will change my mind
This is a HUGE red flag if you're seeking employment long-term in the tech sector.
This is a HUGE red flag if you're seeking employment long-term in the tech sector.
I'm a huge fan of Typescript and not a big fan of Angular. I'm in the same boat as you.
Anders Hejlsberg has done a brilliant thing.
I'm also always a bit sad that Knockout seems to be overlooked a lot. It is not as opinionated but often times exactly the right tool for the job.
Anders Hejlsberg has done a brilliant thing.
I'm also always a bit sad that Knockout seems to be overlooked a lot. It is not as opinionated but often times exactly the right tool for the job.
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.
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
There's literally no reason to not use typescript
I haven't dabbled too much with it, but as still an outsider, Typescript + React honestly seems like a great fit especially to make it even more approachable.
What I like most with React over Angular is that it seems like it cuts to the core of the problem I'm actually trying to solve here. It just feels like a lean, clean, proper solution to the main issue at hand. (this of course helps with dev adoption too because it's easier to find people knowledgeable in lean frameworks, or at worst much quicker to train them)
What I like most with React over Angular is that it seems like it cuts to the core of the problem I'm actually trying to solve here. It just feels like a lean, clean, proper solution to the main issue at hand. (this of course helps with dev adoption too because it's easier to find people knowledgeable in lean frameworks, or at worst much quicker to train them)
I agree also.
I've been using TypeScript with React now for about six months - prior to that I was working on a large React/Redux app written in ES6 using Babel.
In my experience, I have seen a significant increase in my productivity after embracing TypeScript. With the static type support I am fixing/avoiding more errors at 'authoring' time due to intellisense and the VSCode editor flagging what will be compile errors. I am able to refactor across files with a lot less fear.
The advanced types in TS (specifically discriminated unions) make Redux actions and reducer code a lot more maintainable.
Overall I'm very pleased with the transition to TS. I spent time learning Elm last year and simply fell in love with that development experience. For reasons out of my control I cannot use it in production but with my current TS+React approach I can at least get close to what Elm offers.
I've been using TypeScript with React now for about six months - prior to that I was working on a large React/Redux app written in ES6 using Babel.
In my experience, I have seen a significant increase in my productivity after embracing TypeScript. With the static type support I am fixing/avoiding more errors at 'authoring' time due to intellisense and the VSCode editor flagging what will be compile errors. I am able to refactor across files with a lot less fear.
The advanced types in TS (specifically discriminated unions) make Redux actions and reducer code a lot more maintainable.
Overall I'm very pleased with the transition to TS. I spent time learning Elm last year and simply fell in love with that development experience. For reasons out of my control I cannot use it in production but with my current TS+React approach I can at least get close to what Elm offers.
I've never seen anyone conflate TypeScript with angular before GP's comment.
(And I happen to agree with him on angular being confusing and not well designed)
(And I happen to agree with him on angular being confusing and not well designed)
Unfortunately I've met some devs new to SPA stuff and they believe it's either react/flow or angular/typescript. They're being promoted this way in the intro docs on both sides.
Holy smokes, I can't believe how serendipitous this is. I am 5 minutes into a Pluralsight course on Angular 2.
I really like the idea of Typscript, but now... now I guess back to the drawing board on what to learn.
I really like the idea of Typscript, but now... now I guess back to the drawing board on what to learn.
If you're going to switch JS frameworks every time some hipster on HN tells you to, you're never going to get anything done. Use Angular/TS if you like it.
Oh no, I am a desktop and mobile developer, but a recent article on HN made me decide I should dip my toe in web dev just to get a better understanding, so I hit up Pluralsight and was recommended Angular and Typescript.
Then 3 minutes into a Angular 2/Typescript lesson I read that. But point taken.
I think I will stick with Angular and Typescript purely on the basis that it seems to have better integration with .Net core etc. I say all of this from a huge point of ignorance and just what I could gather from an hour or so of research online.
Edit: Changed to single toe.
Then 3 minutes into a Angular 2/Typescript lesson I read that. But point taken.
I think I will stick with Angular and Typescript purely on the basis that it seems to have better integration with .Net core etc. I say all of this from a huge point of ignorance and just what I could gather from an hour or so of research online.
Edit: Changed to single toe.
Typescript works quite well with React, redux etc.
Go with what you like. Take a look at Polymer documentation - it is very easy to pick up and works like a charm. I prefer it to react and angular nowdays.
You will still be able to use redux/whatever with it.
You will still be able to use redux/whatever with it.
Even with SemVer versions it looks really weird to see a new Angular relase branded as 4.0.0.
Angular 1 to Angular 2 made me drop angular entirely, that happened less than 6 months ago I believe.
Just reading Angular 4 gives me the creeps.
Is 4 widely different from 2? How am I suppose to know if you using semver and already have a really bad history?
Angular 1 to Angular 2 made me drop angular entirely, that happened less than 6 months ago I believe.
Just reading Angular 4 gives me the creeps.
Is 4 widely different from 2? How am I suppose to know if you using semver and already have a really bad history?
Most developers should be able to simply update their dependencies and rebuild. A few APIs have been deprecated, but they continue to exist and can be removed at a developer's leisure, per our versioning policy [0]
http://angularjs.blogspot.com/2016/10/versioning-and-releasi...
http://angularjs.blogspot.com/2016/10/versioning-and-releasi...
Lol, if only the real world were that simple. I have an Angular 2.4 project that when updated to 4.0.0 produces about 300+ build time errors (guess you can't access `private` members from templates anymore, it'll be fuuuuuun updating every component and template to work with "backwards" compatible v4), but basically every other version of Angular breaks your code so you just sorta have to live with it.
That didn't change between Angular 2 and Angular 4 - but maybe you changed your build process and are now running AoT with error checking? That would explain why your templates are now error checked and were not before.
Is that enabled by default in 4? I use and identical AOT build process with 2.4 and 4 (ng-cli) and there's no problems building with 2.4
I propose a variant versioning scheme that bumps the MINOR version for backwards incompatibilities and reserves MAJOR version bumps for subjectively "big" changes.
http://www.bayleshanks.com/wiki.pl?proj-sanDiegoVersioning
http://www.bayleshanks.com/wiki.pl?proj-sanDiegoVersioning
This is what the AngularJS versioning scheme was, nearly exactly. Everybody hated it. Hence, semver :)
Huh, thanks for the info! Would you happen to have any hyperlinks to the discussions where people hated on the old scheme? I'd like to read up on this more.
Angular 1 to 2 was a complete rewrite with a change of paradigm, but 2 to 3 then 4 is just because semver (i.e. there may be some breaking changes, it's not 100% backward compatible).
Yeah, but why?
With all people complaining about Java, we don't have to deal with this shit so often.
Most breaking changes I see on the JavaScript ecosystem seem like mostly cosmetic. It has been a rough road trying to make decisions on tech that won't get stale quickly and have support dropped in a 1-2 year frame.
Angular is really one of the worst offenders in this regard. What was so fundamentally broken with Angular v1's api that could not just be worked internally and incremented?
It also has ramifications which are pretty dire in my opinion. We have an app written with Ionic 1, so I go check out Ionic 2 see what's going on, and oh look such shiny things, how do we migrate? Nope, full rewrite of course.
There are some decision makers in these teams which are completely disregarding the fact they are burning through several work hours of people around the globe without real value.
Stop breaking things because new. Fine, use semver, but don't you change that first digit lightly, it hurts when you do.
With all people complaining about Java, we don't have to deal with this shit so often.
Most breaking changes I see on the JavaScript ecosystem seem like mostly cosmetic. It has been a rough road trying to make decisions on tech that won't get stale quickly and have support dropped in a 1-2 year frame.
Angular is really one of the worst offenders in this regard. What was so fundamentally broken with Angular v1's api that could not just be worked internally and incremented?
It also has ramifications which are pretty dire in my opinion. We have an app written with Ionic 1, so I go check out Ionic 2 see what's going on, and oh look such shiny things, how do we migrate? Nope, full rewrite of course.
There are some decision makers in these teams which are completely disregarding the fact they are burning through several work hours of people around the globe without real value.
Stop breaking things because new. Fine, use semver, but don't you change that first digit lightly, it hurts when you do.
I'll probably try it.
But man, am I getting jaded about all this javascript framework stuff. Every 6 months stuff breaks, every 2 years there's a huge shift.
The problem with javascript I've been facing is value. Time and effort doesn't always correlate to what I get in the other end. In fact, I can say when building, going single-page is a time sink.
And it's almost always a mistake to go SPA first. Using a django or a rails lets you get the basics and data flow nailed down early on. Get into a framework too early and have a need to change something? Have fun explaining to your manager/client how costly it is to do a "simple" modification to a JS app when you have to throw the state you built it upon out the door.
What I want is a system tightly coupled into a server-side framework like a Django or a Rails that degrades gracefully and I only have to program the interactivity one time. Something that'd plop right into the asset pipeline/django compressor so I don't have to go outside of the framework to build.
Hundreds of hours of my life have been spent chasing this dream of sharing server side code with client side JS frameworks. That's what I need.
Meteor didn't do it for me. As for rendr, I've done stuff better with backbone/express in-house. As of 2017, I get my best bang for the buck using django and pjax. No joking, I went from full DRF + Backbone Marionette -> to plain old jquery and pjax and couldn't be happier.
All these new build tools (grunt, gulp, webpack... come on), ES versions (I was ok with ES5). None of these things are helping me ship stuff ahead of / on time and correctly. They're creating an even larger gap between the server side data, logic and templates and the JS interactivity.
If anyone is listening, I'd love to have a well-supported opinionated distribution of django or rails that just renders forms, tables, etc. with angular/react/etc. and degrades gracefully.
But man, am I getting jaded about all this javascript framework stuff. Every 6 months stuff breaks, every 2 years there's a huge shift.
The problem with javascript I've been facing is value. Time and effort doesn't always correlate to what I get in the other end. In fact, I can say when building, going single-page is a time sink.
And it's almost always a mistake to go SPA first. Using a django or a rails lets you get the basics and data flow nailed down early on. Get into a framework too early and have a need to change something? Have fun explaining to your manager/client how costly it is to do a "simple" modification to a JS app when you have to throw the state you built it upon out the door.
What I want is a system tightly coupled into a server-side framework like a Django or a Rails that degrades gracefully and I only have to program the interactivity one time. Something that'd plop right into the asset pipeline/django compressor so I don't have to go outside of the framework to build.
Hundreds of hours of my life have been spent chasing this dream of sharing server side code with client side JS frameworks. That's what I need.
Meteor didn't do it for me. As for rendr, I've done stuff better with backbone/express in-house. As of 2017, I get my best bang for the buck using django and pjax. No joking, I went from full DRF + Backbone Marionette -> to plain old jquery and pjax and couldn't be happier.
All these new build tools (grunt, gulp, webpack... come on), ES versions (I was ok with ES5). None of these things are helping me ship stuff ahead of / on time and correctly. They're creating an even larger gap between the server side data, logic and templates and the JS interactivity.
If anyone is listening, I'd love to have a well-supported opinionated distribution of django or rails that just renders forms, tables, etc. with angular/react/etc. and degrades gracefully.
I'm actually really excited about Angular "2+" for something you've expressed here. I know that a React developer won't see this the same way, but I really feel like it's come down (for me at least) to either Angular "2+" or React - and whatever the reason someone is going to be on one side of the fence or the other. I've written smallish to largish programs in Vue, React, Ember, Polymer - and in all of those cases tried, wherever possible to do so in RXJS and Typescript. When everything else shakes out, I'm finding that nothing is coming close to the RXJS and Typescript combination "sweet spot". There have been various attempts to make a lot of the other frameworks "typescript friendly" but it's just nowhere near.
So why is Rx and Typescript so important to me? Well specifically those two are kind of like the drug that once you try them, you literally can't go back. I've been wanting this level of type checking for 10 years on the front end. I am not willing to lose it now. As for Rx, it's the one true way to do async flows. Promises and Callbacks just end up creating large pyramidic code.
So why is Rx and Typescript so important to me? Well specifically those two are kind of like the drug that once you try them, you literally can't go back. I've been wanting this level of type checking for 10 years on the front end. I am not willing to lose it now. As for Rx, it's the one true way to do async flows. Promises and Callbacks just end up creating large pyramidic code.
I think Typescript can sometime have a mind of its own, but it's certainly an enrichment and with Rx everything just falls into place.
At this point it's hard to ignore that all the UI libraries are just paradigms and patterns, and how we use them is getting less important. These days I just want to write Component-style UI code, and I'll be fine.
Similarl things can be said about RxJS, but I think since it's a different level of abstraction, it will hit much harder, once it gains more traction. And it's already building up a solid community much faster than before. the only thing standing in the way of people learning RxJS is the same as Angular / Vue / React. It's scary and there's a lot of fatigue still. I hope that this year is thus going to be even better for teaching. ^^
Tldr; RxJS is going to be huge, if we can teach it more and JS fatigue calms down.
At this point it's hard to ignore that all the UI libraries are just paradigms and patterns, and how we use them is getting less important. These days I just want to write Component-style UI code, and I'll be fine.
Similarl things can be said about RxJS, but I think since it's a different level of abstraction, it will hit much harder, once it gains more traction. And it's already building up a solid community much faster than before. the only thing standing in the way of people learning RxJS is the same as Angular / Vue / React. It's scary and there's a lot of fatigue still. I hope that this year is thus going to be even better for teaching. ^^
Tldr; RxJS is going to be huge, if we can teach it more and JS fatigue calms down.
We've got some really cool ideas to make Rx really first class in Angular. It's already pretty deeply integrated, but with a little work, it'll be awesome.
What are they? I've been developing with the @ngrx suite, and it's been mostly pretty smooth, what more do you want? I would like to see a piece of documentation that lays out explicitly what happens when you pass around Observables. Hot ones, cold ones, when the auto-unsubscribe clicks in, whether
this.property$ = some_observable();
this.property$.subscribe(fn);
definitely agreed! It's become one of the biggest "advocators", so to speak. But I think people will want to learn it as a default, async primitive in JS as promises now are. Not saying support from Angular and other projects and also companies doesn't help, since it makes it look less like a "scary, new thing", but I think more people should start to teach it's benefits to be frank and blunt about it ;)
absolutely. we're 100% invested in Rx, and more than anything else I'd like to see the Observable type standardized.
Cyclejs currently seems to be the only sane observable/typescript based framework to me.
Didn't GWT provide you with type checking on the frontend 10 years back ?
Still works, incidentally.
Still works, incidentally.
Yep, I realized and regretted saying that after I posted that - there certainly are typed languages on the front end, but at some point or another they are all very disconnected from Javascript itself. I feel with Typescript you get both a user-configurable level of type checking combined with the cowboy coder flexibility of Javascript - I guess that's what I was aiming to say. Whether that's a good thing to others is up to them however. ;)
Yep. It was horrible to use, but it had type checking, sure. So did Objective-J, from around the same time period, fwiw.
You should probably check out CycleJs. Rx like and TypeScript.
How does RxJS solve the problem of virtual DOM?
By itself it doesn't really have anything to do with it; they're solutions to completely different problems. (That said, I'm not quite sure what you mean by the "problem" of virtual DOM?)
What _is_ interesting, though, is having your virtual DOM be the output of a reactive stream, and having a virtual DOM library use that to update the actual DOM. This is the approach Cycle.js takes: https://cycle.js.org/
What _is_ interesting, though, is having your virtual DOM be the output of a reactive stream, and having a virtual DOM library use that to update the actual DOM. This is the approach Cycle.js takes: https://cycle.js.org/
Intercooler.js may be along the lines of what you want, when combined with partial views.
You should try ClojureScript. Much simpler tooling (native tooling on top of Google Closure), nice integration of server and client side code.
We are not quite at the point of using NodeJs on the backend normally (and honestly the JVM is 100x better) but you can share the language.
You want get a django or rails like app at the moment.
We are not quite at the point of using NodeJs on the backend normally (and honestly the JVM is 100x better) but you can share the language.
You want get a django or rails like app at the moment.
Look into polymer. Let's you do server side rendering then use custom web components for the widgets needing interactivity.
I found building sites this way refreshing.
I found building sites this way refreshing.
Yeah, I've been using polymer for quite a bit of time. It is very easly to pick up, small, fast and interoperable with everything else.
Preach brother. I've been saying the same thing for years now after a similar experience moving from an Angular SPA to a Django + Pjax app. I noticed an order of magnitude increase in productivity.I can't imagine going back now.
What were your problems with meteor? Because that sounds exactly like what you're asking for
> sharing server side code with client side JS
ever looked into clojurescript?
ever looked into clojurescript?
I'm so out of the loop… Feels like a week ago everyone talked about how cool and performant v2 will be when it's finally out of the beta and officially ready for production, and now there is v4 release.
What's going on with versions?
What's going on with versions?
"Angular 1" is now known as Angular.js and is effectively at the end of its line.
Angular 2+ is now simply Angular. All new releases follow a naming of version X.Y.Z where X indicates breaking changes, Y non-breaking new features, and Z is bug fixes.
Version 3 is being skipped over due to poor naming of the related Angular Router lib.
http://angularjs.blogspot.com/2016/12/ok-let-me-explain-its-...
Angular 2+ is now simply Angular. All new releases follow a naming of version X.Y.Z where X indicates breaking changes, Y non-breaking new features, and Z is bug fixes.
Version 3 is being skipped over due to poor naming of the related Angular Router lib.
http://angularjs.blogspot.com/2016/12/ok-let-me-explain-its-...
It seems that lockstep versioning makes semantic versioning less meaningful
A major version bump for a module could signal a breaking change, or it could just be due to the packages it's locked to having had a breaking change
A major version bump for a module could signal a breaking change, or it could just be due to the packages it's locked to having had a breaking change
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.
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?
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:
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.
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
apple-1.1 => banana-1.1 => carrot-2.0
=> broccoli-1.3 => carrot-1.1
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.
There is also AngularDart, which has forked and isn't following the same numbering scheme:
https://webdev.dartlang.org/angular
https://webdev.dartlang.org/angular
I thought upgrading from 2.x.x to 4.x.x shold break something according to SemVer. So why "it's backwards compatible with 2.x.x"?
You've got it backwards. If you make a breaking change, semver requires you to bump the version number. There is absolutely nothing in the semver spec requiring you to make a breaking change when you bump the version number.
The spec only specifies one of those directions, you're free to bump the major version for any change if you feel like it. Doing so would make your versioning scheme much less useful, but it's not actually breaking the semver rules.
The spec only specifies one of those directions, you're free to bump the major version for any change if you feel like it. Doing so would make your versioning scheme much less useful, but it's not actually breaking the semver rules.
There's also nothing in the spec that stops you from taking a very conservative view of what constitutes a "breaking change". There are many types of changes that may be backwards compatible and you're mostly sure shouldn't break anything, but you want to signal that it might just in case. What constitutes a breaking change that warrants a major version bump is a subjective problem left to project maintainers.
Totally agree, and I think that's what's going on with Angular. Bumping the major version for a set of modules also communicates that you really should be using 4.x of all these modules together rather than mixing and matching with 2.x, even if some subset of them are technically backwards compatible.
I think the distinction is that a breaking API change breaks some of your code, a backward incompatible change breaks your entire codebase -- i.e., fix a few method signatures vs refactor your entire codebase.
Damn... I was really hoping for Angular 16 next year...
16 will be skipped for...no reason what so ever.
They should just name with a year. So in 2018 you'd know that Angular 2017 is so last year…
All of the Angular modules were 2.x.x with exception to the router, which was version 3.x.x.
So to keep all of them at the same major version, they pushed everything to version 4.
Also, the jump from AngularJS (1) to Angular 2 was drastically different. Going from 2 to 4 however is much less significant in terms of breaking changes.
You won't have to relearn hardly anything if you already know 2.
So to keep all of them at the same major version, they pushed everything to version 4.
Also, the jump from AngularJS (1) to Angular 2 was drastically different. Going from 2 to 4 however is much less significant in terms of breaking changes.
You won't have to relearn hardly anything if you already know 2.
SEMVER - Semantic Versioning - http://semver.org/
Aka when in doubt, increment leftmost, also we won't tell you wether we did a complete conceptual overhaul or just found a corner case that is provably incompatible. And I really thought it would be good.
Not exactly semver either, Angular 4 is backward compatible with 2.x.x. Following semver would mean it should continue to be in 2 series
It makes breaking changes that might break some users. That is following semver. Semver doesn't follow backward compatibility in the major number, it follows potential breaking changes that will impact downstream consumers.
It is explained in the first sentence of the article.
semver
increasingly, angular seems less like a tool I'd use and more like a platform that exists to sell typescript and generally influence the web.
in 2017 I'm curious why I'd pick angular over vue for a web-based project, if anyone has insight. not over "x js framework" -- over vue specifically. vue 2 is pretty much exactly what I wanted angular 2 to be.
in 2017 I'm curious why I'd pick angular over vue for a web-based project, if anyone has insight. not over "x js framework" -- over vue specifically. vue 2 is pretty much exactly what I wanted angular 2 to be.
First of all, congrats to the Angular team.
I'll say personally I've never been a fan of Angular, but I think if you want Java/J2EE-ish all-encompassing component model and decorator-/annotation-based GUIs, it certainly is a very strong contender (though kindof the thermonuclear option and absurdly complex IMHO, at least if you have some prior web development experience). I think Google's track record wrt. long-term maintainance isn't half bad really (GWT and closure tools have been around for a long time).
That said, I've recently talked to recruiters, and was told Angular has already peaked as the go-to framework for enterprise MVC web apps, and is replaced by React and others (and I'm assuming Angular wasn't all that much used outside that demographic because of the heavy setup and on boarding/buy-in).
In the course of JavaScript generational cycles I'm expecting we're bound to re-discover "evergreen" web apps, those being characterized by lack of heavy build pipelines, simple browser-refresh driven development cycles, and straightforward use of web forms (+ maybe components).
An open question for me is what about TypeScript, eg. since Angular has been a major driver/user behind its type-heavy approach, will it suffer along with Angular?
I'll say personally I've never been a fan of Angular, but I think if you want Java/J2EE-ish all-encompassing component model and decorator-/annotation-based GUIs, it certainly is a very strong contender (though kindof the thermonuclear option and absurdly complex IMHO, at least if you have some prior web development experience). I think Google's track record wrt. long-term maintainance isn't half bad really (GWT and closure tools have been around for a long time).
That said, I've recently talked to recruiters, and was told Angular has already peaked as the go-to framework for enterprise MVC web apps, and is replaced by React and others (and I'm assuming Angular wasn't all that much used outside that demographic because of the heavy setup and on boarding/buy-in).
In the course of JavaScript generational cycles I'm expecting we're bound to re-discover "evergreen" web apps, those being characterized by lack of heavy build pipelines, simple browser-refresh driven development cycles, and straightforward use of web forms (+ maybe components).
An open question for me is what about TypeScript, eg. since Angular has been a major driver/user behind its type-heavy approach, will it suffer along with Angular?
Rails, bootstrap, react when necessary on portions of pages. Use regular links again - use regular forms again, remember - AJAX can be cool, but it doesn't have to be the whole app.
Remember when the server generated HTML? You could middle click a link!
I'll even use normal browser history, instead of re-implementing it in Javascript for my app (with bugs).
Remember when the server generated HTML? You could middle click a link!
I'll even use normal browser history, instead of re-implementing it in Javascript for my app (with bugs).
I tried react initially. As a Java developer, I needed types, rxjs, modules without the Hassel of webpack configs.
Angular provides consistent structure to your app. With angular-cli, consistent interface to front-end development. Having ported it from Ember, IMO the cli interface should be standard across all front-end frameworks.
I see it as microkernel like framework for front-end development. In Java land, we have OSGi standard for modular software component development, angular has sort-of similar design.
The only confusing part is NgModule, the team should rename angular modules as NgBundle - which consists of native TS modules.
I read somewhere, angular team is working on material widget library, please make style-less components with theming support.
Angular provides consistent structure to your app. With angular-cli, consistent interface to front-end development. Having ported it from Ember, IMO the cli interface should be standard across all front-end frameworks.
I see it as microkernel like framework for front-end development. In Java land, we have OSGi standard for modular software component development, angular has sort-of similar design.
The only confusing part is NgModule, the team should rename angular modules as NgBundle - which consists of native TS modules.
I read somewhere, angular team is working on material widget library, please make style-less components with theming support.
I'm using Knockout JS along with a micro hash-tag routing framework for my SPA. Couldn't be happier. Knockout JS is mature, and doesn't change. Yet there's still PR's that fix things here and there.
JS frameworks these days are such job creators. Which is great for consulting, but I don't want such mutability for my own products.
JS frameworks these days are such job creators. Which is great for consulting, but I don't want such mutability for my own products.
Using Angular2 for 10 months now. Can say it has been a pleasure to work with it. Sure there are some problems - but it is open source. Free. Can't be complaining about stuff you get for free ;)
One thing - name of the framework should have been something different. At first we thought it is going to be called Angular2 and later it became just Angular. You can imagine that whole community will have to rename their libraries and etc.
In overall, big thank you from our frontend team for giving us a great framework
One thing - name of the framework should have been something different. At first we thought it is going to be called Angular2 and later it became just Angular. You can imagine that whole community will have to rename their libraries and etc.
In overall, big thank you from our frontend team for giving us a great framework
Just reading about 'renderModuleFactory' in this announcement makes it sound enough like Java EE bullshit that I want to stay far away from it.
> Just reading about 'renderModuleFactory' in this announcement makes it sound enough like Java EE bullshit that I want to stay far away from it.
it is old school JEE, which is ironic as JEE,Spring and all that bullshit are trying to move far away from what they used to be. All that complexity has a cost.
it is old school JEE, which is ironic as JEE,Spring and all that bullshit are trying to move far away from what they used to be. All that complexity has a cost.
Just a quick note to those who would like to play around with it..
Install the latest version of the CLI: npm install -g @angular/cli
And then run: ng new project-name --ng4
The "--ng4" flag is currently required, as it doesn't yet install ng4 by default.
Install the latest version of the CLI: npm install -g @angular/cli
And then run: ng new project-name --ng4
The "--ng4" flag is currently required, as it doesn't yet install ng4 by default.
New release of CLI is running final checks in CI. Should release momentarily!
Edit: it's released! npm install @angular/cli
Edit: it's released! npm install @angular/cli
Congratulations to the team. I have been using Angular 2 for our internal operations dashboard.
I am seeing : platform-browser / platform-server namespace. Can we expect platform-android, platform-ios, platform-jvm ?
Looking at the angular compiler pipeline, with AST this should be possible ?
I am seeing : platform-browser / platform-server namespace. Can we expect platform-android, platform-ios, platform-jvm ?
Looking at the angular compiler pipeline, with AST this should be possible ?
The first two are pretty well covered by our friends at Ionic and NativeScript.
The last one, well, that's a bit more complicated. Let's just say that sort of thing is on the radar.
The last one, well, that's a bit more complicated. Let's just say that sort of thing is on the radar.
Angular is being overengineered, why for example do you need dependency injection having modules system. It's better to go with VueJS, it can do all that is needed being simple, fast, lightweight and VERY developers friendly.
I wonder what Rob Eisenberg formerly of Angular and now with Aurelia.io would have to say about v4?
I suspect there's going to be a bit of pushback to this acceleration in numbering.
Major release every 6 months, 2 major version deprecation policy.
There was definitely some initial pushback, but we hope to demonstrate with this release that it's a) not that scary and b) good for both developers and users.
Most devs should see significant reduction (upwards of 50%) in their output builds. We think that's a reasonable trade off for a couple hours of work to upgrade.
In this release, most developers should be able to simply update their dependencies and rebuild. We're aiming for regular, planned, minimal changes, rather than Big Bang style change from AngularJS -> Angular.
There was definitely some initial pushback, but we hope to demonstrate with this release that it's a) not that scary and b) good for both developers and users.
Most devs should see significant reduction (upwards of 50%) in their output builds. We think that's a reasonable trade off for a couple hours of work to upgrade.
In this release, most developers should be able to simply update their dependencies and rebuild. We're aiming for regular, planned, minimal changes, rather than Big Bang style change from AngularJS -> Angular.
I think you're right. Probably something similar to how they changed Java from the 1.x to the 5, 6, 7... series. It did take a couple years for people to stop saying 1.5 though, as I suspect will be the case for people saying "Angular2" trying to find a way to distance themselves from Angular 1 but not really caring if some component was written for 4, 5, etc..
you'll find that generally, we refer to it as "Angular" or "Angular 4.0" - officially, AngularJS is 1.x.
We'll see how it shakes out, but so far our community has been pretty awesome about it.
We'll see how it shakes out, but so far our community has been pretty awesome about it.
If my experience is any indication of general industry practices, businesses are very risk averse when it comes to upgrading libraries or dependencies as it usually triggers costly regression testing. At my current gig, we still run on angular 1.3.something and there is no way the business will allow us to migrate to v2 as we struggle to justify exactly what added value will we get from essentially a top-down rewrite.
> there is no way the business will allow us to migrate to v2
We as engineers should not accept this. Business should not be involved in technical decisions like library upgrades. Business and engineering should negotiation development scheduling, nothing more. This means what new features are worked on, what bugs are prioritized, etc. All remaining time should be up to engineering's discretion.
And if business has you working on features full-time, then that's a (really) bad business and you should find a more acceptable company to work for.
We as engineers should not accept this. Business should not be involved in technical decisions like library upgrades. Business and engineering should negotiation development scheduling, nothing more. This means what new features are worked on, what bugs are prioritized, etc. All remaining time should be up to engineering's discretion.
And if business has you working on features full-time, then that's a (really) bad business and you should find a more acceptable company to work for.
Except when said library upgrades send costs spiraling out of control, because the refactor took 3x longer than anticipated...
I dont't disagree with you, but after some years in the industry I noticed certain patterns in how businesses operate: as they get larger and stable they get more risk averse and more in love with legacy systems. But I never worked for Google or the likes, so maybe somewhere out there, the grass is greener :)
I'd have to say I agree with you generally in "library upgrades" but I don't consider AngularJS and Angular "2+" as the same library.
similar to your case, our product was also built on angular 1.x. However, we (and the product as well) have had a better fate in which we successfully convince the big guy to use React for any new feature that we want to build or code we need to fix. Now, we are having more and more react components, and lesser angular 1 code every day.
All hiring posts that are looking for "Angular 2" developers are now outdated and have to be switched to Angular 4 :) And recruiters will probably not understand that the difference between ng2 and ng4 is minor, while the difference between ng1 and ng2 is night and day.
I can see it now
Required: 3+ years experience building Angular 4 apps
Required: 3+ years experience building Angular 4 apps
And the person who eventually gets hired points out that this is impossible, he could not possibly have made more than the two years he has on Angular 3. And he must be really ahead of the curve, all the other losers who applied barely got that much on 2...
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)
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)
[deleted]
I really hope the Angular team find their path again, because it seems like they've lost it a long time ago!. I remember learning Angular 1, 5 years ago, it was an awesome experience but now ... let's say I wish them the best for real.
Can anyone from Angular team please make integration with Google Cloud Endpoints, or at least show how it's done? the official documentation is for AngularJS 1.x: https://cloud.google.com/solutions/angularjs-cloud-endpoints...
Hi wiradiksuma. Ive filed a request internally to update the docs. Feel free to email me at [email protected] to get status updates.
What is one supposed to type into Google when trying to differentiate from Angular 1 and Angular >= 2? I used to type Angular2 but posts going forward may mention Angular4 now and not show up.
Angular 2+ is just Angular.
Angular 1.x is AngularJs.
If you are trying to differentiate the two in google, add -AngularJS to the end of the search. Also pretty good bet you're going to want to search within the last year for up to date posts.
Versioning and Releasing Angular http://angularjs.blogspot.com/2016/12/ok-let-me-explain-its-...
Angular 1.x is AngularJs.
If you are trying to differentiate the two in google, add -AngularJS to the end of the search. Also pretty good bet you're going to want to search within the last year for up to date posts.
Versioning and Releasing Angular http://angularjs.blogspot.com/2016/12/ok-let-me-explain-its-...
Honest question,
How does Angular make my life easier or better in some way?
I currently use Python and Pyramid as a framework. Mako templates. And SQLAlchemy for database interactions.
How is any of this really better?
How does Angular make my life easier or better in some way?
I currently use Python and Pyramid as a framework. Mako templates. And SQLAlchemy for database interactions.
How is any of this really better?
Angular is different. It is not concerned with the server side at all. It's just about so-called Single Page Applications.
This SPA would typically talk to services via "AJAX" (though probably with JSON). These services could be implemented using any technology.
This SPA would typically talk to services via "AJAX" (though probably with JSON). These services could be implemented using any technology.
This still doesn't describe how Angular is objectively "better." In fact, because it requires Javascript just to render HTML, it is objectively worse than straight up HTML delivered from a server-side solution.
> This still doesn't describe how Angular is objectively "better."
Of course. Because it isn’t. It’s not worse either. It’s different. It’s a completely different approach to creating web applications.
Everyone has different criteria to meet. Working without JavaScript usually isn’t one with modern web applications.
Of course. Because it isn’t. It’s not worse either. It’s different. It’s a completely different approach to creating web applications.
Everyone has different criteria to meet. Working without JavaScript usually isn’t one with modern web applications.
To be clear, I don't eschew JavaScript. Of course you need that for applications. JS stuff goes into a Mako template where I import and call the JS when I need it.
This has the added benefit of extremely small page sizes. Nothing gets loaded globally. Every page has only and exactly what it needs to function properly.
I'm just wondering if I am that much of a dinosaur and I need to invest the time into learning some of these frameworks to be competitive on the market in the future.
What I do works well. It's fast, it's scalable, and I'm very fast at developing with that toolchain. The code is clean, clear, well-organized, and modular. Anyone who knows Python, SQL(Alchemy), and JavaScript can pick it up and work with it.
I can work on any different part of an application without worrying about if it might break something elsewhere. I feel like the patterns I've gotten comfortable with are kind of a sweet spot between micro-services and monolithic. My apps are technically monoliths, but the various modules are clearly isolated.
I'm in my late 30s now, and I want to keep up and not turn into one of those old guys who refuses to stay current. I'm genuinely curious what the value proposition is, outside of learning a new paradigm for its own sake. There's always value in learning new ways to solve problems you already have a good handle on.
But outside of those things, is there some secret magic I'm missing out on?
This has the added benefit of extremely small page sizes. Nothing gets loaded globally. Every page has only and exactly what it needs to function properly.
I'm just wondering if I am that much of a dinosaur and I need to invest the time into learning some of these frameworks to be competitive on the market in the future.
What I do works well. It's fast, it's scalable, and I'm very fast at developing with that toolchain. The code is clean, clear, well-organized, and modular. Anyone who knows Python, SQL(Alchemy), and JavaScript can pick it up and work with it.
I can work on any different part of an application without worrying about if it might break something elsewhere. I feel like the patterns I've gotten comfortable with are kind of a sweet spot between micro-services and monolithic. My apps are technically monoliths, but the various modules are clearly isolated.
I'm in my late 30s now, and I want to keep up and not turn into one of those old guys who refuses to stay current. I'm genuinely curious what the value proposition is, outside of learning a new paradigm for its own sake. There's always value in learning new ways to solve problems you already have a good handle on.
But outside of those things, is there some secret magic I'm missing out on?
"These changes reduce the size of the generated code for your components by around 60% in most cases"
Sorry angular team, it just mean you did poor job at first.
Sorry angular team, it just mean you did poor job at first.
Will I be able to build on this platform with pure JavaScript (rather than TypeScript)? What kept me from Angular 2 adoption was its emphasis on TS.
If you don't like TS stay away from Angular. In fact, just stay away from Angular, even if you like TS. You will save yourself a lot of headaches...but hey with Angular you might be able to hire some cheap/junior programmers who are familiar with OOP or move some backend guys who like C#/Java to do frontend.
Does anyone have an good example app using modern Angular?
Looks like cool features, but I have a hard time envisioning on how they all work together.
Looks like cool features, but I have a hard time envisioning on how they all work together.
Check out angularexpo.com and madewithangular.com
Well, less than half of the site on madewithangular actually have any "ng-app" or angular strings in their web page when they are not in 404.
I was suprised, so I made random check, and it was true as far as I can tell.
Plus for fun I randomly checked, also among the remaining sites: very few are «angular powered» on the whole domain. Making the claim these people use angular even less solid.
Please feel free to contribute to my script checking your claims if you feel I missed some true positive
https://gist.github.com/jul/7056d4535da42103407ba2424e47d507
after all no detection tools can claim to be 100% accurate.
I was suprised, so I made random check, and it was true as far as I can tell.
Plus for fun I randomly checked, also among the remaining sites: very few are «angular powered» on the whole domain. Making the claim these people use angular even less solid.
Please feel free to contribute to my script checking your claims if you feel I missed some true positive
https://gist.github.com/jul/7056d4535da42103407ba2424e47d507
after all no detection tools can claim to be 100% accurate.
The monolithic javascript framework era is over and has been.
Anyone choosing monolithic over microframeworks/libraries will regret it over time, that time may be as quick as 6 months, right around launch and switching to maintenance. Pour some out for the poor bastards that have to support legacy versions of these frameworks.
Anyone choosing monolithic over microframeworks/libraries will regret it over time, that time may be as quick as 6 months, right around launch and switching to maintenance. Pour some out for the poor bastards that have to support legacy versions of these frameworks.
Angular is so 8 months ago.
Angular seems to have hard time but it is still the most popular Frontend framework:
https://jobsquery.it/stats/frontend-frameworks/group
https://jobsquery.it/stats/frontend-frameworks/group
Yep, 3k Angular job openings looks good:
https://jobsquery.it/jobs;page=1;tags=AngularJs;sortBy=PUBLI...
https://jobsquery.it/jobs;page=1;tags=AngularJs;sortBy=PUBLI...
Stay away from this abobination, it will make your project unnessary complex, there are better alternatives.
Is it relevant anymore ? Most of the javascript developers I know are working with Ember.
Ember? I thought that died after react came out.
react? I thought that died after Vue.js came out.
[deleted]
Vue.js? I thought that died when Angular 4 came out.
Angular 4? I thought that died when Scala.js came out
Scala.js ? I thought that died when inferno came out ?
inferno? I thought that died when riot came out.
riot? I thought that died when Rakun.js came out.
That's why I stick to jQuery 1.2. Ain't neveh goin' nowheh!
I can't wait to retire.
I don't know anyone using Ember. You surely must mean React?
Ember? What the What? Isn't React the cool new kid on the block?
I was wondering the opposite.
Is Angular ever going to support web standards such as web components?
You can already use most simple web components in Angular without issues - as far as Angular is concerned, it's just another DOM element.
We also support native (or emulated) Shadow DOM out of the box.
It gets a little more interesting when you start interleaving Angular and WebComponents, but one of the deprecations in 4.0 (regarding Angular's use of the <template> tag) is squarely aimed at making that easier in the future.
We also support native (or emulated) Shadow DOM out of the box.
It gets a little more interesting when you start interleaving Angular and WebComponents, but one of the deprecations in 4.0 (regarding Angular's use of the <template> tag) is squarely aimed at making that easier in the future.
Thanks, what I was asking is when are Angular components going to be Web components?
It's unlikely we'll ever have developers write Custom Elements directly - that said, the View Engine rewrite we just did gives us the ability to (theoretically) have our compiler output Custom Elements. We're investigating some use cases on this.
Two words: Code. Bloat.
I just want to say thank you for angular 2. I still code in 1 mind you, but now that ecosystem is stable and mature, and I can just get my stuff done while ignoring all the hip trends.
why does it feel like I have to be a developer OF angular in order to create an app. too many of the design choices they made manifest themselves in MY code, a framework isn't supposed to do this.
I think opinionated framework should do this. This way there is only one way of doing things - angular way.
So when all the angular developers quit and new ones join they can semi-understand the code because it's written in "angular way".
So when all the angular developers quit and new ones join they can semi-understand the code because it's written in "angular way".
Can't wait for Angular 29!!!!!!!1
Man y'all niggas is trippin. Angular changed completely with angular 2.0. If you say 2 and 1 are the same you are plain lyin' to yourself. I am not kidding. They are not the same thing, and should not be named the same. Likewise, pretending that 1+2 = 4 is just fool's talk. I don't care anymore for angular; Having your app-state in-sync with your code is great, but changing your whole paradigm every 6 months because the powers-that-be told you that your major version number _should_ increment for no apparent reason? You must be out of you got-damn mind. So fuck angular, and fuck all that bullshit that comes with it. Downvote me all you want, you guys gotta get a grip on reality, or let go completely, because this honey-do-good-half-assed-bs is getting you absolutely nowhere.
As I said in another comment the fun part is less than 50% example on madewithangular actually use angular on advertised pages, and even the true positive on one page do not imply a significative part of the web domain is powered by angular.
Check by yourself. (Condition for tagging a page made with angular is no 40X/50X/60X and m/(angular|ng-app)/ in html feel free to correct me if I was wrong, I will make my mea culpa and published revised figures. Domain checking was random, by hand (I never trust my software))
https://gist.github.com/jul/7056d4535da42103407ba2424e47d507
So making the hypothesis of good faith from the submitter it means 50% of historic users of angular dropped it since 2015. Most of them anyway did not «fully» adopted it.
If a technology is being dropped after 2 years by their early motivated adopters, maybe there is a smell?
https://gist.github.com/jul/7056d4535da42103407ba2424e47d507
So making the hypothesis of good faith from the submitter it means 50% of historic users of angular dropped it since 2015. Most of them anyway did not «fully» adopted it.
If a technology is being dropped after 2 years by their early motivated adopters, maybe there is a smell?
It does not 'feel' heavyweight or that it gets in my way too much, but the contrary is true. Of course, it has it`s quirks, as every larger lib have, but it`s pluses outweigh minuses by far for me.
Preferences aside, does Angular make you less productive than other options? Do you feel that you fight the framework? Can you finish non trivial frontend apps, involving 5+ team members, 'better', with cleaner code and much faster with other options?
This are just honest questions. I wanted to start some pet project in angular2 soon, but would listen to alternatives, maybe it is a right moment to try some of them.