3 ms·

I worked on an enterprise stack that started as ASP.net web forms, with C# used instead of PHP (this is not a C# vs PHP debate, the core problems exist no matte

I worked on an enterprise stack that started as ASP.net web forms, with C# used instead of PHP (this is not a C# vs PHP debate, the core problems exist no matter what backend form stack you use). The app was created in early 00s and by the early 10s, it was hundreds of pages. While everyone thought our application was mostly a C# app, by 2013 or so, we actually had more lines of JS than C#. Every time a dev needed to add some dynamic behavior to the site, they would import Jquery, or Jquery UI, add a plugin or few, add some inline JS on a CSHTML file, add a css file, etc etc. Eventually the entropy of that sort of thinking, of treating JS as a second class after thought, as like something you can casually inject or bang out on a per page basis, cost us a great deal on product momentum, refactoring, modernization, mobile compatibility, and more. Facebook itself is a PHP app. React was invented to solve similar problems for Facebook. If you're building a basic form app and you're able to make a business out of it in 2023, by all means, use some Jquery, a dead simple form UI and go to town. But if that app starts to evolve beyond a few screens or if more dynamic behavior is required, you owe it to yourself and your team to use a proper JS framework and toolset.

sebazzz 3y ago
> you owe it to yourself and your team to use a proper JS framework and toolset. In 2023 JS is no longer necessary, for instance, Blazor also works fine, and works great for small teams building just LOB apps.
- aloha2436 3y ago
  Blazor Server and WASM both have issues that make them non-starters for me, namely latency quickly gets out of hand for the former and the latter is far too heavy. The (unfortunate?) reality is that Javascript is unavoidable if you want good bundle sizes and client-side interactivity. I find HTMX is a better alternative if I'm trying to write as little JS as possible, I find it smooths over the latency issue better and just lets me write normal web app code that feels like a SPA to use.
- chrisco255 3y ago
  Hi, do you have an open source repo of something you've built in Blazor? Would love to check it out. While it sounds interesting, there are still numerous limitations to wasm. There's no garbage collection, I'm curious how large Blazor apps are at scale on larger code bases, I'm also curious how well that works with either a PHP or Ruby stack, for example, and how easy you find it to integrate with other frameworks outside of the Microsoft stack?

sebazzz 3y ago

> you owe it to yourself and your team to use a proper JS framework and toolset. In 2023 JS is no longer necessary, for instance, Blazor also works fine, and works great for small teams building just LOB apps.

aloha2436 3y ago
Blazor Server and WASM both have issues that make them non-starters for me, namely latency quickly gets out of hand for the former and the latter is far too heavy. The (unfortunate?) reality is that Javascript is unavoidable if you want good bundle sizes and client-side interactivity. I find HTMX is a better alternative if I'm trying to write as little JS as possible, I find it smooths over the latency issue better and just lets me write normal web app code that feels like a SPA to use.
chrisco255 3y ago
Hi, do you have an open source repo of something you've built in Blazor? Would love to check it out. While it sounds interesting, there are still numerous limitations to wasm. There's no garbage collection, I'm curious how large Blazor apps are at scale on larger code bases, I'm also curious how well that works with either a PHP or Ruby stack, for example, and how easy you find it to integrate with other frameworks outside of the Microsoft stack?