20 ms·

Angular v8.0

274 points by tashoecraft 7y ago

Sahhaese 7y ago
This should point to https://github.com/angular/angular-cli/releases/tag/v8.0.0 https://github.com/angular/angular-cli/releases/tag/v8.0.0 which is the release page for this version rather than all releases.
- tashoecraft 7y ago
  I can’t update if a mod wants to update it for me then go ahead
royjacobs 7y ago
Congratulations on the release! For all the talk of React and Vue I still like the 'batteries-included' approach of Angular. I mostly do Kotlin in my day job so Angular aligns fairly nicely with the way applications are structured. I don't get the militant need for terseness that's seen in approaches like React Hooks. I also don't need the choice between multiple backwards-incompatible (or competing) routers, nor do I have a need for functionally pure reducers. So, it may not be sexy, but It Works and that's good enough for me :)
- microcolonel 7y ago
  > Congratulations on the release! For all the talk of React and Vue I still like the 'batteries-included' approach of Angular. It's a different story when your application is huge and mostly made of batteries. ;- )
  - royjacobs 7y ago
    When a typical application spends multiple megabytes just for the webfonts and logo JPGs on the front page, I don't really care whether my application bundle is 200k or 500k, though. I care more about productivity. Now, this clearly needs SOME boundaries, but let's not start a whole "Electron" thread again :)
    - vfc1 7y ago
      The bundle size is now much better, and will only get better with Ivy. Also, I don't think it makes the most important comparison point although it certainly is one to consider. Most websites on the internet load several megabytes of Javascript. For a full-size SPA, I think Angular is a great choice, but for incremental use cases like adding some interactivity to a mostly static page, it's still not the main use case, although that will change with Angular Elements.
      - royjacobs 7y ago
        Yes, that is absolutely fair. I was indeed talking about Angular in the context of a full SPA, not a tiny component in a banner.
      - jmkni 7y ago
        For your second use-case (adding some interactivity to a mostly static page), Vue works really well. For a full on SPA, Angular is lovely to work with.
    - arnvald 7y ago
      I think it's still worth paying attention to size of the JS download. If you download 500k of JS, it means that after ungzipping it, it will be 2mb or more. Your browser needs to parse and execute that code, which also takes time, and it impacts the user experience. Also it's easier (at least from developer's perspective) to deal with a big image than to deal with big JS codebase. You can't just replace it with something smaller, you often need to spend a significant amount to shrink it.
      - royjacobs 7y ago
        Definitely, this is also why it's important that Angular is making strides towards reducing the total download size. This is, in fact, exactly what is happening with this release (and it will only improve when Ivy is released). This does not mean the frontend community should continually be bending over backwards reinventing wheels just so the claim can be made that a certain package is now "only 1.6k GZipped!", imho.
- mhd 7y ago
  I've been burnt by the non-Euclidian enormity of ExtJS, so I understand the desire for something simpler. On the other hand, when you leave the world of progressive enhancement and widgets (ie. jQuery), you find yourself needing a lot of common infrastructure and picking and matching that can be quite tedious (never mind dependency hell), which is something that react always had issues with -- and that seems to extend fractally, where it's not just MobX vs. React but then what framework/project setup you have on top of each of these choices. And now hooks. Still, angular always struck me as going slightly too far into Java-land -- my Struts/J2EE/DI battle scars are larger than even my ExtJS mutilations. And in between you've got VueJS/Vuex, which seems to move a bit too close to react at times, and EmberJs, which seems to move too slowly and/or without many people watching it. I really want to go back to late-90s desktop UI development sometimes…
  - ChicagoDave 7y ago
    WebAssembly is still a couple of years away, sadly.
    - mhd 7y ago
      Yes, then we'll get native J2EE in the browser instead of JS copies… The whole interaction model is just a lot more tedious than desktop UI development. One of the few approaches that I actually liked (not just tolerated) was Seaside, but that went away when the blood-dimmed tide of JS was let loose.
      - sheeshkebab 7y ago
        >then we'll get native J2EE in the browser instead of JS copies… Can’t wait. Imagining all the possibilities...
  - EugeneOZ 7y ago
    DI in Angular 8 is much less aggressive than in AngularJS/Angular 2. At least it feels this way :)
  - gaze 7y ago
- bdcravens 7y ago
  What batteries does Angular include that Vue doesn't?
  - mcescalante 7y ago
    I think instead of meaning specific components (http and routing come to mind) that more often people mean by "batteries included" that Angular has an opinionated way to do most everything, and their docs/guides include examples. In my experience, Vue and React allow a higher degree of freedom in choosing how you would like to approach various things, and there are more choices for some core behaviors for them as well
    - onemoresoop 7y ago
      Freedom isn't bad but in larger environments that freedom can lead to multiple ways of doing the same thing and in turn it becomes harder for new people to jump into current projects, they have to first figure out what the initial thought behind a design was. The way Angular is opinionated benefits this setup and unknown projects look more familiar when you first dive in. Also, searching for solutions online almost always fit your needs.
    - daotoad 7y ago
      Funny thing is, if you look at projects like AngularMaterial, they don't follow to the Angular styleguide by a country mile. The nice thing is that the automation tools are being made progressively easier to customize. That means that it is easier to define your own standard and support it with standard tooling.
