Both C# and Kotlin have a 'Dynamic' type for just that escape hatch. IMHO, That's a better way over TS - since types might not be the right thing 100% of the time, but they are 95% of the time.
I programmed professionally in C# for about eight years and in that time I can count on one hand the number of times I saw the ‘dynamic’ keyword. Nobody seems to think it’s worth the effort or confusion.
In a past life I did some real wizardry with dynamic in C#, drastically improved performance on a thing that had been using strange combinations of T4 compile-time templates, Reflection.Emit, and some very kooky multi-database lookups with a custom IDynamicMetaObject provider.
It was definitely worth the effort then. I also recognize why it is a very unlikely scenario to repeat.
The other place where I used dynamic most heavily in C# was that it was really great for IronPython interop where you could have a bit of "data science" done in a Python module, build that to a .NET assembly and call into the Python module from C#. (Though the other direction was more common, using IronPython to do data science around a bulk of C# models and code.) With so much more data science since that past life of mine having moved to Python, it's almost a shame that IronPython hasn't really kept up.
Agreed. It’s also not as easily used as “any” in TypeScript. I would probably reject a C# codebase that uses dynamic widely. It’s only good for very local use like some serialization or deserialization.
That's my experience as well, I just wanted to note that the escape hatch exists.
Maybe I should have amended my comments for 99% of the time? Or perhaps that there are other functionalities (e.g. tuple types, reflection) to to make working with types almost as easy as without? I use reflection very frequently...
However, in JavaScript-world, where the external types you interact with - from other libraries, from APIs, from the browser itself - are poorly defined, having that escape hatch becomes a sanity-saver, does it not? That's where the power comes from: the squishy, fuzzy, less structured edges.
The parent-parent comment was "I want an escape hatch in the language" and then the argument for it is "someone else used an escape hatch, and now I need an escape hatch". :D
Well, yes, most of the packages available in the JS ecosystem were written in JS. The easiest way to retroactively write typings is to use `any` all over the place.
I saw other commenter say that the benefit of using TS in the frontend and backend, then DB updates in the backend also update the frontend code: "The beauty of Gary’s setup is changes to his database update the types for the server side Code AND client side code. The value of that comes from using the same language in both platforms"
Can you get this sort of benefit with Kotlin? How?
I would love to do frontend Kotlin, but is it one of those things that you end up painting yourself in a corner and wishing you used TypeScript all along?
I have only played a little with the Kotlin web stuff, but no I would not recommend doing anything serious with it.
I think JS/TS are king because of the ecosystem and wealth of documentation. My experience with more "niche" front-end languages is that you have to do much more yourself or have lots of messy interactions with plain JS libraries.
But even if Kotlin JS had an enormous ecosystem, I'm not sure I would love it. What I love about Kotlin is that it is a great replacement for Java. Interoperating with java has zero performance overhead and zero mental overhead. Because of this and Kotlin's general closeness to Java, many more places writing JVM code are comfortable with using Kotlin compared with other JVM languages like Scala or Clojure. Kotlin cleans up the Java syntax and adds nice features like type inferencing, non-null by default, coroutines, blocks, extension functions and so on.
But if we're not on the JVM, I'm definitely not sold on Kotlin as the perfect language or anything. Sealed classes are nice, but still not as nice as tagged unions. As far as type systems go, I think the one in TS is more flexible and expressive.
Like Kotlin, what I like about TS is the zero mental overhead integration with JS and the JS ecosystem. But if we're not tied to a browser, I guess I wouldn't ever really want to program in TS.
Node is kind of remarkable in that it is the backend platform that is most similar to a browser, which makes these full-stack setups a little more natural. Not sure I'm sold on their value in general since most teams are going to be big enough that front-end and backend code are written separately. If you want to keep types in sync, I think graphql or protocol buffers are better solutions.
It's early days. 1.3.70 was only released a few weeks ago and featured a major overhaul of the kotlin-js related tooling.
I gave it a quick try a few weeks ago and it's actually nice. Before that, it wasn't really usable (dead code elimination was a problem, webpack integration kind of sucked, etc.). With the new tools, it's stupidly easy. It uses webpack and karma underneath but it's all driven from gradle and it works without any webpack or karma specific configuration (you can customize of course). You can depend on both npms and kotlin-js jars. There's a gradle plugin under development that translates typescript declarations for npms to kotlin. So, the development experience is pretty nice. But it will take a while for this to mature and get more users. IMHO the upcoming 1.4 release might kick off some adoption.
IMHO what it needs is proper kotlin frameworks for frontend. Yes, you can use vue and react, etc. But they are kind of optimized for people used to untyped blobs of json. Slapping the word state on this does not quite get you to a level that would be comfortable to a Kotlin developer that also develops for Android. IMHO, it's just a matter of time before people discover 1) you can now do frontend with Kotlin and it doesn't suck 2) we should just scrap the few hundred kb of code that actually gets imported at runtime (i.e. react and related cruft) and build that up from the ground and 4) there's a ton of stuff that was already done for Android that ports over relatively well to the browser world. That's actually a lot less work than it sounds like because the runtimes for frameworks like react and vue are tiny.
Reimplementing react seems to be a rite of passage these days for a lot of people and doing that in Kotlin doesn't sound like it should be that big of a deal. You might be tempted to just use the DOM directly and people do that as well. State management when you have proper data classes, co-routines, channels, etc. becomes a whole different game than throwing balls of untyped json around via global variables.
IMHO this is actually true for typescript as well. The next logical step for typescript would be to cut loose from its js legacy and start having it's own frameworks.
That is usually the outcome of not using platform languages, semantic mismatch with the platform, not able to use the libraries without some kind of FFI or wrapping code, needing extra tooling for debugging.
TypeScript gets away with it, because it follows the C++ Trojan route, without the type annotations it is just JavaScript.
I might be very critical of how WebAssembly gets sold, but one thing is certain, unless browser vendors decide to rip it off, with WebGL/WebGPU + WebAssembly, a few of us will be getting our beloved Flash, Silverlight, Java back, even if in different kind of clothing.
Not a pro C# dev but I use it quite a bit - IIRC the correct keyword for that situation would be 'var' which is similar to 'auto' in C++. It just statically infers the type from the assignment, while 'dynamic' actually does runtime casting.
I use 'var' all the time, I use 'dynamic' only when working with JSON objects and such.
I would avoid using dynamic (I believe underneath it is basically the same as the Dictionary<T, U> anyway, howeve r I don't really care to look it up).
Also regarding var. It is best IMO to use var when evident i.e. If the var right hand side is obvious what the type is use var, if it isn't use the Type name.
e.g.
When you should use var (it is evident from the right hand side)
var name = "Joe Bloggs";
vs when it isn't evident:
var myVariables = _service.SomeMethod();
It allows the code to be better read without the IDE. However obviously it is up to you.
> Use implicit typing for local variables when the type of the variable is obvious from the right side of the assignment, or when the precise type is not important.
> Do not use var when the type is not apparent from the right side of the assignment.
> Do not rely on the variable name to specify the type of the variable. It might not be correct.
Your example has me inferring the type from the method name which isn't dissimilar to what they are advising against here.
TBH I should have known I would get a comment like this, where everyone lives in utopia and everything is always obvious to another person, nobody ever had a bad nights sleep or not feeling their best etc etc.
There are plenty of times where it may not be obvious what the Type it is returning even with quite decent coding standards and in any event I think it helps readability and isn't a huge ask. You can get Resharper / Rider to do this as a project setting (Visual Studio can probably do this out of the box now) in your repo and then the IDE will just do it for you.
MS recommends suffixing `Async`, and VS by default names fields with underscore but the C# naming suggests Pascal. So referencing MS docs is hardly justification.
So? because you disagree with some parts of it, all of it is a bad idea? That is a poor argument.
I've justified quite clearly why I think it is a good idea and in my original post I said quite clearly "It is upto you". It is trivial to turn on in the IDE and it improves readability outside of the IDE.
