Live data from Hacker News

RFC: Adopt a modern JavaScript framework for use with MediaWiki

phabricator.wikimedia.org

121–130 of 293 posts

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

#121
post #79

Earlier quoted context omitted.

>Typescript will not help us a dime with type checking for most of devs we hire are long past the stage when typing errors are a thing for them. Who are these mythical people? 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?

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…

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 bugs which often sit dormant until they rear their ugly heads years later. Most people are better off thinking about their API's before they implement them, much like one would do in a real engineering discipline. Types are often (and yes, not always) a good way to draw the effort out to the front of your process.

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

#123

Earlier quoted context omitted.

Vue 3 will change all that. It's written in typescript with first-class support and the composition API is like React hooks but better for most cases. Vue's templating is standard HTML which means it can be delivered by any server-side language/framework. This is where Vue shines in adding interactivity to many typical apps without going fully SPA.

It is standard HTML in the sense that it's valid HTML, which React JSX isn't, of course. But without the JS runtime it won't do anything, so in the end what's the advantage over React? You can add interactivity without going full SPA with React too after all

It's a subtle but huge difference. In React, using JSX means you can create components and mount them on top of the existing elements on the page.

With Vue's HTML templates, the page itself can be the component and everything can become interactive. For example, you can easily output a HTML table from server-side code, then Vue can convert that into a interactive component while using the existing structure and data.

This lets you render the page using existing web frameworks, it's faster because the server puts it together, it's progressive enhancement and works without JS and on slow devices, and Vue can seamlessly add on top with nothing more than a single JS tag and no compilation step.

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

#124
post #79

Earlier quoted context omitted.

>Typescript will not help us a dime with type checking for most of devs we hire are long past the stage when typing errors are a thing for them. Who are these mythical people? 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?

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 do with strong typing or object orientation. Strong, static typing is just a way to ensure at compile-time that the expected interfaces are satisfied.

> Do not use random libraries. A good library should have even some basic docs outline its API and how to use it.

Hearing this assurance from someone who just complained about their jenga tower of tooling causing issues, I'm not convinced.

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

#125
>Better support for usage without Webpack/Babel/front-end build tools

It looks like it's reasonably easy to setup run-time JSX compilation by using a service worker with babel to intercept and transpile .jsx files. I imagine the performance tradeoffs would be similar to using Vue with string templates? Could be faster actually since you could memoize/cache in the service worker

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

#126
post #9

I looked at Vue.js and came away with the impression that it requires me to learn a lot of framework-specific implementation details. For instance, a list requires that you know the v-for directive, while in React it's just JavaScript's Array::map(). Couldn't see the value there.

These directives take less than a day to learn. 99% of the time it's far easier to write HTML tags with data and event binding directives than hack around with JSX and passing all those props. You can also use JSX with Vue if you want. Just add a render() function to the component. That's what happens anyway when you use a normal template, the Vue compiler turns it into a render function the same way JSX is compiled…

and using promises with vue is nightmare.

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

#127

What does this mean for Wikimedia? Will they extend file uploaders and such with some fancier animations and code or will Wikimedia turn into another one of these God-awful Javascript applications running an HTML renderer inside the browser's HTML renderer? Don't get me wrong, Javascript web applications have their place, but Wikimedia is a website and not a web application. Will Vue and React work on 2G cell phones…

The proposal stresses the need for Server-Side Rendering so I suppose they're thinking about this.

Yeah it's very clear that they still plan to have the website work without JavaScript.

In the longer term, adding support for a frontend build step in deployment and for server-side rendering (SSR) of UI components are two tasks that would be particularly useful here...

Until such features are in place, use of Vue.js would be limited to cases where server-rendered elements can be progressively enhanced within the user’s browser.

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

#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/front-end build tools

>We should still explore introducing a full build step in the future (including full support for module bundling, ES6+ transpilation via Babel, etc), but this is a non-trivial change to the architecture of MediaWiki.

A non-trivial change to the architecture of MediaWiki, such as, for example, overhauling the frontend JavaScript with Vue.js? 90%+ of all software has a build step, this is a well-understood problem and has been since before Wikimedia existed in the first place.

They also mentioned that they want a framework which "has a thriving community (and we anticipate this will continue to be the case for years to come)", then picked the framework which has been the underdog since its inception (not that I think any of the other choices they evaluated would have been wise, either). They wanted to use Vue, so they're going to use Vue.

For a website like Wikipedia, it would have been better to consider the alignment with their core mission. A lot of new technology doesn't work in older browsers whose collective market share is still ~5%. A project like Wikimedia is used by effectively 100% of the population, which means that designs which eschew 1% of the population are eschewing tens of millions of people. That's not to mention that these technologies, even when supported, require more computational resources to work, which will make Wikimedia harder to use on low-end or older devices. They considered performance - but only as far as the libraries they "evaluated" compare to each other, not to their baseline.

These kinds of kangaroo court evaluations of technologies for use in a software engineering team make me sick, especially because I'm guilty of having done this before.

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

#129

What does this mean for Wikimedia? Will they extend file uploaders and such with some fancier animations and code or will Wikimedia turn into another one of these God-awful Javascript applications running an HTML renderer inside the browser's HTML renderer? Don't get me wrong, Javascript web applications have their place, but Wikimedia is a website and not a web application. Will Vue and React work on 2G cell phones…

A lot of the questions you're rhetorically asking are answered in the RFC you're commenting on.

Specifically, they had real problems with their current system, which they documented here: https://phabricator.wikimedia.org/T225453. Then they explored the available options in the ecosystem and came up with the one they thought would best fit their needs.

If you're gonna be critical, at least take the time to understand what they're doing and why.

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

#130
post #29

Earlier quoted context omitted.

Why? Typescript just compiles down to JS, and type definitions are used IDEs so they still help when writing JS. How does removing typescript help you?

> How does removing typescript help you? https://github.com/microsoft/TypeScript/issues Please count the number of open bugs JS tooling is already an enormous jenga tower as it is, with tooling breakages eating a double digit of developer time. Adding typescript on top of that would be the real madness. Typescript will not help us a dime with type checking for most of devs we hire are long past the stage when typing…

> long past the stage when typing errors are a thing for them

Nonsense. Static type systems help you write correct code. They're also extremely helpful for refactoring. They also help readability. Outside the JavaScript world, they also help performance. The list goes on.

No-one is too smart for type systems to be helpful.

> it does not pay off at all

You've entirely ignored that TypeScript helps reduce bugs, and helps catch them earlier.

Post reply on HN