- cjblomqvist 7y ago
  But Vue got the batteries included? You have a router included and you can just keep your store as an object or use Vuex for larger applications (if you feel the need for even more structure). All this is according to the official docs, thus included and best practice?
- rufugee 7y ago
  Ah...Kotlin on the backend? Can you share more details about your stack/experience? I've been keeping an eye out for it to crop up in production backend stacks, so I'm very interested in learning how well it works for you...
  - meddlepal 7y ago
    I dunno about original poster but in Kotlin I use Javalin.io for HTTP web services and JDBI for SQL. Jedis for Redis access. These are pretty typical Java libraries, but lightweight. Nothing particularly Kotlin about them but that's why I like Kotlin because you can leverage the entire Java ecosystem easily. I find Kotlin on the backend to be a pleasure.
vfc1 7y ago
This release is awesome, here is a summary from the Angular team blog - https://blog.angular.io/version-8-of-angular-smaller-bundles-cli-apis-and-alignment-with-the-ecosystem-af0261112a27 https://blog.angular.io/version-8-of-angular-smaller-bundles... The main feature among many is differential loading, that will load different versions of the application depending on the capabilities of the browser. This will avoid installing polyfills without the need for them and reduce the bundle size. There are reports of 40kb reduction in bundle size, which is a lot. More than that, this release does a lot of preparation work for Ivy in version 9, which will bring a completely new rendering layer. Also, there is a lot of preparatory work for the introduction of Bazel in the build pipeline, which will bring us fully incremental builds (recompiling only the part of the code that changed and nothing more).
- marshallant 7y ago
  Differential serving can easily be done using babel and webpack. Been doing it for awhile now.
  - vfc1 7y ago
    Yes, it was possible with Angular also before, just like with other frameworks, but now this is built-in the Angular CLI build pipeline. This means that this is now mostly transparent to developers, and taken care for us by the build pipeline without having, for example, to configure webpack and Typescript manually ourselves.
  - turadg 7y ago
    How simple is it to implement? I’ve been considering this but figured the complexity may not be worth it. How many different builds do you emit? Do you run into any frustrations with your user error logging tools having different stack traces?
- preommr 7y ago
  > There are reports of 40kb reduction in bundle size, which is a lot. It would be for libraries like react or vue that are already small. Angular is still big enough that even after being 40kb slimmer it's still fairly huge (I think the typical build is like ~550+kb).
sheeshkebab 7y ago
Angular feels like frontend framework built by backend java Spring developers, that hate frontend development.
- royjacobs 7y ago
  Apart from being verbose, why is that a bad thing? Spring is used to successfully build massive applications. You can meme about Spring's AbstractFactoryBeans all day, but in the end it does what it's supposed to do.
  - p2t2p 7y ago
    Recently I had to hide a bunch of functionality for certain license type in a product. Spring + AspectJ turned it into a enjoyable experience - just add one annotation, two classes, one for aspect, another for exception mapper in rest and you can mark any class as "requires certain type of license" in one like of code now.
  - scotchbonnet 7y ago
    I maintain a class library that is highly depended upon in the rest of our company. I don't like to introduce dependencies at my later because of that. So things like DI are all factory patterns / builder patterns. It's explicit and has kept my object lifecycle super manageable. It feels like the people who meme about EnterpriseFactoryFactory at times just haven't hit the right use case for it.
    - RhodesianHunter 7y ago
      And if they do ever hit it, having never seen a reason to use it before, they instead layer over it with poorly thought out abstractions leading to unmaintainable code that they'll probably hoist onto the next dev.
    - porker 7y ago
      I'd like to understand this more, as being on the fringe of popular open source projects I think I experience this. Can you expand any further with pseudocode?
zihotki 7y ago
I wonder what's the story behind delays of Ivy? Can somebody elaborate? It was first scheduled for v6 (don't remember , then for v7, now there is v8 and it's again rescheduled for v9.
- romanovcode 7y ago
  It needs to be backwards compatible and it is tested with google internal applications and needs to be approved by said applications.
  - imcotton 7y ago
    That what they have been saying for years, not what the REAL reason.
    - romanovcode 7y ago
      What would be the real reason then? It's not like they are workng on something else. Ivy is pretty much all they are working on for the past 1-2 years. Even to the point where events like Angular Connect are very boring because there is nothing new except this. I'm pretty sure they want to release it ASAP and be done with it.
  - jamesgeck0 7y ago
    To add to this, the Angular engineers at Google are responsible for updating all however-many-hundred of those internal applications if they make any backwards incompatible changes.
- fknop 7y ago
  Note that it already mostly works right now with v8.
holografix 7y ago
I was recently at a Microsoft heavy tech conference and spoke to at least 50 .Net developers. Anyone who also did front end did so in Angular. I was surprised at how popular it is!
- inglor 7y ago
  In my experience (as a conference speaker) the people who recommend .NET and sell .NET consulting are often the same people who recommend Angular and do Angular consulting. Both have a relatively high entry barrier compared to their alternatives (though lower than a few years ago).
- jetti 7y ago
  That doesn't really surprise me as Angular uses TypeScript.
- kreck 7y ago
  We're not doing .NET, however i suppose besides the fact that it uses TypeScript it is popular with MS developers, because it gives you a structure that allow to develop enterprise applications in larger teams. If you know your application will have to be enterprise grade, will be large, will be developed by enterprise devs and has to be supported for years to come, Angular is still the definitive choice (IMHO). Mainly because it gives your team a clear structure to operate in combined with known concepts.
