3 ms·

It's a new company, the system is still small and they just lost 80% of their engineering talent. I think what's left of the system doesn't matter that much (bu

by haolez 4y ago

It's a new company, the system is still small and they just lost 80% of their engineering talent. I think what's left of the system doesn't matter that much (but I'll have to check, of course). They are currently on C# + Angular.

oblio 4y ago
Why drop C#, though? Angular, I get. But modern dotnet is quite cool.
- pas 4y ago
  why would you drop Angular though? what would you use instead?
  - brink 4y ago
    I'd start by questioning if I need a front-end framework at all.
    - isbvhodnvemrwvn 4y ago
      They lost 80% of engineering talent, baking a custom framework every single new joiner would have to learn would be a colossal waste of resources.
      - ek750 4y ago
        Do you have any references to this? I must have missed the news, something like a cultural blowup internally?
        isbvhodnvemrwvn 4y ago
        https://news.ycombinator.com/item?id=32026496 https://news.ycombinator.com/item?id=32026496
  - dominotw 4y ago
    react
  - WorldMaker 4y ago
    I think Angular has a pit of failure for performance problems. It's use of RxJS is highly compromised (Angular "best practices" are often RxJS worst practices) and that infects all of Angular development and fills the entire ecosystem with memory leaks and other performance problems. (I've blogged about some specifics before and I've built/published an open source library to try to compensate as best I can as I currently work in codebases now sunk cost fallacy stuck to Angular.) I don't think any of React/Vue/Svelte are nearly as compromised and have nearly as big of a pit of failure. I find React a good option with an active ecosystem. React especially isn't ashamed of and doesn't hide its learning curve like Angular tries to, and that learning curve is especially designed to more often than not lead towards pits of success.
    - pas 4y ago
      can you link that blog post? sounds super interesting! thanks! so maybe I'm just lazy but even though I've tried to jump on the whole FRP train (back when it was blowing up around ~2012-2013 .. there was a great tutorial about it and I caaaaan't fiiiiiiind it now but I spent hours going down memory lane thanks to HN's upvote history :D), but I don't really use it or feel the need for it. TS and a nice Result type (a la Rust), the standard Angular Input/Output bindings, dependency injection, a nice template language, and ... things are smooth and easy. Most of the complexity is fiddling with business requirements, validation (the usual mapping backend data to frontend data), somehow performance was never a problem. And compared to Angular I spent tooo much time fiddling with props in React, fighting with people and their half assed components, their ignorance of TS, and so on :)
      - WorldMaker 4y ago
        Dependency Injection is its own form of "too much time fiddling with props". It's just implicitly handled "magic" and you don't appreciate the time you spend fiddling with it because it seems "automatic" up until that point you need to spend an entire week unmangling a set of NgModules to fix a code-splitting problem. (Or you don't and watch your bundle sizes increase exponentially and assume "that's just the Angular way: huge bundles".) Which is its own performance management headache. I do wish that there was a larger culture of TS usage in the larger React ecosystem. But also I'm still comfortable writing my @types/ modules in DefinitelyTyped if I absolutely need to and want to contribute that work to others. That's generally a good recommendation, if you find an untyped React component check the DT issue tracker for it and post a request if there's isn't already an open one. A couple of "Hacktoberfests" I've contributed @types for requests on there, and I know there are others that are watching it more than just once every October or so. Standard Angular Input/Output bindings are some of my problems with Angular. It's a worst of both worlds situation where some things use RxJS and other things use imperative proxies and the performance weirdness of Zone.js and the weird things it does to Promises and RxJS. I also personally don't like the template language. I think it was a terrible mistake that the template language uses .HTML file extensions. I think that sends too many designers a false sense of security with the template language and I've had to correct so many things. > somehow performance was never a problem Everyone has different performance considerations. I still have a tree-shake and keep bundles as small as possible mindset. I also developed a lot of skills doing performance work in RxJS on Cycle.js projects and redux-observable "sagas" on the React side (and RX backends in C#/.NET). So I notice a lot more things to nitpick than the average casual RxJS user. That's a big reason I keep referring to how Angular uses it as a "pit of failure": it sets up casual RxJS users and junior developers to have a bad performance time, and in some cases not realize that they have bad performance. The biggest for instance are very slow memory leaks that will never impact a developer in the middle of an edit/compile/debug cycle because the app never runs for long enough at a time in that cycle (and the developer often has plenty of RAM anyway compared to the average user), but absolutely will drive end users crazy when they have to hard refresh the tab every few hours/minutes and neither the user or the developer will understand why that performance problem exists. The blog post is here: http://blog.worldmaker.net/2021/06/26/angular/ http://blog.worldmaker.net/2021/06/26/angular/ This is my open source library attempting to wrangle some RxJS best practices out of Angular component design and its standard Inputs/Outputs/Template Bindings: https://worldmaker.net/angular-pharkas/ https://worldmaker.net/angular-pharkas/
- haolez 4y ago
  Because it seems that Rails is a lot more productive in the end. It's not a C# shortcoming, but rather a Rails merit.
  - metaltyphoon 4y ago
    That's a stretch. I guess it depends on the dev team. Everything you have in Rails you also have in ASP. You will probably encounter a hiring problem.
  - UglyToad 4y ago
    My admittedly biased view from the other side of the fence is that it may be a lot (little) quicker initially but you run up against code quality/maintainability and performance struggles far sooner. Granted in a startup worrying about next week is wasted cycles but I don't think rails is so much more productive as to justify switching away from an existing stack (whether Laravel, Django, .NET or whatever. While Rails was a paradigm shift when it was new most all other languages and frameworks have adopted large amounts of the lessons from Rails). I'd urge you to give C# a second chance
  - Sparkyte 4y ago
    Rails isn't any more productive than any other languages. Unless you are talking about dead programming languages in comparison. What you need to do is figure out what the application is doing. Identify what the best language is for that task and just micro service it. Move complicated tasks into smaller services. Don't compound the complexity into a monolith whatever you do! You can get best resource utilization by containerizing an application. Most people say just multithread it Puma ruby whateves... you will go into coherency hell if your app is not designed inherentlt around the idea of puma. Just use unicorn and run it as a container. Right size it for that scale out accordingly.
rapind 4y ago
Fable is pretty kick ass if you’re feeling adventurous within the .net ecosystem. https://fable.io/ https://fable.io/
methehack 4y ago
Rails + angular works well, might be a compromise for you. You could replace the backend endpoint by endpoint... e.g. (or similar to incrementalize it). I mean -- assuming the C# is not something you want to carry forward.
Rapzid 4y ago
Trading up .Net for Ruby is like trading up a lambo for pinto. But maybe you need to drive over a mountain pass and the pinto has snow tires on it.

by haolez 4y ago

oblio 4y ago

Why drop C#, though? Angular, I get. But modern dotnet is quite cool.

pas 4y ago
why would you drop Angular though? what would you use instead?
- brink 4y ago
  I'd start by questioning if I need a front-end framework at all.
  - isbvhodnvemrwvn 4y ago
    They lost 80% of engineering talent, baking a custom framework every single new joiner would have to learn would be a colossal waste of resources.
    - ek750 4y ago
      Do you have any references to this? I must have missed the news, something like a cultural blowup internally?
      - isbvhodnvemrwvn 4y ago
        https://news.ycombinator.com/item?id=32026496 https://news.ycombinator.com/item?id=32026496
- dominotw 4y ago
  react
- WorldMaker 4y ago
  I think Angular has a pit of failure for performance problems. It's use of RxJS is highly compromised (Angular "best practices" are often RxJS worst practices) and that infects all of Angular development and fills the entire ecosystem with memory leaks and other performance problems. (I've blogged about some specifics before and I've built/published an open source library to try to compensate as best I can as I currently work in codebases now sunk cost fallacy stuck to Angular.) I don't think any of React/Vue/Svelte are nearly as compromised and have nearly as big of a pit of failure. I find React a good option with an active ecosystem. React especially isn't ashamed of and doesn't hide its learning curve like Angular tries to, and that learning curve is especially designed to more often than not lead towards pits of success.
  - pas 4y ago
    can you link that blog post? sounds super interesting! thanks! so maybe I'm just lazy but even though I've tried to jump on the whole FRP train (back when it was blowing up around ~2012-2013 .. there was a great tutorial about it and I caaaaan't fiiiiiiind it now but I spent hours going down memory lane thanks to HN's upvote history :D), but I don't really use it or feel the need for it. TS and a nice Result type (a la Rust), the standard Angular Input/Output bindings, dependency injection, a nice template language, and ... things are smooth and easy. Most of the complexity is fiddling with business requirements, validation (the usual mapping backend data to frontend data), somehow performance was never a problem. And compared to Angular I spent tooo much time fiddling with props in React, fighting with people and their half assed components, their ignorance of TS, and so on :)
    - WorldMaker 4y ago
      Dependency Injection is its own form of "too much time fiddling with props". It's just implicitly handled "magic" and you don't appreciate the time you spend fiddling with it because it seems "automatic" up until that point you need to spend an entire week unmangling a set of NgModules to fix a code-splitting problem. (Or you don't and watch your bundle sizes increase exponentially and assume "that's just the Angular way: huge bundles".) Which is its own performance management headache. I do wish that there was a larger culture of TS usage in the larger React ecosystem. But also I'm still comfortable writing my @types/ modules in DefinitelyTyped if I absolutely need to and want to contribute that work to others. That's generally a good recommendation, if you find an untyped React component check the DT issue tracker for it and post a request if there's isn't already an open one. A couple of "Hacktoberfests" I've contributed @types for requests on there, and I know there are others that are watching it more than just once every October or so. Standard Angular Input/Output bindings are some of my problems with Angular. It's a worst of both worlds situation where some things use RxJS and other things use imperative proxies and the performance weirdness of Zone.js and the weird things it does to Promises and RxJS. I also personally don't like the template language. I think it was a terrible mistake that the template language uses .HTML file extensions. I think that sends too many designers a false sense of security with the template language and I've had to correct so many things. > somehow performance was never a problem Everyone has different performance considerations. I still have a tree-shake and keep bundles as small as possible mindset. I also developed a lot of skills doing performance work in RxJS on Cycle.js projects and redux-observable "sagas" on the React side (and RX backends in C#/.NET). So I notice a lot more things to nitpick than the average casual RxJS user. That's a big reason I keep referring to how Angular uses it as a "pit of failure": it sets up casual RxJS users and junior developers to have a bad performance time, and in some cases not realize that they have bad performance. The biggest for instance are very slow memory leaks that will never impact a developer in the middle of an edit/compile/debug cycle because the app never runs for long enough at a time in that cycle (and the developer often has plenty of RAM anyway compared to the average user), but absolutely will drive end users crazy when they have to hard refresh the tab every few hours/minutes and neither the user or the developer will understand why that performance problem exists. The blog post is here: http://blog.worldmaker.net/2021/06/26/angular/ http://blog.worldmaker.net/2021/06/26/angular/ This is my open source library attempting to wrangle some RxJS best practices out of Angular component design and its standard Inputs/Outputs/Template Bindings: https://worldmaker.net/angular-pharkas/ https://worldmaker.net/angular-pharkas/
haolez 4y ago
Because it seems that Rails is a lot more productive in the end. It's not a C# shortcoming, but rather a Rails merit.
- metaltyphoon 4y ago
  That's a stretch. I guess it depends on the dev team. Everything you have in Rails you also have in ASP. You will probably encounter a hiring problem.
- UglyToad 4y ago
  My admittedly biased view from the other side of the fence is that it may be a lot (little) quicker initially but you run up against code quality/maintainability and performance struggles far sooner. Granted in a startup worrying about next week is wasted cycles but I don't think rails is so much more productive as to justify switching away from an existing stack (whether Laravel, Django, .NET or whatever. While Rails was a paradigm shift when it was new most all other languages and frameworks have adopted large amounts of the lessons from Rails). I'd urge you to give C# a second chance
- Sparkyte 4y ago
  Rails isn't any more productive than any other languages. Unless you are talking about dead programming languages in comparison. What you need to do is figure out what the application is doing. Identify what the best language is for that task and just micro service it. Move complicated tasks into smaller services. Don't compound the complexity into a monolith whatever you do! You can get best resource utilization by containerizing an application. Most people say just multithread it Puma ruby whateves... you will go into coherency hell if your app is not designed inherentlt around the idea of puma. Just use unicorn and run it as a container. Right size it for that scale out accordingly.

rapind 4y ago

Fable is pretty kick ass if you’re feeling adventurous within the .net ecosystem. https://fable.io/ https://fable.io/

methehack 4y ago

Rails + angular works well, might be a compromise for you. You could replace the backend endpoint by endpoint... e.g. (or similar to incrementalize it). I mean -- assuming the C# is not something you want to carry forward.

Rapzid 4y ago

Trading up .Net for Ruby is like trading up a lambo for pinto. But maybe you need to drive over a mountain pass and the pinto has snow tires on it.