RFC: Adopt a modern JavaScript framework for use with MediaWiki • Hacker News Board

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

#31

Post by manigandham » Thu, Mar 19, 2020, 9:26 AM UTC

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…

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?

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

#32

Post by fraktl » Thu, Mar 19, 2020, 9:27 AM UTC

nullc wrote: post #25

fraktl wrote: post #20

Earlier quoted context omitted.

What you wrote is blatant lie, particularly the part with creating a typed component library. I've created 7 components as of yesterday, using TS, zero hacks and zero problems. It's so annoying when a person with clear lack of understanding decides they're competent to critique a tool and then they literally - lie. Keep using React, it's awesome you like it but please - do some fact checking. I know you want to belie…

Would it be so hard to start with an assumption that the person you're responding to is working with outdated information or that they're just confused? Even if they were intentionally lying (why??) it would hurt no one to humor it and be polite, and it would do a lot towards making this a more enjoyable place to read. Your post was informative, too bad it made me just want to close this tab.

> Would it be so hard to start with an assumption that the person you're responding to is working with outdated information or that they're just confused?

Yes.

> Even if they were intentionally lying

Never wrote anyone lied intentionally.

> it would hurt no one to humor it and be polite, and it would do a lot towards making this a more enjoyable places to read.

I'm a programmer used to relay information in least words possible, so I just refer to factual observation. Whether I used word "lie" or had I masked it in a wall of text to spare feelings of flowers - meaning is the same. I consider all people my peers so I don't do to them what I don't want done to me - saying pretty words to hide the meaning.

> Your post was informative, too bad it made me just want to close this tab.

But you had to type what you have before you closed it. I mean, you're calling me out for being impolite by being impolite. I get the whole hypocrisy move and SJW reflex, but my stance is that IT and developers need to relay truth to one another in form of information, not prettify the stuff so people's feelings don't get hurt.

Your feelings got hurt? You didn't get coronavirus because of my text, you'll be ok.

Take care :)

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

#33

Post by MaxBarraclough » Thu, Mar 19, 2020, 9:29 AM UTC

sdan wrote: post #6

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.

+1 on Svelte. Seems like the better/faster option.

Is it really faster for real-world uses?

I know Svelte does clever things to avoid a virtual DOM, but is the difference in practice really appreciable?

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

#34

Post by W4ldi » Thu, Mar 19, 2020, 9:30 AM UTC

Kiro wrote: post #28

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…

Sorry, but that's just crazy. I would avoid your company like the plague.

I've worked with both. And I have to say: It depends. Mostly I feel like typescript slows me down A LOT. In my opinion, the better your code style, guidelines, linting, infrastructure, error reporting and tests - the less you need typescript. I worked in a team that had about 150 micro-apps and services, it was maintained by roughly 15 devs. Each microservice had it's very small scope and it was very very easy to work with it. Everything was very predictable, which made it easy to work without having types.

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

#35

Post by ptrwis » Thu, Mar 19, 2020, 9:35 AM UTC

boobsbr wrote: post #12

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.

That feels like learning Angular template syntax, and I really dislike it. React has its warts, but I find JSX very readable, much more flexible.

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

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

#36

Post by anton_gogolev » Thu, Mar 19, 2020, 9:36 AM UTC

W4ldi wrote: post #34

Kiro wrote: post #28

Earlier quoted context omitted.

Sorry, but that's just crazy. I would avoid your company like the plague.

I've worked with both. And I have to say: It depends. Mostly I feel like typescript slows me down A LOT. In my opinion, the better your code style, guidelines, linting, infrastructure, error reporting and tests - the less you need typescript. I worked in a team that had about 150 micro-apps and services, it was maintained by roughly 15 devs. Each microservice had it's very small scope and it was very very easy to wor…

> ...the better your code style, guidelines, linting, infrastructure, error reporting and tests

Doesn't TypeScript kind of solves (at least partially) those issues?

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

#37

Post by scrollaway » Thu, Mar 19, 2020, 9:37 AM UTC

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…

You're removing typescript because you think it's creating bugs...

You realize you're probably creating bugs yourself by removing typescript manually, which is a thing.. typescript itself can do, by compiling down to JS?

This is some prime dailywtf material.

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

#38

Post by tjpnz » Thu, Mar 19, 2020, 9:43 AM UTC

Not knocking Vue but what exactly is meant by modern? I work on the backend and hardly (if ever) see frameworks described in those terms.

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

#39

Post by baybal2 » Thu, Mar 19, 2020, 9:44 AM UTC

manigandham wrote: post #31

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…

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 typing to JS will make JS less of a JS. You still have to be a very disciplined dev to work with a typescript for it retaining many other tricky parts from JS.

> Can you give a concrete example where typescript is a blocking issue for your development?

Typical example: the tsc transpiler plainly dies, and you know nothing how to debug it, you know nothing of its internals, and you loose the rest of the day doing fruitless email exchanges with typescript dev team, and trying to trace a breaking commit.

Second example: you got a prod breakage report in some hard to reproduce case. You fire a debugger in chrome through vscode, and then you find out that the debugger completely loses the execution flow in transpiler/tooling garbage, and broken source maps. Having a debugger pick code that went through webpack (be it cursed) is already a 50/50 lottery, and additional layer of tooling makes it even worse.

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

#40

Post by StreamBright » Thu, Mar 19, 2020, 9:45 AM UTC

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.

>> This is where Vue shines in adding interactivity to many typical apps without going fully SPA.

That is good to know. I wasn't aware. Most of the apps we are working on cannot be SPAs easily, so it matters if the JS framework supports operating without it.