- jaabe 7y ago
  I work in the Danish public sector and we currently have 300 systems from various contractors. Almost all of them are moving toward a C#/JAVA api based backend and an Angular front. Only one of those systems uses Vue. None of them use React. Outside the public sector React is a bit more popular, but it’s still mainly used outside of enterprise and Vue rarely sees any use. The job-market doesn’t seem to follow the tech hype cycles much, at least not when you live in a country like mine.
  - h1d 7y ago
    Maybe just afraid to use tools developed by someone you don't know?
revskill 7y ago
I feel Svelte is the framework that Angular author actually wanted to build since the first version.
- inglor 7y ago
  Funnily enough, Ivy takes a pretty similar approach to Svelte with its markDirty calls similar to Svelte's $$invalidate calls. That said, Angular doesn't utilize its compiler the same way Svelte does (yet) so time will tell.
  - Sammi 7y ago
    I think moving stuff from runtime to compiletime is the theme of most changes to Angular 2+ compared to Angular 1. So I'm very much expecting Angular devs to look at Svelte and start hitting ctrl-c ctrl-v repeatedly on their keyboards :)
- romanovcode 7y ago
  A lot of talk about Svelte in this thread, I guess it's the new FOTM front-end framework. In any case - angular has no one author and it is moving to the Svelte direction of rendering with Ivy which is to be released in next major version.
bricss 7y ago
Nobody interested. Except Java and C# developers.
- james_s_tayler 7y ago
  So millions of developers then?
- equasar 7y ago
  Apparently your bitter comment brought you here by some interest, either to love it or hate it, but you were interested.
bob1029 7y ago
I honestly had no idea this was still a thing. We jumped ship to riot.js back around Angular V2 and haven't really thought about another javascript framework since. All of our web tools have been vanilla JS/CSS/HTML with riot tying it all together for the last 3+ years now. It really does seem like the ideal way to compose single page web applications. We do use some 3rd party stuff like codemirror, momentjs, etc., but that's about it. Not even jQuery to be found unless some 3rd party component depends on it. The advantages of not using someone's framework, language or module system is that we have a direct and stable surface (the DOM) against which to tie things together. Complex web interactions we attempted to do (and failed to do) using Angular directives/components/etc became trivial using our vanilla+riot approach. It almost feels like cheating by comparison, and then you don't care because your incredibly-complex web interaction that involves 5+ vendor libraries and 8 nested API calls just works and is easy to inspect directly. Obviously, you need some discipline to manage something with less structure around it, but all it takes is a handful of code review sessions to get other developers synced up on how things work in this more 'open' world. There honestly aren't a lot of new things to learn either (there are definitely more things to unlearn coming from Angular). Productivity is also a huge plus. I don't have to spend an hour reviewing the semantics around some Angular construct before I do my work. After a few weeks away from some web project, I can jump directly into the HTML/JS/CSS, crank out a new .html riot tag file and be done with it in less time than it would have taken to re-sync my brain into Angular semantics land. If you haven't tried riot yet, you should definitely take a look. Once we got our first application working on it and we understood the basics, it felt like we had escaped from frontend jail and could do anything we wanted to. For everyone who views front-end as a mosh pit of chaos and uncertainty, I strongly suggest trying this approach out on a throwaway project when you get some free time.
- pier25 7y ago
  Anyone knows when Riot v4 will be ready? I wanted to try Riot but then I saw they were working on v4 with the Simulacra guy and decided to wait until the new version.
i_can_c_sharp 7y ago
Does anyone know how Angular compares to Aurelia?
pier25 7y ago
While the effort by the Angular team deserves praise, I think for the vast majority of use cases it is a mistake to do it all client side. With some exceptions, there is really no benefit in making a SPA but there are many drawbacks. I don't say this lightly. I used AngularJS in 2015 and since then I've been making SPAs in React, Vue, and Inferno + Mobx.
- christophilus 7y ago
  I tend to agree. But in defense of the SPA, my experience is that over time, most screens accrete complexity. You start out with a simple content screen. Then the client wants comments. Then they want richer comments. Then they want live comments. Etc. Over time, most of my web applications tend to require richer and richer interactivity on each screen. As a result, it's nice to have started out with a client-side framework, rather than hitting some threshold where you suddenly need to switch things over.
  - hombre_fatal 7y ago
    Your last paragraph summarizes why I default to a client-side framework if there's going to be much of any JS interactivity at all on a screen. Even something that seems simple like a search form can be surprisingly interactive.
  - pier25 7y ago
    > As a result, it's nice to have started out with a client-side framework You mean like Angular or Ember? Because you can perfectly use Vue, React, Inferno, Svelte, Imba, etc, on a multiple-page application.
- phponpcp 7y ago
  It's all about the use case. If you're on an ecommerce website and click between category and PDP pages 5-10 times browsing, a SPA is going to make that transaction an order of magnitude faster. Since you're only loading the smallest possible payload (JSON) that contains only the things that have changed, it is optimized in a way that is never going to be achievable with server-side rendering. At least that's why I opted to push for a SPA.
