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

281–290 of 293 posts

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

#281

Post by orange8 »

Udik wrote: post #241
orange8 wrote: post #240

Earlier quoted context omitted.

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

> Typescript aim to model a strongly typed, OPP language. Do you think? I just take TS for what it gives me, documentation and static code analysis. I can write down my knowledge and expectations about the code and have the tool keep track of it for me, removing the cognitive load of doing it myself- which I'd have to otherwise. Can you give me an example of a pattern that is "good" in JS and not in TS, or the other…

A good indirect example is an actual feature added to JS recently, which are classes. Classes are the main unit of OOP, while functions are the main unit in the functional paradigm. The class syntax in JS is not a real new structure added to the language, but just syntax sugar. Underneath it all, the JS compiler just converts it to a regular JS function using a specific pattern. You could, if you wanted, save the compiler that work by just coding using that pattern to begin with.

When using TS the class syntax fits in perfectly for me, an in pure JS I'd stick to functions.

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

#282

Post by Can_Not »

rk06 wrote: post #161
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.

do you want to see the value? if so, here it is: By itself, there is no inherent value in either v-for or Array::map(). However, these choices do not exist in a vacuum, they are other decisions in place, which do provide significant value: - React, allows full power of js when writing template. and easy to express and decompose components into functions. while Vue does not allow the fine-grained in template unless yo…

React: supports JSX and vanillajs render function.

Vue: supports JSX, vanillajs render function, pug, and its default HTML templates.

You: "React allows full power of js"

Ok

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

#283

Post by Can_Not »

shirshak55 wrote: post #175
martin_a wrote: post #10

Earlier quoted context omitted.

Right now, Corona made some time for that, I'm rewriting something I tried to do in Vue. I don't work with Vue daily and that makes it real hard to do even the simplest things. I'm back to vanilla JS, few sprinkles of jQuery and HTML5. Works well for me.

exactly. React works so well with js. And vue claims to be simple but tbh its hard. working with async await function, promises are so weird. And you need packages for simple stuff also.

Really? async/await just works by in Vue. And React doesn't need packages for simple stuff? Really??? Are you sure you've ever used Vue?

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

#284

Post by Can_Not »

shirshak55 wrote: post #126
manigandham wrote: post #18

Earlier quoted context omitted.

These directives take less than a day to learn. 99% of the time it's far easier to write HTML tags with data and event binding directives than hack around with JSX and passing all those props. You can also use JSX with Vue if you want. Just add a render() function to the component. That's what happens anyway when you use a normal template, the Vue compiler turns it into a render function the same way JSX is compiled…

and using promises with vue is nightmare.

[Citation Needed]

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

#285

Post by Udik »

orange8 wrote: post #281
Udik wrote: post #241

Earlier quoted context omitted.

> Typescript aim to model a strongly typed, OPP language. Do you think? I just take TS for what it gives me, documentation and static code analysis. I can write down my knowledge and expectations about the code and have the tool keep track of it for me, removing the cognitive load of doing it myself- which I'd have to otherwise. Can you give me an example of a pattern that is "good" in JS and not in TS, or the other…

A good indirect example is an actual feature added to JS recently, which are classes. Classes are the main unit of OOP, while functions are the main unit in the functional paradigm. The class syntax in JS is not a real new structure added to the language, but just syntax sugar. Underneath it all, the JS compiler just converts it to a regular JS function using a specific pattern. You could, if you wanted, save the com…

So you're giving a javascript feature as an example of a pattern that doesn't fit javascript. Then you claim to use an equivalent but syntactically different form in js? How does this constitute a different pattern?

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

#286

Post by boomlinde »

orange8 wrote: post #275
boomlinde wrote: post #267

Earlier quoted context omitted.

> Not really. My definition of a language feature is something the compiler supports and checks for. JS does not have interfaces. It doesn't matter what your definition of a language feature is. The person you responded to was obviously talking about interfaces in the general sense of the word and was asking a question about it. > What you're talking about are patterns and best practices, so you're getting there... N…

> It doesn't matter what your definition of a language feature is. The person you responded to was obviously talking about interfaces in the general sense of the word and was asking a question about it. Really? So now this has devolved into a debate about semantics? I thought this was about JS and TS, not the "general meaning of interfaces". Using that way of thinking, even HTML and CSS have interfaces. Arguing over…

> Really? So now this has devolved into a debate about semantics?

You just reasoned on the basis of your "definition of a language feature" that I am wrong. Don't blame me for turning it into a discussion about semantics.

> I thought this was about JS and TS, not the "general meaning of interfaces". Using that way of thinking, even HTML and CSS have interfaces.

It is about JS and TS. A poster asked, about JS developers, "Do they just magically decipher what interface an argument conforms to?". There is a reasonable answer to that, and it isn't "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", which doesn't answer his question and instead assumes that the poster simply hasn't explored languages that for some unargued reason will change his question.

Obviously he is not talking about interfaces as a language feature, since he acknowledges that JS doesn't have explicitly defined interfaces.

You yourself have been talking about library APIs. I'm sure you know what the I stands for.

> Are you saying an interface is a function signature and is this what you mean by interfaces in general?

I am saying that they are interfaces. I am not saying that function signatures constitute the entirety of interfaces in general, and I'm not sure what I wrote that makes you even ask that question.

> My responses do not have to be blow by blow objections to every single point you make. This is a discussion, not a computer program.

It's a discussion, and I participate to discuss things, not to hear you tell me to "deal with it". But sure, I can't stop you from participating on whatever basis you prefer. I just want to point out that I get absolutely nothing out of it, so if you're writing that for my sake you can stop.

