3 ms·

I'm working on a massive Angular 13 project and I love it. There are reasons for choosing "front-end frameworks" and once you get into Enterprise-level territo

I'm working on a massive Angular 13 project and I love it. There are reasons for choosing "front-end frameworks" and once you get into Enterprise-level territory you start to see why. I'm both front and back and Angular is hitting the sweet spot with our developers who come from OOP backgrounds and can grasp TypeScript at a glance and don't get scared by compiler errors.

tylerchilds 5y ago
My problem with TypeScript isn't the fear of compiler errors. It's because then my day job became hammering scope until the problem could be solved with CSS so we didn't need to write any Superset of JavaScript at all.
- EMM_386 5y ago
  > . It's because then my day job became hammering scope until the problem could be solved with CSS so we didn't need to write any Superset of JavaScript at all. CSS is the least of your problems, wait until your career gets to the point of 20+ developers. And by "compiler errors" I don't mean TypeScript, that is easy peasy ... I mean Angular. And even that is easily sorted if you know why it's complaining and how to fix it.
  - tylerchilds 5y ago
    I work with more than 20 engineers. Our biggest problems stem from abstraction A built on abstraction B, built abstraction C, built on abstraction D. Specifically, the abstractions are material UI, our component library in react, react data grid, and an app specific for any of it. For end users, they want a table. TypeScript provides the logistics to make this sprawl predictable, albeit with a 500ms delay on user input. CSS isn't a problem: it is the solution. That's why I'm working to get our tech debt paid upfront and upstream with it.
    - EMM_386 5y ago
      > For end users, they want a table. TypeScript provides the logistics to make this sprawl predictable, albeit with a 500ms delay on user input. This is a problem with your engineering, not with TypeScript or front-end frameworks. TypeScript isn't even a thing for end-users, that gets transpiled to plain old JavaScript. We deal with real-time grids that are updated via RxJs 7 subscribed to multiple data feeds. Thousands of rows all being updated in real time without a page refresh. The performance impact is negligible. Especially compared to the desktop apps I used to write that did the same thing. 500 ms is insane, you are doing something wrong. Our grids update on the order of less than 5 ms, and with virtual infante scrolling on top of that. Lots of rows, all scrollable smoothly and all flashing updated numbers in real-time. It works perfectly and is extremely performant. If you are having issues with "sprawl" and data grids, you have a problem with a poor component library and/or poor engineering. We use PrimeNG. It's table component is blazing fast. You stick a <p-table> component in your template and bind it to a data source, the rest is handled from there for the most part. I'm not sure what there is to complain about any of this. It works as advertised. At least in Angular it does. I have no idea with React. I know both but I avoid React like the plague for various reasons. https://www.primefaces.org/primeng/showcase/#/table https://www.primefaces.org/primeng/showcase/#/table
      - tylerchilds 5y ago
        Your assessment is spot on. I've been working on building a proof of concept outside of our jenga tower of dependencies. This is the foundational open-sourced layer I built that I'm now building on top of: https://thelanding.page/tag/ https://thelanding.page/tag/ I'm starting to transition to sell mode, it's just a tough sell when the entire org is heavily invested in the aforementioned jenga tower.
SantiagoElf 5y ago
We migrated to Angular 13 from 11. I LOVE Angular for front-end. TypeScript is love, TypeScript is life :)

tylerchilds 5y ago

My problem with TypeScript isn't the fear of compiler errors. It's because then my day job became hammering scope until the problem could be solved with CSS so we didn't need to write any Superset of JavaScript at all.

EMM_386 5y ago
> . It's because then my day job became hammering scope until the problem could be solved with CSS so we didn't need to write any Superset of JavaScript at all. CSS is the least of your problems, wait until your career gets to the point of 20+ developers. And by "compiler errors" I don't mean TypeScript, that is easy peasy ... I mean Angular. And even that is easily sorted if you know why it's complaining and how to fix it.
- tylerchilds 5y ago
  I work with more than 20 engineers. Our biggest problems stem from abstraction A built on abstraction B, built abstraction C, built on abstraction D. Specifically, the abstractions are material UI, our component library in react, react data grid, and an app specific for any of it. For end users, they want a table. TypeScript provides the logistics to make this sprawl predictable, albeit with a 500ms delay on user input. CSS isn't a problem: it is the solution. That's why I'm working to get our tech debt paid upfront and upstream with it.
  - EMM_386 5y ago
    > For end users, they want a table. TypeScript provides the logistics to make this sprawl predictable, albeit with a 500ms delay on user input. This is a problem with your engineering, not with TypeScript or front-end frameworks. TypeScript isn't even a thing for end-users, that gets transpiled to plain old JavaScript. We deal with real-time grids that are updated via RxJs 7 subscribed to multiple data feeds. Thousands of rows all being updated in real time without a page refresh. The performance impact is negligible. Especially compared to the desktop apps I used to write that did the same thing. 500 ms is insane, you are doing something wrong. Our grids update on the order of less than 5 ms, and with virtual infante scrolling on top of that. Lots of rows, all scrollable smoothly and all flashing updated numbers in real-time. It works perfectly and is extremely performant. If you are having issues with "sprawl" and data grids, you have a problem with a poor component library and/or poor engineering. We use PrimeNG. It's table component is blazing fast. You stick a <p-table> component in your template and bind it to a data source, the rest is handled from there for the most part. I'm not sure what there is to complain about any of this. It works as advertised. At least in Angular it does. I have no idea with React. I know both but I avoid React like the plague for various reasons. https://www.primefaces.org/primeng/showcase/#/table https://www.primefaces.org/primeng/showcase/#/table
    - tylerchilds 5y ago
      Your assessment is spot on. I've been working on building a proof of concept outside of our jenga tower of dependencies. This is the foundational open-sourced layer I built that I'm now building on top of: https://thelanding.page/tag/ https://thelanding.page/tag/ I'm starting to transition to sell mode, it's just a tough sell when the entire org is heavily invested in the aforementioned jenga tower.

SantiagoElf 5y ago

We migrated to Angular 13 from 11. I LOVE Angular for front-end. TypeScript is love, TypeScript is life :)