Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RFC: Adopt a modern JavaScript framework for use with MediaWiki

phabricator.wikimedia.org

Post reply on HN
Print view View original

241–250 of 293 posts

Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki

#241

Post by Udik »

orange8 wrote: post #240
Udik wrote: post #212

Earlier quoted context omitted.

> it will happily allow you to say that a method always returns a string when sometimes it returns a number Just replace "say" with "assume" and you have the javascript situation: javascript is just typescript with documentation stripped off. > Typescript is just documentation that compiles. Exactly. And we're arguing whether code should contain documentation or not.

> javascript is just typescript with documentation stripped off. JS, at its core is a dynamically typed, functional language. Typescript aims to model a strongly typed, OPP language. The two programming paradigms have their own strengths, weaknesses and most importantly: patterns and best practices . If the only difference between your pure javascript code and your typescript code is the annotations, you are doing it…

> Typescript aim to model a strongly typed, OPP language.

Do you think? I just take TS for what it gives me, documentation and static code analysis. I can write down my knowledge and expectations about the code and have the tool keep track of it for me, removing the cognitive load of doing it myself- which I'd have to otherwise.

Can you give me an example of a pattern that is "good" in JS and not in TS, or the other way round? I'm curious.

Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki

#242

Post by ricardobeat »

ddevault wrote: post #128

This thread reads to me like the engineers went into it already knowing they wanted Vue.js, and retroactively doing the necessary mental gymnastics to come up with a rationale. A better justification would have started with "these are our pain points, and this is our evaluation of how these options address our problems." Instead, it's full of weird things like this: >Better support for usage without Webpack/Babel/fro…

I'm happy to see another big project commiting to Vue, but found the rationale funny to say the least, having seen the same kind of analysis multiple times. For example, these requirements:

- UI elements created within the framework are reactive (update automatically in response to changes in data or user input) by default - The framework is heavily optimized for performance

should automatically exclude React itself, but it seems to have been the second option. Despite appearances React is not very reactive, especially with hooks where you do dependency management yourself. Performance is not a given either, nothing is memoized by default and it's all up to the implementer (or the state management system) to actually optimize rendering at all.

The 'large community' mindset which automatically dismisses Svelte and Preact all the time is the most heartbreaking. If we worked with the herd mentality five years ago, neither or React or Vue would have been born and some variant of Backbone would still be the most used view library.

Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki

#243

Post by Udik »

danShumway wrote: post #216
Udik wrote: post #212

Earlier quoted context omitted.

> it will happily allow you to say that a method always returns a string when sometimes it returns a number Just replace "say" with "assume" and you have the javascript situation: javascript is just typescript with documentation stripped off. > Typescript is just documentation that compiles. Exactly. And we're arguing whether code should contain documentation or not.

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 news! Try the same library with no documentation at all then, so you won't get a false sense of safety. If that is your problem, why don't you just avoid importing typings for libraries?

And I don't get this insistence on bugs and safety. Sure, typescript probably prevents you from doing really stupid stuff sometimes, but that's not the main reason I use it. I use it because it both allows me to write much more complex code and speeds up dramatically the development- because the tool takes on itself what is otherwise a heavy cognitive load: remembering and inferring interfaces and signatures that are there all the time, even if implicitly.

Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki

#244

Post by mch82 »

bawolff wrote: post #221
hombre_fatal wrote: post #101

Earlier quoted context omitted.

> but Wikimedia is a website and not a web application Check out the /edit mode for any page. It's already a non-trivial JS app.

The edit view that most power users use is definitely not an spa. There are multiple "editors" in use on wikipedia et al. Visual editor and mobile edior are more SPA-ish, however the old fashioned full of code, editor is still very popular among users. Disclaimer: work for wikimedia, but not on stuff related to this. My opinions are my own.

Another interesting note is that Parsoid, the nodejs service that turns wikitext into the Visual Editor, is being ported from js to PHP.

Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki

#245

Post by [deleted] »

untog wrote: post #166
HumblyTossed wrote: post #158

> The need to evolve our platform is very evident when it comes to how we design, develop, and deliver experiences to users in the browser. > Requirements: > The framework allows UI elements to be defined in a declarative way > UI elements created within the framework are reactive (update automatically in response to changes in data or user input) by default > The framework is open-source, widely used, and has a thri…

