5 ms·

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 s

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.
    - aitchnyu 7y ago
      Is there anybody who assumes networks are fast enough and immutable caches are a thing but parser is the bottleneck? They would bundle everything into a single js but minimise parsing costs. ``` polyfill1 = "function(...)" polyfill2 = "function(...)" vendor1 = "function(...)" vendor2 = "function(...)" route1 = "function(...)" if(firefox) eval(polyfill1) if(route === '/locations') { eval(vendor1) eval(vendor2) eval(route1) } ```
  - h1d 7y ago
    Since when are developers supposed to develop with developer first mind? Those products usually look dull and tedious to use.
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.

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.
  - aitchnyu 7y ago
    Is there anybody who assumes networks are fast enough and immutable caches are a thing but parser is the bottleneck? They would bundle everything into a single js but minimise parsing costs. ``` polyfill1 = "function(...)" polyfill2 = "function(...)" vendor1 = "function(...)" vendor2 = "function(...)" route1 = "function(...)" if(firefox) eval(polyfill1) if(route === '/locations') { eval(vendor1) eval(vendor2) eval(route1) } ```
- h1d 7y ago
  Since when are developers supposed to develop with developer first mind? Those products usually look dull and tedious to use.

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.