Comment by gwbas1c | Hacker News Reader

Comment by gwbas1c | Hacker News Reader

I'm currently developing a WASM app in C#. (Via in-browser Blazor). We chose this stack because we're a small team with a lot of C# knowledge, and our server-side is C#.

As a result, with a small team we can make a much prettier and slicker app; and it's easy for everyone to be "full stack" without the learning curve that comes with two languages. It's also nice to share code between the server and browser, for things like contracts and small bits of logic that are easily isolated.

One of the more frustrating aspects of WASM via C# is the slow load time because the binary is large. Another frustrating aspect is that, for tight integration with the DOM, it still is best to use JavaScript. As a result, we end up spending time writing wrappers for "best of class" JavaScript libraries instead of using C# libraries.

---

In our case, with hindsight, I think server-side Blazor (with pure JavaScript or TypeScript for logic that needs to happen in the browser,) would be better for our purposes. (It basically moves a lot of the state that would be in the browser to the server. This is really helpful for small teams.) There's reasons why I don't think we'll switch any time soon.

I'm always dubious on claims like these. JavaScript and the web platform are synonymous in discourse but much different in reality. Even with transpired languages or WASM, you still have to use the platform, but now in a non standard language. JavaScript isn't that hard, and I really question if not having to learn it really saves time.

IMHO no platform should force a specific programming language on the programmer, and JS is a lousy compilation target (compared to WASM at least).

But the biggest problem of the web isn't actually JS or WASM, but the inflexible DOM and the (for the most part) poorly designed web APIs.

Blazor generates HTML, but doesn't allow direct manipulation of the DOM unless you start jumping through a lot of hoops. It's generally "good enough" until you get to things like maps or charts with 1000s of datapoints.

> Even with transpired languages or WASM, you still have to use the platform, but now in a non standard language.

That's the entire point of WASM: To program in the browser using any language you want.

IMO, the big flaw is WASM is that browser APIs aren't "first class." IE, all calls to the browser APIs have to go through JavaScript.

That's my point, it's still calling JS at the end of the day. Unless you have some computationally expensive functionality that needs optimization like a large Canvas or Excel-esque table, what's the advantage? Just avoiding JS is not enough of a reason for me.

In principle I support WASM, but in actuality I think it falls short for the majority of applications. It's much easier to learn JS than the web platform. Might as well learn it in the primary language.

I disagree; language choice for a project has a lot of factors: Team familiarity, the need to compile or not, ect, ect.

This is why there are also languages like TypeScript, but they wouldn't work in our case because we want to keep the corpus of languages small.

> It's much easier to learn JS than the web platform.

Just because I know JavaScript doesn’t mean I want to use it. It’s an ugly and cumbersome language.

It's not that learning JS is hard, it's that JS is a very unsafe and unergonomic language. Which is why we have TS... but TS has other problems. People want to use C# or what have you because these are languages that are simply better to develop large applications in. JS, like most dynamically typed scripting languages, becomes more and more of a liability as application size grows.

JS was always supposed to be a scripting language. That you could build whole applications in it was a neat hack but never supposed to be serious. I think a lot of people have forgotten that.

If I have learned anything in decades of developing is that adding layers never short times or make life easier

So you went back to writing assembly...?

If someone suggests that 9 layers is perhaps a touch too many, that doesn't imply that the correct solution is necessarily go back to one layer.

> If someone suggests that 9 layers is perhaps a touch too many (but 8 layers is better than 1)

> adding layers never short times or make life easier

Pick one.

Anyway when people say they don't like abstraction layers what they mean is always they don't like abstraction layers except their favorite ones.

I'm willing to consider there being a happy medium. That doesn't mean more is always better, and it doesn't mean that this particular one is good.

> I think server-side Blazor (with pure JavaScript or TypeScript for logic that needs to happen in the browser,)

Do you mean server side rendering or interactive server mode?

Server-side rendering. I haven't tried interactive mode yet. (It wasn't available when we started our project.)

Would you mind commenting on how it's been going so far? My last consultancy never bought in on .NET web frontend and I haven't had the chance to try it out on a side project, your team liking it so far?

Reply on news.ycombinator.com