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

101–110 of 293 posts

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

#101

Post by hombre_fatal »

jeroenhd wrote: post #87

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…

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

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

#102

Post by aww_dang »

jeroenhd wrote: post #87

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…

>I have seen too many sites collapse into an empty white page because whatever javascript they were running couldn't access a resource and the shitty JS framework just stopped, leaving me with an empty page.

It is even worse when these pages are basically images and text. SPAs have their place and people can develop them as they wish, but I fail to understand why these frameworks have become the go to solution for every page.

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

#104

Post by est31 »

hombre_fatal wrote: post #101
jeroenhd wrote: post #87

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…

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

I'm ok with their interactive editor being written in SPA style. Most of Wikipedia's billions of users aren't editing pages though. For them, WP should focus on rendering speed which means lowest complexity possible, which means keeping the serialized DOM technology.

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

#105

Post by DanielBMarkham »

oefrha wrote: post #88
DanielBMarkham wrote: post #85

Earlier quoted context omitted.

Apologies, I a bit confused. SPA stands for Single-Page Application, does it not? So if you have a single page that works as an application, it is a SPA, no? I understand the desire to use webkit, Typescript, and so forth to develop modern apps, I'm just confused at why Vue in a stand alone page delivered by ftp or usb drive isn't a "full" SPA

You can mix and match traditional server-rendered content and JS framework (in this case Vue)-rendered components on the same page (not considering SSR here). Going full SPA means using the latter exclusively.

Got it. Thanks. We have several content-delivery pipelines at work. It had been so long since I used server-side dynamic content creation that it had slipped my mind.

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

#106

Post by imtringued »

boobsbr wrote: post #47
ptrwis wrote: post #35

Earlier quoted context omitted.

I dislike both. Most readable template syntax for me is PHP's "alternative syntax for control structures" (the one with colons instead of braces and closing keywords).

That feels like JSP to me, and I don't have fond memories of JSP.

JSF somehow managed to be even worse than JSP.

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

#107

Post by MatthewPhillips »

This is a bad idea. If you look at the list of advantages to doing this only 1 is user-centric (things would be reactive). The rest are all related to how it makes development easier. When you choose a developer-centric workflow your users will suffer.

You only have to look at the numerous server to SPA conversions to see how consistently bad of a choice this tends to be; Reddit is a big and obvious example.

They could take a half-measure and move away from the brittle jQuery based front-end they are currently using by adapting those to use something like Preact, while leaving the rest of the page alone. This would give you more dynamic and more maintainable page widgets without the sacrifices that inevitably occur when you move the entire site to being front-end rendered.

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

#108

Post by inertiatic »

orange8 wrote: post #79
inertiatic wrote: post #53

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…

>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 this context and what is options?

What makes me more productive, going up the stack and seeing who might call this function and with what argument, or instantly knowing what the domain of values it operates on is and being able to treat this as a separate unit?

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

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?

Okay.

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

#109

Post by 112 »

baybal2 wrote: post #23
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…

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…

Every language comes with its own culture, and with its own stereotypes. Java's over-engineering and boredom, JavaScript's throwing shit on the wall and see what sticks, PHP's developers that do stackoverflow-driven development.

There are experts, average people, and bad people in every field. TypeScript brings sanity that is valuable for both experienced developers and less experienced developers.

The peace of mind that you get with types when doing refactoring is invaluable. I would never be able to go back and write vanilla JavaScript, because it's broken.

You can over-engineer and write crap code in any language.

Also a comment on anyone that says experienced devs get no benefit from types: you think you're good, but you're not. As good as you think you are, if you seriously deny the benefits of static typing, you're probably shit as a developer. If you understand static typing and it's benefits then you agree it's a good trade, if you don't understand it and still have a strong opinion against it, then you're just a lazy human.

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

#110

Post by 112 »

mcny wrote: post #15
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…

I've only used angular but I'm curious, why has angular never been an option for you? I've never used react but I think you can use typescript with react if you wanted to, right? it just isn't the default but if you're in react land, you probably don't care much for defaults?

React with TypeScript is a joy. I have the utmost respect for Angular, and for the way it pushed forward progress on frontend. Vue itself has taken many great ideas from Angular.

It hasn't been an option for me because I found it quite opinionated for personal projects, and in my work context I didn't enjoy / respect the people that were working on Angular projects. This is not about Angular, it's about where I was working and the people there.

It's easy to judge a tool by it's users, but we mustn't.

Post reply on HN