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

201–210 of 293 posts

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

#201

Post by EvanYou »

est31 wrote: post #187
EvanYou wrote: post #169

Team lead of Vue.js here. Clarifying a few points being raised in this thread: - This does not mean Wikipedia is becoming an SPA. One of the reasons they picked Vue is because Vue can be used to progressively enhance a statically rendered page (just like jQuery, but with a declarative development paradigm), and it allows you to do so without a build step (while keeping the going-full-build-step option open). - Wikime…

As long as there is no accepted non-vue replacement for the server side rendering technology, one has to assume that WP will replace php based rendering with Vue templates on a large scale, even for the static content. However, Vue templates require usage of node.js. I couldn't find any standalone serverside vue template parser/renderer written in something like C++, Rust or Go. So if they adopt Vue, they'd still be…

AFAIK there is currently no plan to replace existing php rendering with Vue SSR. They just wanted to make sure the framework they went with supports SSR so they are not locking themselves out of the possibility.

The HN implementation renders the comments on the client side because it was using the Firebase HN API which doesn't provide a friendly API for fetching the entire comment tree. Notably, some other HNPWA implementations were using a custom API endpoint. We didn't switch to it because the Vue HN was built as an educational demo rather than a benchmarking subject.

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

#202

Post by katabasis »

Hi HN – I'm one of the authors of this proposal. I'd like to clarify a few points here:

* Wikipedia is not becoming an SPA

* Wikipedia is not dropping support for non-js users

* This proposal is not about changing our current browser-support matrix[1] (which includes IE11 as a first-class target; Vue.js ecosystem still supports IE 11)

* This proposal is about changing the way we develop enhanced, JS-only features across our projects; many such features exist already, but they are written in jQuery and an in-house framework called OOUI

* These features will continue to be delivered in a progressively-enhanced way on top of the PHP-rendered baseline for the forseeable future. We are interested in how server-side rendering of JS components can integrate with this but we're still looking into how this might work

* We will continue to prioritize accessibility, internationalization, and performance in everything we ship

I don't think that Vue is "better" than React, but I think it has some features which are especially helpful in our progressive-enhancement, ES5 (for now, anyway) use-case. But it's great to have so many amazing tools to choose from.

Previously we've been using a framework we created in-house for complex JS features, but it's a product of an earlier era of the web and is increasingly out of step with the current paradigms in UI development. We think that one big benefit of moving in this direction is lowering barriers to contribution (both for new developers at the foundation, as well as folks in the wider community).

[1]: https://www.mediawiki.org/wiki/Compatibility#Browsers

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

#203

Post by NetOpWibby »

woutr_be wrote: post #55
NetOpWibby wrote: post #24

Earlier quoted context omitted.

If you wanna see Svelte in production, I’m using it for my homepage: https://webb.page I’m glad to see Svelte growing in popularity here.

Is it open-source? Otherwise it just looks like any other website, the code would be a lot more useful.

Yup! Here it is: https://code.webb.page/Webb/Homepage/commits?branch=primary

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

#204

Post by NetOpWibby »

benbristow wrote: post #41
NetOpWibby wrote: post #24

Earlier quoted context omitted.

If you wanna see Svelte in production, I’m using it for my homepage: https://webb.page I’m glad to see Svelte growing in popularity here.

That page could literally just be a static web page or built using a static site builder like Jekyll/Hugo etc?

Of course it could but once you have a starter template setup it becomes an easy to jump right in.

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

#205

Post by capableweb »

LandR wrote: post #148
capableweb wrote: post #91

Earlier quoted context omitted.

> How are your production bundle sizes? Application I'm working on is not that complex, 20 something different pages with multiple sub-sections themselves, bundle ends up being 1.5MB or something like that, 300kb gzipped. Main weight comes from using multimethods which pulls in a lot of cljs.core, so not using that would make it a lot smaller. Also gonna start splitting the bundle per page but haven't yet. > Are you…

IntelliJ with Cursive is a very good Clojure IDE.

Tried it out before (and your comment actually triggered me to try it out again just to see) but I'm struggling to find anything it does that vim + fireplace doesn't do while vim is way faster and takes less screen-estate so I can have my browser + editor side-by-side.

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

#206

Post by NetOpWibby »

leadingthenet wrote: post #45
NetOpWibby wrote: post #24

Earlier quoted context omitted.

If you wanna see Svelte in production, I’m using it for my homepage: https://webb.page I’m glad to see Svelte growing in popularity here.

What exactly are you using Svelte for? It seems to literally be one HTML page...

To put it simply, I like it. Plus, I have a starter template project that makes it easy to just code and go.

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

#207

Post by NetOpWibby »

cmroanirgo wrote: post #50
NetOpWibby wrote: post #24

Earlier quoted context omitted.

If you wanna see Svelte in production, I’m using it for my homepage: https://webb.page I’m glad to see Svelte growing in popularity here.

Viewing the source shows an html page without a closing body nor html tag: it's probably not the best case for showcasing it seems. The layout it all over the place too using FFox, (it's fine on Chrome and Safari) so it also seems to be lacking in some basic cross browser testing, which again, is not good news when show-casing a framework, as a frameworks' prime responsibility is to ensure cross browser/platform unif…

Interesting, Firefox is my main browser and it's always looked fine to me.

I also built https://socii.network in Svelte/Sapper but that's in need of a rewrite. Just a smidge.

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

#208

Post by user34234 »

I have the opinion that Vue and React are ideal when you do need a SPA (example: when you want to make something that works offline, uses a lot of browser side storage, etc).

For every other application, my favourite tool is https://unpoly.com/, and alternatively Turbolinks + Stimulus.

Most applications do not need Vue or React there is a HUGE abuse of client side JavaScript these days.

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

#209

Post by anchpop »

untog wrote: post #182
anchpop wrote: post #181

Earlier quoted context omitted.

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

Serious question: why are you using React for a blog? What interactive elements are there on the page that require it? EDIT: Saw the link in your profile. I see lower numbers than you, though not by much. But I also see 2.6 seconds time to interactive with 3.1 seconds of main thread work. Broadly speaking, that's fine for your blog. But if it was a site that you expect to add more and more features to over time that…

There are no interactive elements, I just enjoy using React more than the alternatives, even for static content. Instead of asking "what requires react", a better question is "what are the tradeoffs of using react in this situation". In my case React allows me to use Gatsby, a wonderful static site generator, and it also makes it easy for me to add any interactive content I want in the future.

My site will load fine without javascript, so it's hard to imagine react is slowing things down much (although if you've visited before the PWA will mess it up if you try to turn JS off).

For something like Wikipedia, time to interactive isn't that important (which is good, because lighthouse tells me that this page [1] has a TTI of 7.4s). First meaningful paint matters much more. I really disagree with the narrative that anything written with React is going to have a much worse user experience compared to the "old" stack.

[1]: https://en.wikipedia.org/wiki/Matthias_Hansen_House

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

#210

Post by SaxonRobber »

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…

Sounds like you need to raise the bar on hiring if learning static typing is an impediment. I recommend less JS monkeys and looking for actual engineers.
Post reply on HN