RFC: Adopt a modern JavaScript framework for use with MediaWiki

Why don't I consider it strongly typed?: Structurally subtyped as opposed to nominal typing, the pervasiveness of any, allowance for vanilla JS coercion, exceptions and promise rejections are untyped, etc.

A decade ago isn't very long ago. JavaScript is more than 24 years old, and we had to get along without good design patterns or good linters or good debuggers or good libraries or good documentation or good IDEs or good compilers or even good interpreters back then. It sounds like you were late to the party and missed all the fun! ;)

Apologies. That actually explains a lot :)

> 1) ignoring the first part of his question, about having to remember signatures in general, including of your own code; 2) interpreted "random" in a strictly negative way, as if it meant "any junk library" instead of "every library".

The answer to 1) is that remembering type signatures in general (or primarily referencing them through a separate spec sheet) turns out to be about as easy as Typescript for some projects and some people. The answer to 2) is that not "every library" is complicated enough to need extensive bindings, and that since Typescript doesn't help you with junk libraries anyway, the benefits to well-documented libraries turn out to be relatively minor.

I mean, I don't even use an IDE for development. I'm on Vim/Emacs, so the immediate documentation benefits of Typescript you describe literally just don't apply to me. And there are plenty of JS devs in the same position, where their only interaction with the type checker will be during a compile.

The short answer to how people magically know the type signature of random methods is they don't. They use documentation, or they look at source code, which is something I still regularly have to do in the projects where I use Typescript.

----

> Who are these mythical people? [the developers who never make typings mistakes]

In general, typings mistakes aren't a major source of bugs in most of my projects. I only observe them to be a major source of bugs in large orgs where lots of teams are coordinating on large interfaces. And that's not because I'm a genius programmer or have a magic power, there are normal programmers who will find themselves in that situation.

> Do they just magically decipher what interface an argument conforms to?

No, I look at the documentation. In general, I also spend a lot of time on interface design so my interfaces are small enough and consistent enough that I can hold the entire API in my head without much cognitive load and without needing to check documentation very often.

> What methods are accessible on a returned result from any random library they're using?"

I look at the documentation, or the source code if I don't trust the documentation.

You are always going to be able to make the argument that I just don't understand how much time I could be saving. I don't know how to prove to you that this isn't a massive drop in productivity for me, in the same way that I don't know how to prove to you that it's not a massive drop in productivity for me to write DOM manipulation code in Vim instead of Webstorm with tab-completion. All I can say is, I use both JS and Typescript on an almost daily basis, and I pay attention to the cognitive loads, bugs, and time-sinks I have in each environment. The JS environments aren't any slower to program in.

It doesn't matter what your definition of a language feature is. The person you responded to was obviously talking about interfaces in the general sense of the word and was asking a question about it.

> What you're talking about are patterns and best practices, so you're getting there...

Nope, what I'm talking about is interfaces. The nature of function signatures as interface points is not a matter of patterns and best practices. They simply are exactly that, whether it's spelled out for you or not.

> JS is a dynamic language. Just deal with it already... you sound smart enough to support both paradigms at the same time in your head.

This doesn't constitute an argument or an objection to anything I've said. It presumes that I won't "deal with it" when there is no evidence that I'm not. It supposes that "support[ing] both paradigms at the same time", whatever that means, is a matter of my intelligence. It doesn't argue for any of this.

Depends for what. For industrial size project, a little, because of the better typescript support. But that's it. You have the same vscode and browser extensions otherwise.

> we use CRA at my company and I can comfortably drop into projects I've never seen before with complete confidence.

First, on this part I'm talking about JS in general. Only a minority of projects use react.

Of course, not all projects use CRA. Many projects use different versions of react with different things you can do with it. Many projects will chose different convention for adapting components, passing children rounds, talking to parent, binding function, etc.

And I _never_ see two react projects with the same me directory tree. There is no strong convention on it.

Then you must chose.

One project is using an inhouse store with useContext, on other use manual redux with that convention, on use redux with that other convention, one use redux-toolkit, one use manual mobx with that convention, one use mobx react, etc. None of them work the same. None of them integrated the same.

And that's just for one lib. One project as many of such libs, all integrated manually.

And yet, the CRA experience is supposed to be one of the best integration you can have.

When you come from another world like Ruby or Python, it's a mad house.

In fact, I'll argue than only experienced programmers manage to get a consistent experience in the JS world.

> Simple things like placing a setInterval()/clearInterval() at the right place

Nope, in react you can use lifecycle OR hooks. You have to choose. And they don't work the same at all.

In vue, for a simple hello world, you can even place the setInterval outside of the component and hapily modify the model, it will update. You don't have to figure out the lifecycle for small app, only for a reusable component.

>How? It's just JavaScript, write a conditional. This is exactly what I'm talking about: you don't need to know how to conditionally set a class in React, you just need to know how to conditionally set a value in JavaScript.

C strings are just an arrays of char, so you don't have to learn those pesky high level string objects in those modern language with all their new fancy API.

> My go-to example to explain why I find React so much simpler is Vue's slots. It's an entire API that many people find confusing to replicate something that comes for free in React.

In both case the user will google "how to get a reference on children components". There is now way you can guess that it's passed as props.

And then, you will want to have several children at different places. And now the illusion breaks, because props.children doesn't work, you have to manually pass each children as props, and you can use them nested as before. And because it's not a "feature", but a convention, you have to know that you need to do that for components that use it. So it's no more natural that slots.

While in vue, you still use slots, you just give them names. The feature is congruent from the simple use case, to the advanced one.

So maybe for the simple case it took 5 minutes in react, and 6 in vue, and the same time for the complex case. For a rarely used feature.