4 ms·

Simplicity. You can achieve the same in Svelte using fewer concepts and a smaller API. Angular is over-engineered, Svelte is not.

by erokar 7y ago

sansnomme 7y ago
Specifically Svelte is a lot shorter and concise without the Spring-style infamous enterprise software boilerplate that plagues angular. https://dev.to/maurogarcia_19/angular-vs-svelte-card-component-14nk https://dev.to/maurogarcia_19/angular-vs-svelte-card-compone... In addition, its reactive variables is a lot easier to use.
vikingcaffiene 7y ago
> Angular is over-engineered. I take issue with opinions like this that are espoused as fact. I've built large apps in both Angular and React. The React code base needed everything that I got out of the box from Angular. The difference is that React had no one true way to do things which I suppose some people would consider a good thing. I don't. Angular is a framework. Its not over engineered, its complete. You might not like its chosen abstraction but for people like me who just want to get shit done without needing to worry about plumbing and boiler plate, its really nice. All that said, Svelte looks cool. I'll check it out. I think its a fair criticism to say that Angular has a steeper learning curve and if I can reap all the benefits with a shorter ramp up time, its worth adding to the tool belt.
- ng12 7y ago
  To understand why people say Angular is over-engineered Google something simple like "Angular http request". You'll end up at this page: https://angular.io/guide/http https://angular.io/guide/http It's almost comical. I can't believe how long that guide is and how many concepts Angular invented just to fetch some JSON from an http service.
  - rileymat2 7y ago
    Interestingly, they explain some of the reasoning behind the extra info in the docs. WHY WRITE A SERVICE? This example is so simple that it is tempting to write the Http.get() inside the component itself and skip the service. In practice, however, data access rarely stays this simple. You typically need to post-process the data, add error handling, and maybe some retry logic to cope with intermittent connectivity. The component quickly becomes cluttered with data access minutia. The component becomes harder to understand, harder to test, and the data access logic can't be re-used or standardized. That's why it's a best practice to separate presentation of data from data access by encapsulating data access in a separate service and delegating to that service in the component, even in simple cases like this one.
  - vikingcaffiene 7y ago
    I find it a little strange that you are pointing out comprehensive documentation on a module as proof of a problem with the framework... Lets talk about what you get with HttpClient: - Easy testing. Because its using the DI system, its very mockable. You can totally set this up with fetch or whatever behind a service but, well why? Its already done. - Robust type safety. Again you can set this up with fetch, but why? Its already done. - Integrated with rxjs/observables for data transformation, piping, and filtering. You can set this up with fetch but why? It's already done. - Discoverable API because of the deep framework integration and type intelligence. You can set this up with fetch buy why? It's already done. - HttpInterceptor is awesome for checking for things like auth tokens and such. You can set this up with fetch but why? It's already done. Not specific to HttpClient but: - AOT compiler means that unneeded code gets pruned keeping your bundles small. - AOT compiler means that you literally can't compile incorrect code (but it provides an escape hatch if you want to live your life that way) I can make this same argument for pretty much any module you throw at me. Like I said, Angular is _complete_. Is it the right fit for every situation? No! :) It's overkill for smaller projects but if you are building anything of sufficient complexity, you _will_ need all this stuff. The question is, do you want it to be something you had to roll yourself and didn't have time to document for your teammates or do you want something that did all the hard work for you and is ready for whatever you throw at it?
    - ng12 7y ago
      I mean it's really not "already done" if you have to use all this boilerplate to get those features. > Robust type safety. Again you can set this up with fetch, but why? Its already done. Not sure what you mean here. Fetch has high-quality TypeScript bindings. For the rest it's mostly YAGNI. The boilerplate confuses new developers (try explaining what NgModule does to a junior dev just trying to build a simple page) and experienced developers know how to do this stuff themselves.
      - vikingcaffiene 7y ago
        It's YAGNI until you do. Since we're busting out the acronyms a lot of what you are saying sounds like a case of NIH syndrome. :) I have trained junior devs on Angular and I think it's a fair criticism to say it's a steeper learning curve. They do fine tho and as an added bonus they get introduced to concepts like IoC and the like which sets them up for other languages. Experienced developers can set this stuff up its true. I have in fact. It's fun the first few times. Then you get annoyed and want to actually work on your problem domain. I'd much rather spend my time and brain power on that stuff. The apps that I've built that had an established pattern and all the infrastructure needed from go tended to age better and tolerate changes to business requirements. The ones where we rolled it all hodge podge needed more extensive refactoring later. I mean look: this really boils down to very different philosophies. You either go light and build as you go or go everything and the kitchen sink and deal with (what some would call) bloat. I think both have their pros and cons. No silver bullet and all that. You gotta look at the situation and make a call. The rest is just preference and gut instinct.
  - paulddraper 7y ago
    > I can't believe how long that guide is The format should probably be broken up. But yeah covers a lot: * HTTP, JSON, JSONP * Request entities, response entities, headers * Error handling, cancelation, and retries * Authentication, logging, and other kinds of "middleware" * XSRF * Progress tracking * DI and testing * Type safety > how many concepts Angular invented Not a single one of those was invented by Angular. The "weirdest" thing Angular does is use RxJS. But that would be more a criticism of Rx/FRP in general, not Angular specifically.
    - ng12 7y ago
      They're not invented by Angular but for each and everyone one I have to learn how to do it the "Angular way", usually with an Angular-specific API. That's why it's over-engineered.
      - paulddraper 7y ago
        Yes, that's certainly true. Whether good or bad, it seeks to be the solution to many problems (which you would have to solve in some way), hence it being a "framework". I'd probably call that "opinionated" rather than "over-engineered."