pure 7y ago
Angular is really a great framework. I think a lot of people complaining about Angular haven't actually built an app in Angular 4+. I also wish the Angular team had just called Angular 2 something else, since the 1 -> 2 transition frustrated a lot of people who jumped ship and never looked back. I also understand that people just have different preferences, which is fine, too. Out of the box, you get: routing with lazy loading, full TypeScript support and a TypeScript-first ecosystem, a great CLI that completely abstracts Webpack and the build process, easy and mostly automatic updates with the CLI, reactivity with RxJS baked-in and supported widely in the community, a great forms library, and, of course, a component-based approach to UI development. The uniformity is a big benefit. It's easy to ramp up on a new Angular project, and there are fewer decisions to make when starting a new one. The built-in parts of the framework are all high quality and an easy bet. There's no need to evaluate different routers, form libraries, HTTP clients, get back up to speed on configuring Webpack only to forget how until next time, etc. It's also interesting to see the React community move towards some of the things that Angular has been doing for years: embracing TypeScript, extracting business logic to services (or you can call them Hooks), creating injectable shared state (or you can call it Context).
- onemoresoop 7y ago
  I started working with angular 7 this February and I have to admit the learning curve was steep at first but after the slow start I quickly built my first project and now fully appreciate its power. I also think I am lucky to have taken a stab at it in its current stages, 4+ as I lost my patience for too much noise and too many changes. I also have many praises for Visual Studio Code. The reasons you mentioned are very valid and thats the reason Angular got adopted by enterprises. The uniformity the framework imposes on the projects makes it easy for other devs to jump in, to pick up a project done by somebody else, etc.. For all people who resent SPAs, continue using all jquery and other libs for small or existing projects but do consider a framework like angular if you want to build a stable web application (or a suite of web applications), you will appreciate it after your initial dive. I also recommend a youtube channel with clear non ADD turorials: search for ‘kudvenkat angular’ on youtube.
  - 7y ago
dmitriid 7y ago
In my opinion Angular's story is a story of how people invent problems and then valiantly tackle them. - We want to re-write the whole thing from scratch. In TypeScript. - And let's use Google's Closure Compiler for JavaScript. Even though it doesn't support TypeScript, modules, or anything, really from non-Google Javascript world (at the time) - Oh. Then... Let's create a TypeScript to Closure Translator even though TypeScript doesn't let you extend the compiler and TypeScript and Closure are in general not entirely compatible - Oh, and we use a weird combination of annotations and templates to work, so... we need to compile our templates into TypeScript (which we need to translate to Closure-compatible JavaScript which will then be compiled further down) - Only the whole process is abysmally slow. Let's implement incremental compilation. - It's probably still slow, complicated, and error-prone. We know! Let's use Google's Bazel! You know, the tool to build huge codebases in parallel on clusters. Yeah, why not use that to build JS code? - Only bazel has no support for either Closure, or Javascript, or TypeScript, so we have to build tools and integrations to work with bazel! And the quests just keep popping up.
- equasar 7y ago
  What's the point you are trying to achieve with that negativity? Writing non existing tooling around some tools is almost positive as they can pave the journey to other and better tooling. Also, I doubt you are paying a cent to those developers to justify your complaints about it.
  - dmitriid 7y ago
    > What's the point you are trying to achieve with that negativity? Not trying to achieve anything. It’s my own personal opinion on how I view Angular’s development. The devs dig deeper and deeper holes to bravely climb out of them. > Writing non existing tooling around some tools is almost positive Since there’s no cost-benefit analysis, “almost positive” is entirely speculation. > I doubt you are paying a cent to those developers to justify your complaints about it. “Only paying customers are allowed to voice criticism. Please purchase a criticism package or a yearly subscription today. Volume discounts are available, contact your nearest sales representative”
chrismbarr 7y ago
Literally just finished a huge re-write of an angular 4 app to latest Angualr 7 today, to revise the UI and improve everything. As I was about to merge it in I see this... time to upgrade!
- sheeshkebab 7y ago
  Job security
visarga 7y ago
Angular is too abstract / has a steep learning curve. You need to learn too many design patterns at once (factory, provider, service, singleton, pipes, directives, observable, component, container, dependency injection). Trying something simple is trivial, but trying something more complex is overly difficult.
- sa46 7y ago
  I understand your point but to be fair, if we cherry pick all the terminology from React it also looks bad: JSX, components, props, context, error boundaries, forwarding refs, fragments, higher-order components, container. Once you add in concepts from the other libraries commonly used with React like mobx or redux I think the comparison isn't as clearcut.
- deleted 7y ago
  [deleted]
- deleted 7y ago
  [deleted]
- DrFell 7y ago
  True, but you are learning ubiquitous programming concepts in about as well conceived of an implementation as you will get in a frontend scripting framework. While none of the extra complexity is crucial to making a dynamic website, it earns its keep when you try to build a big online application. Why not just learn that stuff. I think all the bundled pre-built functionality, like reactive forms, is the hardest part of Angular. That can be tedious to learn. But then again, so is 3rd party library X, so it's a wash. Factories are no longer in Angular 2
arnvald 7y ago
Congratulations on the release and thanks to core team and all contributors for their work!
ousta 7y ago
guys. as a long time old school dev. I have heard about components all my life from ASP MVC to JSF in java. what is really the difference with angular? A better embedding of RX-JS and AJAX is that it all?
sungju1203 7y ago
why use Angular instead of Vue? no benefit at all.

