I was struck by how reactionary some of the responses to this comment are. Many people seemed to feel obliged to firmly question your preferences. Kind of odd, I don't normally notice that as much here on HN.

I expected it because over the years any Dart or Microsoft positive statements I've made have received pushback. Some people can't let go what Microsoft did 20 years ago and assume they are still evil (with GitHub Copilot for example.) Others who are JavaScript programmers can't let go that a Google exec said at the outset that Dart was meant to replace JavaScript. They have fought it over the years.

I almost felt like I was trolling by combining the two, but I'm actually using Dart and Blazor to see how they can work together because Blazor Wasm doesn't do DOM manipulation and Dart does it in such a easy to use fashion that the marriage feels natural to me.

I try not to attack back and have a bit of a sense of humor about it, but it does feel like suppression of thought on HN

Well personally I wasn't questioning the preference itself, I was curious about the purpose of the preference since I've seen people avoid JS/TS both because they don't like it and because it struggles to accomplish certain things. I was simply curious which it was (if either).

Genuine question: is the goal to get something that is not achievable with JS/TS, or is the goal to simply avoid JS/TS?

I really dislike JavaScript for a number of reasons. Dart gives me more distance from it than TypeScript. Of course, I can't avoid it, but I don't have to deal with many annoyances such as which 'this' is this? Should I put 'this' into a var called 'self' to be safe? That's just one example of how JavaScript and I don't get along. I understand some people have brains that think this way, but mine doesn't

The comment reads like you used JavaScript 10 years ago. For instance, just use arrow functions and this remains untouched.

I know but that's just bizarre. One function has it's own this and another doesn't so if my arrow function gets big and I want to make it a regular function I may have to rewrite it. Ugh.

Edit: I'm thinking of cognitive load too. I like to eliminate load I don't need. Keeping track of this is not something I want to do with my life

https://drpicox.medium.com/reducing-programmers-cognitive-ov...

I sometimes refactor code for purely aesthetic reasons. To each his own.

http://www.synergeticapplications.com/ergonomics.htm

By the way, I feel like I'm at a bar and you're negging me

What do you like about Dart over TypeScript? The type system in TypeScript is far superior to Dart's. Other than that, the languages are more-or-less the same.

Actually, I'm taking another look at TypeScript today. I liked it well enough when I last investigated it in 2016, but the code I wrote then was just a veneer over jQuery. I'm sure things have improved dramatically, which I am about to find out. Frankly, a Turing complete type system [1] seems like over-kill to me and a complication I don't need.

Still, Dart had everything I wanted in a front end language in 2013. I think JS devs were short sighted to reject it out of hand. It's a shame it never caught on by itself and not as a just a Flutter language. I read that Google is using it in Fuchsia so there is still a chance Dart will be big in the future!

[1] TypeScript and Turing Completeness: https://itnext.io/typescript-and-turing-completeness-ba8ded8...

I highly recommend TypeScript. I don't really like the JS runtime, but, purely from a language point of view, TS is my favorite.

Some cool features:

1) Type unions

interface A { a: string; }

interface B { b: string; }

type C = A | B;

const c: C = { a: 'a' };

2) Type assertions if ('a' in c) { /* compiler knows c is of type A here */ }

function isA(c: A): c is A { return 'a' in C } // compiler knows c is A if this returns true

3) Nice helper types interface A { ... }

ReadOnly<A> // Like A, but all properties are read-only

Partial<A> // Like A, but all properties are optional

Omit<A, 'someProp'> // Like A, but without 'someProp'

Interesting. I'll learn more today as I rewrite one of my Dart components into TypeScript. But I also dislike Node and Npm so I'll try Deno first.

TBH, TypeScript's type system really impressed me. It's the strongest type system of any language I regularly use (I haven't had time to unpack Rust yet, and I learned enough Haskell to decide Haskell didn't help me solve problems I had).

It’s an expressive type system, but ime it allows developers to go crazy on type interdependencies and general entanglement, so you can’t just go to the “header” and quickly figure out what your method or a return value really is, despite TS has structural typing.

E.g. look at this: https://github.com/telegraf/telegraf/blob/v4/src/telegram-ty...

That's definitely overwhelming. After reading it for 5 minutes though, there is a type called Telegram and it has a field called 'Opts' that has a lot of different fields. MakeExtra lets you take a type from 'Opts' and exclude certain parameters. Probably do something like "you can set the chat message contents, but you can't set the chat id"

TS type system is Turing complete.

https://github.com/microsoft/TypeScript/issues/14833

Surely it's easier to stick to JavaScript The Good Parts than to introduce a whole new layer in the form of Blazor?

Blazor is not equal to JavaScript. Blazor is Microsoft's answer to React and Flutter. So far of the three, I like Blazor, but not the server version that uses SignalR to communicate with the client because it locks you in. Blazor Webassembly is awesome, but just needs a good DOM manipulation library. With Blazor Wasm on the client, I can use anything on the back end.

> I really dislike JavaScript for a number of reasons.

Might I suggest being less sensitive/that your reasons are overblown?

I don't like liver and horse radish either. Should I eat that because a lot of people like it?

What's C# giving you that Dart isn't, OOI? My impression is they're fairly similar languages. (Does Dart not have a WebAssembly backend?)

Blazor is using C# to build web pages, which isn't new, but using C# on the client with a webassembly version of .NET. It works well enough, but is limited to simple things like onClick="SomeCSharpFunction" and can not do things like getting elements by id or class. That's were Dart shines. Most will use either JavaScript or TypeScript, but I like Dart so I want to see how it is to combine Blazor Webassembly with Dart.

It would be even more interesting if there were a Dart.NET

My point is: why C#, why Blazor? What's that doing that you couldn't just do in Dart itself?

For someone about to go knees deep into Blazor very soon.

Do you have any gotchas which isn't really mentioned on MS documentation site? primarily related to performance, since it will be one of my main concerns.

If one of your main concerns is performance, then all I can say is don't use Blazor. WASM will never be able to compete with regular JS so long as it has to go through an interop layer, plus it has to send down and parse an entire interpreter before it can even start looking at your actual UI and business logic. Server Side has to wait for a server response for every single action you take, and any small drops can make the entire thing sluggish, or even buggy.

That's not to say it isn't cool and can't work for some projects where say, development speed is more important, but performant it just aint.

If you're talking site load time you'd have to be careful because netdot is compiled as wasm, which doesn't leave a lot of room below the standard site size. It's hard to tell because even ordinary sites now are huge. I need to do some testing.

What's wrong with JS bindings? Surely DOM manipulation is slow enough for WASM/JS overhead not being noticeable.

You still need to go through a port with Blazor, but you can minimize those calls for the most part. DOM manipulation was slow as recently as a few years ago, but improvements to Blink have made it blazingly fast. I agree with Svelte that we no longer need a virtual DOM

https://svelte.dev/blog/virtual-dom-is-pure-overhead

Edit: I didn't answer your question. There's nothing wrong with JS bindings. Both Blazor and Dart use them, which could get awkward going from Blazor -> Dart (as JS) -> JavaScript lib. I'm considering TypeScript again because no port is needed to call JS libs.