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

81–90 of 293 posts

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

#81

Post by williamdclt »

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…

This is the weirdest and least convincing thing I've read about Typescript. I won't comment on such experienced devs spending so much time struggling with tooling that shouldn't change all that often, but I have to react that "fixing Typescript" means "fixing your code".

If you're saying that you can't handle the overhead of Typescript config because your devs already spend so much time struggling with the rest of your tooling, by all mean get your shit together with your tooling, this amount of time spent on it isn't any sort of acceptable. You have huge problems.

> most of devs we hire are long past the stage when typing errors are a thing for them

This is just not a thing.

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

#82

Post by currysausage »

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…

https://html.spec.whatwg.org/multipage/syntax.html#optional-...

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

#83

Post by smichel17 »

cageface wrote: post #59
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…

I would never hire a JS dev with this attitude towards typescript nor work for one. I’ve done JS with and without types. I’d find a new job before going back to working without them. That’s how dramatic the benefits have been in my code.

I like going type-less for prototyping (pun intended), then converting to or rewriting in typescript for anything I'm going to need to maintain or refactor.

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

#84

Post by miffy900 »

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…

> https://github.com/microsoft/TypeScript/issues > Please count the number of open bugs

You do realise the large number of open issues almost certainly relates to Typescript's compiler and language implementation? When a project is written in Typescript, it does not mean all those bugs will inevitably plague the project itself. If I wrote "hello world" in Typescript with a Webpack + Babel project starter, it doesn't suddenly mean I now have thousands of open Typescript bugs to deal with.

Also: the number of closed issues outnumbers open ones by almost x5. Moreover, the total number of issues exceeds 20 thousand; the number is only so high because so many people have already adopted Typescript into their dev workflows. It's a sign it's been battle tested extensively.

> Like half of all genuine bug triage time is already spent on webpack, bable, and other things in the tooling stack. 200 hours a month for $30-$40 per hour devs.

Half? This just seems totally implausible; this could only be true if you were constantly modifying your webpack and babel setup and config files and breaking things.

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

#85

Post by DanielBMarkham »

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.

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

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

#86

Post by kashug »

baybal2 wrote: post #39
manigandham wrote: post #31

Earlier quoted context omitted.

Yea bugs exist, yet there are still thousands of teams using it to build very complex projects with less bugs because of Typescript safety and features. TS tooling either replaces JS tooling or interacts with it seamlessly. It's not like you're skipping JS altogether and there's no type-checking in JS anyway so where's the interference? Can you give a concrete example where TS is a blocking issue for your development…

If you get less bugs because of type checks and you are a serious JS/web dev with 5+ years experience, then your skills are plainly not good enough. People who spent time with JS and webdev in general got to learn that JS is a minefield of a language, and they work with that in mind. Typing discipline is pretty much the first thing people learn when they try doing JS seriously. How to say. There is no way just adding…

When I am writing plain JS I often end up having to write loads of tests to check that I don't to wrong things with types. Did I remember to consider null/undefined? What if I sent in something totally different?

With TS I don't need to spend as much time with these types of tests. I just let the compiler do it for it. If my function says in it's signature the argument can't be null I don't need to do null-checks.

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

#87

Post by jeroenhd »

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 running super basic browsers? Will screen readers support all elements created by the Javascript framework?

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. I hope the Wikimedia foundation can stay clear of unnecessary javascript development as long as possible.

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

#88

Post by oefrha »

DanielBMarkham wrote: post #85
manigandham wrote: post #17

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.

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.
Post reply on HN