274 points by tashoecraft 7y ago

This should point to https://github.com/angular/angular-cli/releases/tag/v8.0.0 https://github.com/angular/angular-cli/releases/tag/v8.0.0 which is the release page for this version rather than all releases.

tashoecraft 7y ago
I can’t update if a mod wants to update it for me then go ahead

royjacobs 7y ago

Congratulations on the release! For all the talk of React and Vue I still like the 'batteries-included' approach of Angular. I mostly do Kotlin in my day job so Angular aligns fairly nicely with the way applications are structured. I don't get the militant need for terseness that's seen in approaches like React Hooks. I also don't need the choice between multiple backwards-incompatible (or competing) routers, nor do I have a need for functionally pure reducers. So, it may not be sexy, but It Works and that's good enough for me :)

microcolonel 7y ago
> Congratulations on the release! For all the talk of React and Vue I still like the 'batteries-included' approach of Angular. It's a different story when your application is huge and mostly made of batteries. ;- )
- royjacobs 7y ago
  When a typical application spends multiple megabytes just for the webfonts and logo JPGs on the front page, I don't really care whether my application bundle is 200k or 500k, though. I care more about productivity. Now, this clearly needs SOME boundaries, but let's not start a whole "Electron" thread again :)
  - vfc1 7y ago
    The bundle size is now much better, and will only get better with Ivy. Also, I don't think it makes the most important comparison point although it certainly is one to consider. Most websites on the internet load several megabytes of Javascript. For a full-size SPA, I think Angular is a great choice, but for incremental use cases like adding some interactivity to a mostly static page, it's still not the main use case, although that will change with Angular Elements.
    - royjacobs 7y ago
      Yes, that is absolutely fair. I was indeed talking about Angular in the context of a full SPA, not a tiny component in a banner.
    - jmkni 7y ago
      For your second use-case (adding some interactivity to a mostly static page), Vue works really well. For a full on SPA, Angular is lovely to work with.
  - arnvald 7y ago
    I think it's still worth paying attention to size of the JS download. If you download 500k of JS, it means that after ungzipping it, it will be 2mb or more. Your browser needs to parse and execute that code, which also takes time, and it impacts the user experience. Also it's easier (at least from developer's perspective) to deal with a big image than to deal with big JS codebase. You can't just replace it with something smaller, you often need to spend a significant amount to shrink it.
    - royjacobs 7y ago
      Definitely, this is also why it's important that Angular is making strides towards reducing the total download size. This is, in fact, exactly what is happening with this release (and it will only improve when Ivy is released). This does not mean the frontend community should continually be bending over backwards reinventing wheels just so the claim can be made that a certain package is now "only 1.6k GZipped!", imho.
mhd 7y ago
I've been burnt by the non-Euclidian enormity of ExtJS, so I understand the desire for something simpler. On the other hand, when you leave the world of progressive enhancement and widgets (ie. jQuery), you find yourself needing a lot of common infrastructure and picking and matching that can be quite tedious (never mind dependency hell), which is something that react always had issues with -- and that seems to extend fractally, where it's not just MobX vs. React but then what framework/project setup you have on top of each of these choices. And now hooks. Still, angular always struck me as going slightly too far into Java-land -- my Struts/J2EE/DI battle scars are larger than even my ExtJS mutilations. And in between you've got VueJS/Vuex, which seems to move a bit too close to react at times, and EmberJs, which seems to move too slowly and/or without many people watching it. I really want to go back to late-90s desktop UI development sometimes…
- ChicagoDave 7y ago
  WebAssembly is still a couple of years away, sadly.
  - mhd 7y ago
    Yes, then we'll get native J2EE in the browser instead of JS copies… The whole interaction model is just a lot more tedious than desktop UI development. One of the few approaches that I actually liked (not just tolerated) was Seaside, but that went away when the blood-dimmed tide of JS was let loose.
    - sheeshkebab 7y ago
      >then we'll get native J2EE in the browser instead of JS copies… Can’t wait. Imagining all the possibilities...
- EugeneOZ 7y ago
  DI in Angular 8 is much less aggressive than in AngularJS/Angular 2. At least it feels this way :)
- gaze 7y ago
bdcravens 7y ago
What batteries does Angular include that Vue doesn't?
- mcescalante 7y ago
  I think instead of meaning specific components (http and routing come to mind) that more often people mean by "batteries included" that Angular has an opinionated way to do most everything, and their docs/guides include examples. In my experience, Vue and React allow a higher degree of freedom in choosing how you would like to approach various things, and there are more choices for some core behaviors for them as well
  - onemoresoop 7y ago
    Freedom isn't bad but in larger environments that freedom can lead to multiple ways of doing the same thing and in turn it becomes harder for new people to jump into current projects, they have to first figure out what the initial thought behind a design was. The way Angular is opinionated benefits this setup and unknown projects look more familiar when you first dive in. Also, searching for solutions online almost always fit your needs.
  - daotoad 7y ago
    Funny thing is, if you look at projects like AngularMaterial, they don't follow to the Angular styleguide by a country mile. The nice thing is that the automation tools are being made progressively easier to customize. That means that it is easier to define your own standard and support it with standard tooling.