> And I stand by the sentiment: for optimal results, think functional when working in a functional language.

This is not about functional vs. non-functional. It's about JS and TS, as you've pointed out yourself.

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

#287

Post by DonHopkins »

orange8 wrote: post #280
DonHopkins wrote: post #271

Earlier quoted context omitted.

I think what Andrew Hejlsberg himself, the designer of C# and TypeScript, said speaks to the claims orange8 is making about TypeScript being a "VERY opinionated linter" and that "you loose a lot of its power and flexability by shoe-horning it into strongly typed languange patterns". Andrew Hejlsberg's point is that TypeScript is a "multi-paradigm" language: it's not just strongly typed, but also structurally typed, i…

>> you don't "lose" anything: you actually gain more "flexibility" and more "language" patterns. You do not need TS to use OOP language patterns in JS. Remember TS is compiled down to JS, so all that flexibility comes from JS. The same flexibility that makes the concept of TS and the 100 other "compile to JS" languages possible. Some of that flexibility is lost because you let the TS compiler make some decisions for…

You're factually wrong: zero flexibility is lost. Not even any "flexability". (But I'm glad we're both using the same word now -- I was worried you had some completely different definition of "loose languange flexability" that you were arguing, because you don't seen to be making any sense, and your facts about TypeScript are wrong. Programmers who scoff at IDEs and compilers like you do should be more careful about your own spelling and punctuation and grammar and logic and facts and definitions and semantic arguments.)

The TypeScript compiler will BY DEFINITION compile any JavaScript code to equivalent JavaScript code that does exactly the same thing. So no flexibility is lost, which is obvious if you know TypeScript, or have bothered to read the second sentence of the first paragraph of the TypeScript wikipedia page. TypeScript is a "strict syntactical superset" of JavaScript. So it's impossible for the TypeScript compiler to decrease the flexibility of TypeScript, because all JavaScript is valid TypeScript. Understand?

https://en.wikipedia.org/wiki/TypeScript

>TypeScript is an open-source programming language developed and maintained by Microsoft. It is a strict syntactical superset of JavaScript, and adds optional static typing to the language.

Just the opposite of your claim, and consistent with what Wikipedia and Andrew Hejlsberg say, the TypeScript compiler "ADDS optional static typing to the language", which INCREASES the number of programming paradigms.

Yet you wrote:

>Remember TS is compiled down to JS, so all that flexibility comes from JS.

C++ is compiled down to machine language, but machine language is not object oriented, while C++ is. Do you claim that the flexibility of C++ comes from machine language's innate object oriented-ness, not the C++ compiler? That's simply wrong.

Somehow the C++ compiler is adding object oriented programming to machine language, just as the TypeScript compiler is adding generic programming and structured typing and static typing and other features to JavaScript, even though JavaScript doesn't have those features itself. They came from the compiler, not the target language. JavaScript simply isn't capable of checking types before running a program, and you know that.

You're really not getting the point, or just purposefully trying to avoid it. Read what Andrew Hejlsberg himself said about multi-paradigm languages, which I've quoted to you twice but you haven't acknowledged. Do you really so blatantly disagree with the guy who wrote TypeScript, about his own language?

If you so strongly disagree with Andrew Hejlsberg and the TypeScript manual, then why don't you go edit the Wikipedia articles about TypeScript and JavaScript, and remove the parts about TypeScript being a "strict syntactical superset of JavaScript" that "adds optional static typing to the language", and also remove the part about Javascript being a "multi-paradigm language", and see how long those edits lasts?

https://en.wikipedia.org/wiki/JavaScript

>JavaScript (/ˈdʒɑːvəˌskrɪpt/),[6] often abbreviated as JS, is a programming language that conforms to the ECMAScript specification.[7] JavaScript is high-level, often just-in-time compiled, and multi-paradigm. It has curly-bracket syntax, dynamic typing, prototype-based object-orientation, and first-class functions.

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

#288

Post by maps7 »

rk06 wrote: post #167
maps7 wrote: post #72

Isn't Vue 3 vastly different to Vue 1 and 2? Also why not Svelte?

It is not. The devs initially wanted to make some drastic changes. But Community feedback was very vocal and very negative. Since their main source of income is the community(not FAANG), they reverted their stance

Ah good to know!

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

#289

Post by rk06 »

slantyyz wrote: post #254
rk06 wrote: post #252

Earlier quoted context omitted.

Really, what makes you believe so? IMO, to drive adoption rates, you would need dev evangelists While the RFC states that they are taking cautious route here. They also mention that they are not making an SPA which all the cool kids look up to.

The best type of evangelism is adoption by one of the most heavily used sites in the world.

nope, the best type of evangelism is evangelism. adoption by most heavily used sites jsut proves technical feasibility.

Unless the devs of "most heavily used sites" evangelize, it makes no matter which sites use svelte. As a matter of fact, Vue's adoption increased after Taylor Otlwell (Laravel's creator) and other started _telling_ people that they are planning to use Vue, instead of react.

Wide range adoption followed next.

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

#290

Post by iaml »

BiteCode_dev wrote: post #270
iaml wrote: post #247

Earlier quoted context omitted.

>no Django/RoR equivalent in JS Both angular and ember are pretty close in my opinion.

They are client side, not server side. They have a very, very limited scope. They don't have to deal with the DB, the authentication, the permissions, the deployment, the creation of a REST API, the migration, the mix of several run times, uploads, logging, sending emails, session management, etc. And yet. Their support for i18n, validation, routing, caching, pagination, data formating and presentation - what they sh…

Ah, for some reason I thought you meant clientside alternatives. For backend, there is sails and now nestjs.
Post reply on HN