Live data from Hacker News

RFC: Adopt a modern JavaScript framework for use with MediaWiki

phabricator.wikimedia.org

61–70 of 293 posts

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

#61
post #39

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…

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

What about linters, static analysis, code highlighting, IDEs? Should we skip those too? Should I dig out my "made with notepad" badge?

Types and good static analysis tools allow me to focus on more important things, such as business logic, scale, planning. We don't pay developers for mental gymnastics, but solving real world problems.

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

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

Vue 3 is getting delayed, isn't it? Not weird for a community project, but still something to note.

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

#63
post #34
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…

I mean, I would be willing to work in company that does not uses typescript.

But a company that goes to irrational length of rewriting dependencies because they use typescript? A company that assumes that seniors don't make simple mistakes? Those are warning flags.

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

#64
post #39

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…

[deleted]

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

#65
post #23
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…

I'm also avoiding typescript as much as I can, but not because typescript itself, but because of how typescript projects tends to be outlined. Lots of the projects are way over-engineered for where they are on the timeline and typescript makes people reach for classes too early. Seeing the same with vanilla JS projects now too when `class` been introduced.

Instead I'm stricly using ClojureScript as the tooling is really solid in everything Clojure, backwards compatibility is a huge selling point in everything Clojure and projects using Clojure/Script tends to be just of the right size and think more about the data structures themselves instead of what many refer to "proper engineering" (SOLID patterns and other nonsense)

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

#66
post #48

Earlier quoted context omitted.

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?

The bigger the virtual dom the larger the performance gap is supposed to be. But, true, would like to see some benchmarks from the real world, i.e rewrites and such.

Perhaps not a great comparison, but here are the Svelte and Vue HackerNews feeds. Not a great deal of difference, but perhaps it's too simple for performance to really matter.

https://hn.svelte.dev/top/1

https://vue-hn.herokuapp.com/top

Edit This site says the Svelte one wins on load times: https://hnpwa.com/

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

#67
post #62

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.

Vue 3 is getting delayed, isn't it? Not weird for a community project, but still something to note.

I don't know, there's no hard deadline but you can check the official roadmap: https://github.com/vuejs/vue/projects/6

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

#68
post #39

Earlier quoted context omitted.

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…

> 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. What about linters, static analysis, code highlighting, IDEs? Should we skip those too? Should I dig out my "made with notepad" badge? Types and good static analysis tools allow me to focus on more important things, such as business logic, scale, planning. We don't pay…

Of course we do that, and I looked at Flow a few times.

But typing errors are such a minor thing in comparison to everything else, than "everything else" is of much higher on the priority list

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

#69
Top 20 free and premium dashboard template in 2020

To track all the performance on your website, these free dashboard templates come very helpfully for your website. With a dashboard template, you’ll know exactly how well your online project is doing. For example, track sales, new members, likes, profits, tickets, you name it, it can all be done inside your ultimate dashboard.

https://is.gd/P7BmMm

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

#70
post #23
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…

> we have a problem of having to "de-typescript" a lot of 3rd party code.

What do you mean by this? npm packages at least are already "de-typescripted", in the sense that they're just .js files with accompanying .d.ts files describing the former to people using editors with TypeScript support.

(Also, it feels like you've experienced a weird subset of TypeScript code. It also happens to be an enormous help when doing things "the Javascript way", which is what it's actually designed for. But I can imagine that encountering bad apples can sour the experience for you.)

Post reply on HN