cjblomqvist 7y ago
But Vue got the batteries included? You have a router included and you can just keep your store as an object or use Vuex for larger applications (if you feel the need for even more structure). All this is according to the official docs, thus included and best practice?
rufugee 7y ago
Ah...Kotlin on the backend? Can you share more details about your stack/experience? I've been keeping an eye out for it to crop up in production backend stacks, so I'm very interested in learning how well it works for you...
- meddlepal 7y ago
  I dunno about original poster but in Kotlin I use Javalin.io for HTTP web services and JDBI for SQL. Jedis for Redis access. These are pretty typical Java libraries, but lightweight. Nothing particularly Kotlin about them but that's why I like Kotlin because you can leverage the entire Java ecosystem easily. I find Kotlin on the backend to be a pleasure.

vfc1 7y ago

This release is awesome, here is a summary from the Angular team blog - https://blog.angular.io/version-8-of-angular-smaller-bundles-cli-apis-and-alignment-with-the-ecosystem-af0261112a27 https://blog.angular.io/version-8-of-angular-smaller-bundles... The main feature among many is differential loading, that will load different versions of the application depending on the capabilities of the browser. This will avoid installing polyfills without the need for them and reduce the bundle size. There are reports of 40kb reduction in bundle size, which is a lot. More than that, this release does a lot of preparation work for Ivy in version 9, which will bring a completely new rendering layer. Also, there is a lot of preparatory work for the introduction of Bazel in the build pipeline, which will bring us fully incremental builds (recompiling only the part of the code that changed and nothing more).

marshallant 7y ago
Differential serving can easily be done using babel and webpack. Been doing it for awhile now.
- vfc1 7y ago
  Yes, it was possible with Angular also before, just like with other frameworks, but now this is built-in the Angular CLI build pipeline. This means that this is now mostly transparent to developers, and taken care for us by the build pipeline without having, for example, to configure webpack and Typescript manually ourselves.
- turadg 7y ago
  How simple is it to implement? I’ve been considering this but figured the complexity may not be worth it. How many different builds do you emit? Do you run into any frustrations with your user error logging tools having different stack traces?
preommr 7y ago
> There are reports of 40kb reduction in bundle size, which is a lot. It would be for libraries like react or vue that are already small. Angular is still big enough that even after being 40kb slimmer it's still fairly huge (I think the typical build is like ~550+kb).

sheeshkebab 7y ago

Angular feels like frontend framework built by backend java Spring developers, that hate frontend development.

royjacobs 7y ago
Apart from being verbose, why is that a bad thing? Spring is used to successfully build massive applications. You can meme about Spring's AbstractFactoryBeans all day, but in the end it does what it's supposed to do.
- p2t2p 7y ago
  Recently I had to hide a bunch of functionality for certain license type in a product. Spring + AspectJ turned it into a enjoyable experience - just add one annotation, two classes, one for aspect, another for exception mapper in rest and you can mark any class as "requires certain type of license" in one like of code now.
- scotchbonnet 7y ago
  I maintain a class library that is highly depended upon in the rest of our company. I don't like to introduce dependencies at my later because of that. So things like DI are all factory patterns / builder patterns. It's explicit and has kept my object lifecycle super manageable. It feels like the people who meme about EnterpriseFactoryFactory at times just haven't hit the right use case for it.
  - RhodesianHunter 7y ago
    And if they do ever hit it, having never seen a reason to use it before, they instead layer over it with poorly thought out abstractions leading to unmaintainable code that they'll probably hoist onto the next dev.
  - porker 7y ago
    I'd like to understand this more, as being on the fringe of popular open source projects I think I experience this. Can you expand any further with pseudocode?

zihotki 7y ago

I wonder what's the story behind delays of Ivy? Can somebody elaborate? It was first scheduled for v6 (don't remember , then for v7, now there is v8 and it's again rescheduled for v9.

romanovcode 7y ago
It needs to be backwards compatible and it is tested with google internal applications and needs to be approved by said applications.
- imcotton 7y ago
  That what they have been saying for years, not what the REAL reason.
  - romanovcode 7y ago
    What would be the real reason then? It's not like they are workng on something else. Ivy is pretty much all they are working on for the past 1-2 years. Even to the point where events like Angular Connect are very boring because there is nothing new except this. I'm pretty sure they want to release it ASAP and be done with it.
- jamesgeck0 7y ago
  To add to this, the Angular engineers at Google are responsible for updating all however-many-hundred of those internal applications if they make any backwards incompatible changes.
fknop 7y ago
Note that it already mostly works right now with v8.

holografix 7y ago

I was recently at a Microsoft heavy tech conference and spoke to at least 50 .Net developers. Anyone who also did front end did so in Angular. I was surprised at how popular it is!

