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

71–80 of 293 posts

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

#71

Post by idoubtit »

manigandham wrote: post #18
jeswin wrote: 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…

Using Vue's pseudo-HTML directives might be easier for many cases, but it is less powerful than JavaScript. In some cases, these restrictions leads to workarounds or rewrites. I agree with the grand-poster that the added value is controversial.

As for JSX with Vue, it's clearly a second class citizen. For instance, last I checked, JSX + TypeScript was broken, though both are officially documented with Vue.

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

#73

Post by blackoil »

baybal2 wrote: post #29
manigandham wrote: post #26

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…

Ratio of open/closed issue is a very strong indicator of how active a project is. My perspective, with 21k closed and 4k open issues, shows a very active project where I should not be finding major blockers if I adopt it. If it has an issue 1000s of people are actively looking at it and it will be caught at beta stage or will be solved quickly.

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

#74

Post by christophilus »

capableweb wrote: post #65
baybal2 wrote: post #23

Earlier quoted context omitted.

A reverse situation here. I deal with strict no typescript policy, so besides a problem of finding typescript devs, we have a problem of having to "de-typescript" a lot of 3rd party code. Typescript has a lot of adoption within with ex-Java devs, and with that comes a lot of "Java-think." It's hard for these people to adapt to not doing things "the Java way" and vice versa. And another part of the problem is that peo…

I'm also avoiding typescript as much as I can, but not because typescript itself, but because of how typescript projects tends to be outlined. Lots of the projects are way over-engineered for where they are on the timeline and typescript makes people reach for classes too early. Seeing the same with vanilla JS projects now too when `class` been introduced. Instead I'm stricly using ClojureScript as the tooling is rea…

I’m spinning up a few new projects at the moment, and was sooo close to doing them in ClojureScript. I ended up going with JavaScript, Preact, and Rollup just because of familiarity allowing me to move faster. That, and my build times are sub-second, something that was not true of my previous Webpack and typescript projects. My total application bundle size is still smaller than React alone.

ClojureScript is really good, though, I gotta say. How are your production bundle sizes? Are you using shadowcljs? If not, what tooling are you using? Also, what editor? I’m a VSCode guy, and last time I used Clojure (a year or more ago), Calva wasn’t up to snuff. I wonder if that’s changed.

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

#75

Post by twsted »

omnimus wrote: post #14
eknkc wrote: post #4

Well I guess you can not go wrong with either React or Vue at this point as they have mature communities. However I feel like while React is just fantastic on its corner, Svelte seems like a better built Vue than Vue. It lacks the community but technically feels like a refinement and enhancement of Vue’s ideas. I wish it would gain more traction.

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.

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

#76

Post by tannhaeuser »

The requirements listed for a "modern JavaScript framework" are completely generic. Of course, if you include requirements such as "declarative" and "broad mindshare", you can only arrive at React, Angular, or Vue - at the moment that is.

Is this for internal Wikimedia apps or intended as a long-term replacement for Wikipedia/MediaWiki? If the latter, a prime requirement surely would be to support MediaWiki markup wouldn't it?

The problem with this kind of assessment starts with the deliberate decision that you need a JavaScript "framework" at all in the first place (that isn't just motivated by a junior dev seeking to pad his/her resume). Going from there, since you desperately want to persuade yourself that today's frontend landscape isn't just a result of big media influence (Fb, Google), you necessarily choose Vue (I know several companies who settled on Vue because they couldn't stand the React hype).

In other words, decisions for a particular JavaScript framework are as generational as ever, and the hope for a choice with a long-term perspective is futile, because a new generation of webdevs will soon re-invent their generation's framework since maintaining daddy-o's web framework isn't fun, and because every developer wants to carve out a niche for creativity.

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

#77

Post by williamdclt »

manigandham wrote: post #17
112 wrote: post #5

I've loved Vue for a long time, worked two years with it almost daily, but right now I avoid it as much as I can, as I can't stand working with JavaScript without TypeScript. The TypeScript support in the current version of Vue is crap, and the simplest things, such as creating a (typed) component library, are hard and require numerous hacks. If I were to use something that lacks TypeScript support, it would be Svelt…

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

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

#78

Post by keithnz »

manigandham wrote: post #17
112 wrote: post #5

I've loved Vue for a long time, worked two years with it almost daily, but right now I avoid it as much as I can, as I can't stand working with JavaScript without TypeScript. The TypeScript support in the current version of Vue is crap, and the simplest things, such as creating a (typed) component library, are hard and require numerous hacks. If I were to use something that lacks TypeScript support, it would be Svelt…

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.

you can use the composition api already in Vue2, which is what I have been doing, and I'm using typescript for everything. There is a chance the api may change, but it seems pretty stable. I combo this with using tailwindcss and I think that makes for a pretty productive combo.

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

#79

Post by orange8 »

inertiatic wrote: post #53
baybal2 wrote: post #29

Earlier quoted context omitted.

> 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…

>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-horning it into strongly typed languange patterns. Yes, I get it, many programmers think best and are most productive using strongly typed languages, but for those of us that can think dynamic or both, TS just gets in the way.

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

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.

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

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

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

#80

Post by keithnz »

idoubtit wrote: post #71
manigandham wrote: post #18

Earlier quoted context omitted.

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…

Using Vue's pseudo-HTML directives might be easier for many cases, but it is less powerful than JavaScript. In some cases, these restrictions leads to workarounds or rewrites. I agree with the grand-poster that the added value is controversial. As for JSX with Vue, it's clearly a second class citizen. For instance, last I checked, JSX + TypeScript was broken, though both are officially documented with Vue.

I haven't found it very limiting, however, because it is very well defined, in Vue3 they are looking to actually use this to make massive optimizations in rendering that you simply can't make when you use javascript anyway you like to assemble things.
Post reply on HN