To be blunt, this is an extremely common thing in web development and it makes me very sad. But whenever I raise it I’m rebuffed with the vague argument that “developer productivity = more features = better user experience”. Which sounds great in theory but a crappy experience is a crappy experience no matter how many features you put on top. Go look at the lighthouse scores for pages that use React + Redux + whateve…

[deleted]

Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki

#246

Post by sequoia »

anchpop wrote: post #181
untog wrote: post #166

Earlier quoted context omitted.

To be blunt, this is an extremely common thing in web development and it makes me very sad. But whenever I raise it I’m rebuffed with the vague argument that “developer productivity = more features = better user experience”. Which sounds great in theory but a crappy experience is a crappy experience no matter how many features you put on top. Go look at the lighthouse scores for pages that use React + Redux + whateve…

> Go look at the lighthouse scores for pages that use React + Redux + whatever + blah blah and tell me the user experience isn’t sub par I looked at the Lighthouse score for my blog (written in React and all that blah blah). It got a 100 for performance, 100 for accessibility, 100 for best practices, and 100 for SEO. So I am happy to tell you the user experience is not sub par.

Go look at the lighthouse score on my blog: https://sequoia.makes.software/

Also a 100 on performance & time to interactive 0.9 seconds. What are the key features of React that you use to set your blog apart from mine?

Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki

#247

Post by iaml »

BiteCode_dev wrote: post #224
ng12 wrote: post #217

Earlier quoted context omitted.

> The API is full of little details that show you care (I smile every time I see you can do '.prevent" - "oh right, they though of that!"). I tend to have the opposite reaction. I want a framework with a small API I can keep cached in my head. I don't want to worry about finding the magic switches to get it working the way I want.

I see that a lot in the JS world, "libraries over frameworks" and all that. The result is that when you go from project to project, people solve the same problems, again and again, in a different way. And create their own custom abstractions, badly tested and documented. Eventually, the API you could "keep cached in your head" lead to a system you MUST keep in your head because it's very hard to follow how things wor…

>no Django/RoR equivalent in JS

Both angular and ember are pretty close in my opinion.

Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki

#248

Post by iaml »

orange8 wrote: post #240
Udik wrote: post #212

Earlier quoted context omitted.

> it will happily allow you to say that a method always returns a string when sometimes it returns a number Just replace "say" with "assume" and you have the javascript situation: javascript is just typescript with documentation stripped off. > Typescript is just documentation that compiles. Exactly. And we're arguing whether code should contain documentation or not.

> javascript is just typescript with documentation stripped off. JS, at its core is a dynamically typed, functional language. Typescript aims to model a strongly typed, OPP language. The two programming paradigms have their own strengths, weaknesses and most importantly: patterns and best practices . If the only difference between your pure javascript code and your typescript code is the annotations, you are doing it…

> Typescript aims to model a strongly typed, OPP language

That's a rather puzzling statement, to be honest. Strong type system is explicitly one of the non-goals[0]. I write typescript code everyday and most of it is functional. Things like fp-ts[1] make it even more enjoyable.

[0] https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi... [1] https://github.com/gcanti/fp-ts

Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki

#249

Post by manigandham »

danShumway wrote: post #171
inertiatic wrote: post #108

Earlier quoted context omitted.

>This is a good example of the object oriented, strongly typed way of thinking. Explore languages that follow different paradigms, where interfaces just don't apply. I'm not sure whether you intended this to sound so patronizing, but wow. What languages should I explore while talking about Javascript? You are called to edit a function that takes 2 arguments: function handle_req(request, options): What is request in t…

> that will ensure that these situations no longer happen? Well... but Typescript doesn't ensure those situations won't happen, ironically because it's a superset of Javascript and it's not strict enough. Typescript is just documentation that compiles. If a library has bad documentation, it's likely to have bad Typescript as well, and bad Typescript can be a giant curse. Typescript will happily allow you to force a t…

Typescript won't save anyone from intentional writing bad code or using a broken library. Nothing will. I don't see how that's a criticism of TS itself.

Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki

#250

Post by DonHopkins »

orange8 wrote: post #236
giantDinosaur wrote: post #121

Earlier quoted context omitted.

I don't even get this criticism - the problem with Typescript is that it's far too easy to bypass the type system and allow the dynamic parts of JS to do whatever you want. You can lie about your interfaces all day and to your dynamic heart's content. For what it's worth, my experience with programmers who think like you is that rarely they're actually genuinely talented and right, and mostly they just spew forth bug…

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?
Post reply on HN