inglor 7y ago
In my experience (as a conference speaker) the people who recommend .NET and sell .NET consulting are often the same people who recommend Angular and do Angular consulting. Both have a relatively high entry barrier compared to their alternatives (though lower than a few years ago).
jetti 7y ago
That doesn't really surprise me as Angular uses TypeScript.
kreck 7y ago
We're not doing .NET, however i suppose besides the fact that it uses TypeScript it is popular with MS developers, because it gives you a structure that allow to develop enterprise applications in larger teams. If you know your application will have to be enterprise grade, will be large, will be developed by enterprise devs and has to be supported for years to come, Angular is still the definitive choice (IMHO). Mainly because it gives your team a clear structure to operate in combined with known concepts.
jaabe 7y ago
I work in the Danish public sector and we currently have 300 systems from various contractors. Almost all of them are moving toward a C#/JAVA api based backend and an Angular front. Only one of those systems uses Vue. None of them use React. Outside the public sector React is a bit more popular, but it’s still mainly used outside of enterprise and Vue rarely sees any use. The job-market doesn’t seem to follow the tech hype cycles much, at least not when you live in a country like mine.
- h1d 7y ago
  Maybe just afraid to use tools developed by someone you don't know?

revskill 7y ago

I feel Svelte is the framework that Angular author actually wanted to build since the first version.

inglor 7y ago
Funnily enough, Ivy takes a pretty similar approach to Svelte with its markDirty calls similar to Svelte's $$invalidate calls. That said, Angular doesn't utilize its compiler the same way Svelte does (yet) so time will tell.
- Sammi 7y ago
  I think moving stuff from runtime to compiletime is the theme of most changes to Angular 2+ compared to Angular 1. So I'm very much expecting Angular devs to look at Svelte and start hitting ctrl-c ctrl-v repeatedly on their keyboards :)
romanovcode 7y ago
A lot of talk about Svelte in this thread, I guess it's the new FOTM front-end framework. In any case - angular has no one author and it is moving to the Svelte direction of rendering with Ivy which is to be released in next major version.

bricss 7y ago

Nobody interested. Except Java and C# developers.

james_s_tayler 7y ago
So millions of developers then?
equasar 7y ago
Apparently your bitter comment brought you here by some interest, either to love it or hate it, but you were interested.

bob1029 7y ago

I honestly had no idea this was still a thing. We jumped ship to riot.js back around Angular V2 and haven't really thought about another javascript framework since. All of our web tools have been vanilla JS/CSS/HTML with riot tying it all together for the last 3+ years now. It really does seem like the ideal way to compose single page web applications. We do use some 3rd party stuff like codemirror, momentjs, etc., but that's about it. Not even jQuery to be found unless some 3rd party component depends on it. The advantages of not using someone's framework, language or module system is that we have a direct and stable surface (the DOM) against which to tie things together. Complex web interactions we attempted to do (and failed to do) using Angular directives/components/etc became trivial using our vanilla+riot approach. It almost feels like cheating by comparison, and then you don't care because your incredibly-complex web interaction that involves 5+ vendor libraries and 8 nested API calls just works and is easy to inspect directly. Obviously, you need some discipline to manage something with less structure around it, but all it takes is a handful of code review sessions to get other developers synced up on how things work in this more 'open' world. There honestly aren't a lot of new things to learn either (there are definitely more things to unlearn coming from Angular). Productivity is also a huge plus. I don't have to spend an hour reviewing the semantics around some Angular construct before I do my work. After a few weeks away from some web project, I can jump directly into the HTML/JS/CSS, crank out a new .html riot tag file and be done with it in less time than it would have taken to re-sync my brain into Angular semantics land. If you haven't tried riot yet, you should definitely take a look. Once we got our first application working on it and we understood the basics, it felt like we had escaped from frontend jail and could do anything we wanted to. For everyone who views front-end as a mosh pit of chaos and uncertainty, I strongly suggest trying this approach out on a throwaway project when you get some free time.

pier25 7y ago
Anyone knows when Riot v4 will be ready? I wanted to try Riot but then I saw they were working on v4 with the Simulacra guy and decided to wait until the new version.

i_can_c_sharp 7y ago

Does anyone know how Angular compares to Aurelia?

pier25 7y ago

While the effort by the Angular team deserves praise, I think for the vast majority of use cases it is a mistake to do it all client side. With some exceptions, there is really no benefit in making a SPA but there are many drawbacks. I don't say this lightly. I used AngularJS in 2015 and since then I've been making SPAs in React, Vue, and Inferno + Mobx.

christophilus 7y ago
I tend to agree. But in defense of the SPA, my experience is that over time, most screens accrete complexity. You start out with a simple content screen. Then the client wants comments. Then they want richer comments. Then they want live comments. Etc. Over time, most of my web applications tend to require richer and richer interactivity on each screen. As a result, it's nice to have started out with a client-side framework, rather than hitting some threshold where you suddenly need to switch things over.
- hombre_fatal 7y ago
  Your last paragraph summarizes why I default to a client-side framework if there's going to be much of any JS interactivity at all on a screen. Even something that seems simple like a search form can be surprisingly interactive.
- pier25 7y ago
  > As a result, it's nice to have started out with a client-side framework You mean like Angular or Ember? Because you can perfectly use Vue, React, Inferno, Svelte, Imba, etc, on a multiple-page application.
phponpcp 7y ago
It's all about the use case. If you're on an ecommerce website and click between category and PDP pages 5-10 times browsing, a SPA is going to make that transaction an order of magnitude faster. Since you're only loading the smallest possible payload (JSON) that contains only the things that have changed, it is optimized in a way that is never going to be achievable with server-side rendering. At least that's why I opted to push for a SPA.

pure 7y ago

