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

231–240 of 293 posts

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

#231

Post by karatestomp »

matthewmacleod wrote: post #194
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. It's genuinely terrifying to think that people out there with this attitude are producing software that I might be at risk of using.

Seriously. “We manage OK without static types” is one thing but “LOL we’re not n00bs so we don’t need your productivity-killing static types” is... wow. WTF. Keep anything that team writes far away from important data and processes, please.

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

#232

Post by vorpalhex »

k__ wrote: post #176
vorpalhex wrote: post #165

Earlier quoted context omitted.

Server side rendering is slow and expensive . Wikipedia needs to be fast for all of it's users, and needs to be very cost centric.

Static site generation is very cheap in terms of generation and delivery.

Yes, SSR and static are not the same.

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

#233

Post by karatestomp »

vorpalhex wrote: post #165
k__ wrote: post #99

Earlier quoted context omitted.

Modern JavaScript runs on the server just fine, they will probably use server side rendering and build time rendering.

Server side rendering is slow and expensive . Wikipedia needs to be fast for all of it's users, and needs to be very cost centric.

Weird, most of the fastest-feeling sites I use are server-side rendered. Though I doubt they use any JS in that path. Maybe basic html Gmail does but probably it’s Java or something.

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

#234

Post by belval »

whycombagator wrote: post #198
belval wrote: post #133

I'm not a frontend dev, in fact I know little about the current "cool" JS framework. That being said, I donate to Wikipedia/Wikimedia every year and I will reconsider if this goes through. This is exactly the kind of bloat that no one needs. The Wikimedia sites should be seen as a public library where accessibility is the most important thing. Creating a web app with apparently no measurably good impact is pure idioc…

> I'm not a frontend dev, in fact I know little about the current "cool" JS framework. > That being said, I donate to Wikipedia/Wikimedia every year and I will reconsider if this goes through. This is exactly the kind of bloat that no one needs. The latter seems an overreaction given the former.

It is absolutely an overreaction, and I don't see myself going through with something like that. I use the site probably daily and feel like I have to donate.

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

#235

Post by belval »

jdlrobson wrote: post #211
enriquto wrote: post #144

Earlier quoted context omitted.

Whatever, but if wikipedia somehow becomes unusable without javascript, it will be a real tragedy.

You dont need to be worried about this. Our morales and principles are not changing. I built the Wikipedia mobile site and there's a reason our hamburger menu, lazy loaded images and editor actually work without JS. We are for everyone regardless of internet connection speed, device value and internet stability. That's a a hill at least I as an employee am prepared to die on.

If that's the case then I am sorry for my earlier comment, Wikipedia is a treasure and you are doing amazing work!

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

#236

Post by orange8 »

giantDinosaur wrote: post #121
orange8 wrote: post #79

Earlier quoted context omitted.

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

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

#237

Post by [deleted] »

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…

[deleted]

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

#238

Post by ng12 »

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…

> It took me 2 weeks to understand react, and much more to actually write decent code with it. Practically, react is very unproductive without something like create-react-app because you have to take so many decisions about it for every new project.

I won't argue that bootstrapping a React project is more complicated than a Vue project. I will argue that React's developer ergonomics are much better.

> Everybody has a boilerplate one of course. Nothing is standardized, so the ecosystem is not reusable.

Not sure what you mean. We use CRA at my company and I can comfortably drop into projects I've never seen before with complete confidence.

> Simple things like placing a setInterval()/clearInterval() at the right place

This doesn't make sense to me. The pattern for setting/clearing an interval with the class-based React API is identical to Vue. With React's hook API it becomes even easier.

> or conditionally settings classes on stuff is not straightforward

How? It's just JavaScript, write a conditional. This is exactly what I'm talking about: you don't need to know how to conditionally set a class in React, you just need to know how to conditionally set a value in JavaScript. I get really tired of the "how do I do task X in Framework Y". I want to ask that question as few times as possible.

My go-to example to explain why I find React so much simpler is Vue's slots. It's an entire API that many people find confusing to replicate something that comes for free in React.

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

#239

Post by orange8 »

inertiatic wrote: post #108
orange8 wrote: post #79

Earlier quoted context omitted.

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

> I'm not sure whether you intended this to sound so patronizing, but wow. What languages should I explore while talking about Javascript?

Why would the suggestion to explore non OOP, strongly typed languages sounds patronizing to you? The more different languages you play with, the broader your mental modelling toolset becomes. It is painfully obvious to me that someone worried about interfaces in JS is not very familiar with more dynamically typed or/and functional languages. JS is a VERY FLEXIBLE language which can be coded in any style, which is why I've suggest playing with something more opinionated to get the gist. Languages like XSLT, Erlang, LISP, Haskell etc.

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

The fact that you can edit handle_req means it is application code. So how you figure that out comes down to the structure and patterns you and your team use (if any) and the available documentation (if any). You'd be surprised how far Eslint and JSDoc will take you. TypeScript accomplishes the same, and I've no problem using it within a team that needs it but personally, it feels like an overkill I don't really need to.

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

The decision to use TypeScript or any other tooling should really be made at the BEGINING of a project, so why are we talking about projects that already missed the boat, and even worse lack documentation and tests? This just proves my point, what you really need is discipline (documentation, tests, best praise etc) and a good linter, not a whole new language or programming paradgim.

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

#240

Post by orange8 »

Udik wrote: post #212
danShumway wrote: post #171

Earlier quoted context omitted.

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

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

Post reply on HN