251–260 of 293 posts
I have used react and vue and I prefer vue. React is fine but it has a few issues such as having to write className instead of class in the html templates (yes I know why). It's not a big difference between all these new frameworks though, and it will be a huge improvement over html generated from PHP with some jQuery.
Earlier quoted context omitted.
One of their criteria is widespread adoption. Svelte isn't there yet. One day it probably will be, but today is not that day.
I think that's a chicken egg thing. If Wikimedia adopted it, adoption rates would skyrocket.
IMO, to drive adoption rates, you would need dev evangelists
While the RFC states that they are taking cautious route here.
They also mention that they are not making an SPA which all the cool kids look up to.
Earlier quoted context omitted.
This is kind of a subtle idea, but in some instances, the illusion of safety can be harmful. It is occasionally (not always) better not to give people the illusion of safety when that safety doesn't actually exist. Sometimes putting an ineffective railing along a mountain path increases accidents, because it's human nature for people walking on that path to watch their footing less when they see the railing. >> Do no…
> in some instances, the illusion of safety can be harmful > you can catch some shallow bugs around types > If Typescript is giving you a false sense of confidence about using random libraries > Badly documented dependencies are not a problem that Typescript solves. Seriously, what is your claim? That if you have a badly documented third party library with wrong typings then typescript doesn't help? Well, that's some…
Yes? That's exactly what people are doing when they import a dependency written in Typescript into a pure JS project.
> A whole lot of the time, especially in Javascript land you will join projects where libraries are being used, and where documentation is lacking. Your advice here is basically to not be part of those projects? Instead of developing and using tooling that will ensure that these situations no longer happen?
My claim is that Typescript does not solve the problem of joining a project with poorly written, undocumented libraries.
I'm not bashing on Typescript. If the primary way you use it is as an organizational tool to reduce cognitive load and make interfaces more explicit, then that's great. You're using Typescript as intended. And there are some scenarios where a compile-time type-checker is just obviously the right tool for the job.
You started this thread by asking how JS devs could manage 3rd-party interfaces without Typescript. I assume you genuinely want an answer to that question. The answer is that for some people on some projects, using well defined interfaces and keeping a reference page open with documentation is about as fast and about as easy as using Typescript, and that following that process doesn't increase their bug count or cognitive load to the point where they feel the need to introduce a compilation step.
Earlier quoted context omitted.
I think that's a chicken egg thing. If Wikimedia adopted it, adoption rates would skyrocket.
Really, what makes you believe so? IMO, to drive adoption rates, you would need dev evangelists While the RFC states that they are taking cautious route here. They also mention that they are not making an SPA which all the cool kids look up to.
Earlier quoted context omitted.
But react and vue are underneath much closer to each other than Svelte. Sure vue and svelte use templates and react doesn't but that's about it. Anyway since svelte must be compiled i dont think it's good choice for something like mediawiki where you might have plugins and addons that want reuse core components and connect to each other in runtime.
> Anyway since svelte must be compiled i dont think it's good choice for something like mediawiki where you might have plugins and addons that want reuse core components and connect to each other in runtime. Compiled Svelte components are highly reusable and cross-framework like few others.
Earlier quoted context omitted.
I use Vue without a compile step (I abuse Go's templating engine to achieve this). Mostly to avoid the security nightmare of Webpack's 434583593e4735683 dependencies (and most of the other options are not much better) so Typescript is not an option. I love that I can do this with Vue (I can't with React).
so what you're saying is you avoid vue's poor typescript support by not using typescript
Earlier quoted context omitted.
> in some instances, the illusion of safety can be harmful > you can catch some shallow bugs around types > If Typescript is giving you a false sense of confidence about using random libraries > Badly documented dependencies are not a problem that Typescript solves. Seriously, what is your claim? That if you have a badly documented third party library with wrong typings then typescript doesn't help? Well, that's some…
> If that is your problem, why don't you just avoid importing typings for libraries? Yes? That's exactly what people are doing when they import a dependency written in Typescript into a pure JS project. > A whole lot of the time, especially in Javascript land you will join projects where libraries are being used, and where documentation is lacking. Your advice here is basically to not be part of those projects? Inste…
Except that in this way they also lose good typings for any other library and for their own code as well. I understand an outdated definition file can be annoying, but there can be various ways to only ignore type definitions for that specific library.
> My claim is that Typescript does not solve the problem of joining a project with poorly written, undocumented libraries.
That is a problem that no language or tool can solve.
> You started this thread by asking how JS devs could manage 3rd-party interfaces without Typescript.
No, I didn't, you're confusing me with someone else. Inertiatic asked at the beginning of this thread
"Who are these mythical people? [the developers who never make typings mistakes] Do they just magically decipher what interface an argument conforms to? What methods are accessible on a returned result from any random library they're using?"
Then the thread proceeded by 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".
Earlier quoted context omitted.
Wow! What a mature, thoughtful response \s Only the first and last sentences actually addressed the topic, the rest was just an angry emotional attack on those who think differently from you. Hope you're feeling better now.
\s and not /s? I didn't realize there was such a thing a reverse sarcasm. Or is that some new fangled TypeScript string escape character?
Earlier quoted context omitted.
I'm not a myth. Some of us started JS programming over a decade ago, with no strong typing and IDE to hold our hand and tell us every time you make a mistake. The key is just discipline, good design patterns and a good linter. I see TypesScript as a VERY opinionated linter that affects how you think and write JS. JS is a dynamically typed language, which means you loose a lot of its power and flexability by shoe-horn…
> Explore languages that follow different paradigms, where interfaces just don't apply. Interfaces as a general concept applies whether there is a type system to ensure that they are satisfied or not. Do you have function parameter lists? Do you have expected shapes for function inputs and outputs? Do you have distinct types? Then you have interfaces. Your shit breaks when they aren't conformed to. It has nothing to…
Not really. My definition of a language feature is something the compiler supports and checks for. JS does not have interfaces. What you're talking about are patterns and best practices, so you're getting there...
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.
Earlier quoted context omitted.
I'm not a myth. Some of us started JS programming over a decade ago, with no strong typing and IDE to hold our hand and tell us every time you make a mistake. The key is just discipline, good design patterns and a good linter. I see TypesScript as a VERY opinionated linter that affects how you think and write JS. JS is a dynamically typed language, which means you loose a lot of its power and flexability by shoe-horn…
> Explore languages that follow different paradigms, where interfaces just don't apply. Interfaces as a general concept applies whether there is a type system to ensure that they are satisfied or not. Do you have function parameter lists? Do you have expected shapes for function inputs and outputs? Do you have distinct types? Then you have interfaces. Your shit breaks when they aren't conformed to. It has nothing to…
>>Hearing this assurance from someone who just complained about their jenga tower of tooling causing issues, I'm not convinced.
It wasn't me. Maybe a TypeScript compiler will help you correctly follow the comment threads? ;)