Angular is really a great framework. I think a lot of people complaining about Angular haven't actually built an app in Angular 4+. I also wish the Angular team had just called Angular 2 something else, since the 1 -> 2 transition frustrated a lot of people who jumped ship and never looked back. I also understand that people just have different preferences, which is fine, too. Out of the box, you get: routing with lazy loading, full TypeScript support and a TypeScript-first ecosystem, a great CLI that completely abstracts Webpack and the build process, easy and mostly automatic updates with the CLI, reactivity with RxJS baked-in and supported widely in the community, a great forms library, and, of course, a component-based approach to UI development. The uniformity is a big benefit. It's easy to ramp up on a new Angular project, and there are fewer decisions to make when starting a new one. The built-in parts of the framework are all high quality and an easy bet. There's no need to evaluate different routers, form libraries, HTTP clients, get back up to speed on configuring Webpack only to forget how until next time, etc. It's also interesting to see the React community move towards some of the things that Angular has been doing for years: embracing TypeScript, extracting business logic to services (or you can call them Hooks), creating injectable shared state (or you can call it Context).

onemoresoop 7y ago
I started working with angular 7 this February and I have to admit the learning curve was steep at first but after the slow start I quickly built my first project and now fully appreciate its power. I also think I am lucky to have taken a stab at it in its current stages, 4+ as I lost my patience for too much noise and too many changes. I also have many praises for Visual Studio Code. The reasons you mentioned are very valid and thats the reason Angular got adopted by enterprises. The uniformity the framework imposes on the projects makes it easy for other devs to jump in, to pick up a project done by somebody else, etc.. For all people who resent SPAs, continue using all jquery and other libs for small or existing projects but do consider a framework like angular if you want to build a stable web application (or a suite of web applications), you will appreciate it after your initial dive. I also recommend a youtube channel with clear non ADD turorials: search for ‘kudvenkat angular’ on youtube.
- 7y ago

dmitriid 7y ago

In my opinion Angular's story is a story of how people invent problems and then valiantly tackle them. - We want to re-write the whole thing from scratch. In TypeScript. - And let's use Google's Closure Compiler for JavaScript. Even though it doesn't support TypeScript, modules, or anything, really from non-Google Javascript world (at the time) - Oh. Then... Let's create a TypeScript to Closure Translator even though TypeScript doesn't let you extend the compiler and TypeScript and Closure are in general not entirely compatible - Oh, and we use a weird combination of annotations and templates to work, so... we need to compile our templates into TypeScript (which we need to translate to Closure-compatible JavaScript which will then be compiled further down) - Only the whole process is abysmally slow. Let's implement incremental compilation. - It's probably still slow, complicated, and error-prone. We know! Let's use Google's Bazel! You know, the tool to build huge codebases in parallel on clusters. Yeah, why not use that to build JS code? - Only bazel has no support for either Closure, or Javascript, or TypeScript, so we have to build tools and integrations to work with bazel! And the quests just keep popping up.

equasar 7y ago
What's the point you are trying to achieve with that negativity? Writing non existing tooling around some tools is almost positive as they can pave the journey to other and better tooling. Also, I doubt you are paying a cent to those developers to justify your complaints about it.
- dmitriid 7y ago
  > What's the point you are trying to achieve with that negativity? Not trying to achieve anything. It’s my own personal opinion on how I view Angular’s development. The devs dig deeper and deeper holes to bravely climb out of them. > Writing non existing tooling around some tools is almost positive Since there’s no cost-benefit analysis, “almost positive” is entirely speculation. > I doubt you are paying a cent to those developers to justify your complaints about it. “Only paying customers are allowed to voice criticism. Please purchase a criticism package or a yearly subscription today. Volume discounts are available, contact your nearest sales representative”

chrismbarr 7y ago

Literally just finished a huge re-write of an angular 4 app to latest Angualr 7 today, to revise the UI and improve everything. As I was about to merge it in I see this... time to upgrade!

sheeshkebab 7y ago
Job security

visarga 7y ago

Angular is too abstract / has a steep learning curve. You need to learn too many design patterns at once (factory, provider, service, singleton, pipes, directives, observable, component, container, dependency injection). Trying something simple is trivial, but trying something more complex is overly difficult.

sa46 7y ago
I understand your point but to be fair, if we cherry pick all the terminology from React it also looks bad: JSX, components, props, context, error boundaries, forwarding refs, fragments, higher-order components, container. Once you add in concepts from the other libraries commonly used with React like mobx or redux I think the comparison isn't as clearcut.
deleted 7y ago
[deleted]
deleted 7y ago
[deleted]
DrFell 7y ago
True, but you are learning ubiquitous programming concepts in about as well conceived of an implementation as you will get in a frontend scripting framework. While none of the extra complexity is crucial to making a dynamic website, it earns its keep when you try to build a big online application. Why not just learn that stuff. I think all the bundled pre-built functionality, like reactive forms, is the hardest part of Angular. That can be tedious to learn. But then again, so is 3rd party library X, so it's a wash. Factories are no longer in Angular 2

arnvald 7y ago

Congratulations on the release and thanks to core team and all contributors for their work!

ousta 7y ago

guys. as a long time old school dev. I have heard about components all my life from ASP MVC to JSF in java. what is really the difference with angular? A better embedding of RX-JS and AJAX is that it all?

sungju1203 7y ago

why use Angular instead of Vue? no benefit at all.