Simplicity. You can achieve the same in Svelte using fewer concepts and a smaller API. Angular is over-engineered, Svelte is not.

by erokar 7y ago

Simplicity. You can achieve the same in Svelte using fewer concepts and a smaller API. Angular is over-engineered, Svelte is not.

sansnomme 7y ago

Specifically Svelte is a lot shorter and concise without the Spring-style infamous enterprise software boilerplate that plagues angular. https://dev.to/maurogarcia_19/angular-vs-svelte-card-component-14nk https://dev.to/maurogarcia_19/angular-vs-svelte-card-compone... In addition, its reactive variables is a lot easier to use.

vikingcaffiene 7y ago

> Angular is over-engineered. I take issue with opinions like this that are espoused as fact. I've built large apps in both Angular and React. The React code base needed everything that I got out of the box from Angular. The difference is that React had no one true way to do things which I suppose some people would consider a good thing. I don't. Angular is a framework. Its not over engineered, its complete. You might not like its chosen abstraction but for people like me who just want to get shit done without needing to worry about plumbing and boiler plate, its really nice. All that said, Svelte looks cool. I'll check it out. I think its a fair criticism to say that Angular has a steeper learning curve and if I can reap all the benefits with a shorter ramp up time, its worth adding to the tool belt.

ng12 7y ago
To understand why people say Angular is over-engineered Google something simple like "Angular http request". You'll end up at this page: https://angular.io/guide/http https://angular.io/guide/http It's almost comical. I can't believe how long that guide is and how many concepts Angular invented just to fetch some JSON from an http service.
- rileymat2 7y ago
  Interestingly, they explain some of the reasoning behind the extra info in the docs. WHY WRITE A SERVICE? This example is so simple that it is tempting to write the Http.get() inside the component itself and skip the service. In practice, however, data access rarely stays this simple. You typically need to post-process the data, add error handling, and maybe some retry logic to cope with intermittent connectivity. The component quickly becomes cluttered with data access minutia. The component becomes harder to understand, harder to test, and the data access logic can't be re-used or standardized. That's why it's a best practice to separate presentation of data from data access by encapsulating data access in a separate service and delegating to that service in the component, even in simple cases like this one.
- vikingcaffiene 7y ago
  I find it a little strange that you are pointing out comprehensive documentation on a module as proof of a problem with the framework... Lets talk about what you get with HttpClient: - Easy testing. Because its using the DI system, its very mockable. You can totally set this up with fetch or whatever behind a service but, well why? Its already done. - Robust type safety. Again you can set this up with fetch, but why? Its already done. - Integrated with rxjs/observables for data transformation, piping, and filtering. You can set this up with fetch but why? It's already done. - Discoverable API because of the deep framework integration and type intelligence. You can set this up with fetch buy why? It's already done. - HttpInterceptor is awesome for checking for things like auth tokens and such. You can set this up with fetch but why? It's already done. Not specific to HttpClient but: - AOT compiler means that unneeded code gets pruned keeping your bundles small. - AOT compiler means that you literally can't compile incorrect code (but it provides an escape hatch if you want to live your life that way) I can make this same argument for pretty much any module you throw at me. Like I said, Angular is _complete_. Is it the right fit for every situation? No! :) It's overkill for smaller projects but if you are building anything of sufficient complexity, you _will_ need all this stuff. The question is, do you want it to be something you had to roll yourself and didn't have time to document for your teammates or do you want something that did all the hard work for you and is ready for whatever you throw at it?
  - ng12 7y ago
    I mean it's really not "already done" if you have to use all this boilerplate to get those features. > Robust type safety. Again you can set this up with fetch, but why? Its already done. Not sure what you mean here. Fetch has high-quality TypeScript bindings. For the rest it's mostly YAGNI. The boilerplate confuses new developers (try explaining what NgModule does to a junior dev just trying to build a simple page) and experienced developers know how to do this stuff themselves.
    - vikingcaffiene 7y ago
      It's YAGNI until you do. Since we're busting out the acronyms a lot of what you are saying sounds like a case of NIH syndrome. :) I have trained junior devs on Angular and I think it's a fair criticism to say it's a steeper learning curve. They do fine tho and as an added bonus they get introduced to concepts like IoC and the like which sets them up for other languages. Experienced developers can set this stuff up its true. I have in fact. It's fun the first few times. Then you get annoyed and want to actually work on your problem domain. I'd much rather spend my time and brain power on that stuff. The apps that I've built that had an established pattern and all the infrastructure needed from go tended to age better and tolerate changes to business requirements. The ones where we rolled it all hodge podge needed more extensive refactoring later. I mean look: this really boils down to very different philosophies. You either go light and build as you go or go everything and the kitchen sink and deal with (what some would call) bloat. I think both have their pros and cons. No silver bullet and all that. You gotta look at the situation and make a call. The rest is just preference and gut instinct.
- paulddraper 7y ago
  > I can't believe how long that guide is The format should probably be broken up. But yeah covers a lot: * HTTP, JSON, JSONP * Request entities, response entities, headers * Error handling, cancelation, and retries * Authentication, logging, and other kinds of "middleware" * XSRF * Progress tracking * DI and testing * Type safety > how many concepts Angular invented Not a single one of those was invented by Angular. The "weirdest" thing Angular does is use RxJS. But that would be more a criticism of Rx/FRP in general, not Angular specifically.
  - ng12 7y ago
    They're not invented by Angular but for each and everyone one I have to learn how to do it the "Angular way", usually with an Angular-specific API. That's why it's over-engineered.
    - paulddraper 7y ago
      Yes, that's certainly true. Whether good or bad, it seeks to be the solution to many problems (which you would have to solve in some way), hence it being a "framework". I'd probably call that "opinionated" rather than "over-engineered."