At least the content is freely available, so I can stand-up my HTML-only Wikipedia clone if they render the official version unusable with this reactive JS madness.
Turns out HTML over HTTP is GREAT way to deliver encyclopedic content.
RFC: Adopt a modern JavaScript framework for use with MediaWiki
141–150 of 293 posts
Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki
#142Earlier 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…
If you use Svelte with Sapper, you will get the "best of both worlds".
The first page you hit has the content baked into the HTML, and all subsequent content "pages" load like a single page app.
Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki
#143Earlier quoted context omitted.
It is standard HTML in the sense that it's valid HTML, which React JSX isn't, of course. But without the JS runtime it won't do anything, so in the end what's the advantage over React? You can add interactivity without going full SPA with React too after all
It's a subtle but huge difference. In React, using JSX means you can create components and mount them on top of the existing elements on the page. With Vue's HTML templates, the page itself can be the component and everything can become interactive. For example, you can easily output a HTML table from server-side code, then Vue can convert that into a interactive component while using the existing structure and data.…
I think you're talking about universal or isomorphic rendering, but each of these allow for it.
Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki
#144I'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…
Page Previews is a great example of leveraging "web app" that solves many problems at once: - quickly inform on a topic without clicking through (lower latency) - increase scanability (hence readability) - decrease expensive whole page loads - eliminate need to open many tabs https://www.mediawiki.org/wiki/Page_Previews
Whatever, but if wikipedia somehow becomes unusable without javascript, it will be a real tragedy.
Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki
#145What 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…
A lot of the questions you're rhetorically asking are answered in the RFC you're commenting on. Specifically, they had real problems with their current system, which they documented here: https://phabricator.wikimedia.org/T225453 . Then they explored the available options in the ecosystem and came up with the one they thought would best fit their needs. If you're gonna be critical, at least take the time to understan…
HN will never pass up an opportunity to shit on JS or especially web frameworks, without fail. It’s actually sort of entertaining.
Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki
#146I'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…
Page Previews is a great example of leveraging "web app" that solves many problems at once: - quickly inform on a topic without clicking through (lower latency) - increase scanability (hence readability) - decrease expensive whole page loads - eliminate need to open many tabs https://www.mediawiki.org/wiki/Page_Previews
[deleted]
Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki
#147This thread reads to me like the engineers went into it already knowing they wanted Vue.js, and retroactively doing the necessary mental gymnastics to come up with a rationale. A better justification would have started with "these are our pain points, and this is our evaluation of how these options address our problems." Instead, it's full of weird things like this: >Better support for usage without Webpack/Babel/fro…
They expect to have server side rendering, so end user will get just HTML (except the parts that require js even today), so older browsers should still work
Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki
#148Earlier quoted context omitted.
I’m spinning up a few new projects at the moment, and was sooo close to doing them in ClojureScript. I ended up going with JavaScript, Preact, and Rollup just because of familiarity allowing me to move faster. That, and my build times are sub-second, something that was not true of my previous Webpack and typescript projects. My total application bundle size is still smaller than React alone. ClojureScript is really g…
> How are your production bundle sizes? Application I'm working on is not that complex, 20 something different pages with multiple sub-sections themselves, bundle ends up being 1.5MB or something like that, 300kb gzipped. Main weight comes from using multimethods which pulls in a lot of cljs.core, so not using that would make it a lot smaller. Also gonna start splitting the bundle per page but haven't yet. > Are you…
IntelliJ with Cursive is a very good Clojure IDE.
Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki
#149Earlier 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. Who are these mythical people? Do they just magically decipher what interface an argument conforms to? What methods are accessible on a returned result from any random library they're using?
N=1, but type errors are extremely rare for me in Javascript. I don't think I'm a magical or exceptional programmer. I think it's just if you spend a lot of time in dynamic languages, there's a certain style of programming some people end up adopting that makes those errors much less common.
If you held a gun to my head and forced me to recklessly provide conjecture on what the difference is, I would say that static languages encourage devs to build large interfaces that take tons of options and pass around a bunch of parameters. This is highly, highly subjective, but:
I think there's a grain of truth in what other people are saying about how Typescript projects tend to be kind of verbose. People start reaching for interfaces that are split across multiple files, people start reaching for classes. When you have really rigid types that need to be formally extended all over the place, this also encourages a lot of casting, which tends to be error prone.
I've seen some really complicated logic/type flows in Typescript that would be extremely error prone in Javascript, but there's basically no reason for them to be that complicated in the first place. There are paradigms in Javascript the codebases are not taking advantage of which are forcing them into these over-complicated logic/data flows. Basically, the more crazy boilerplate, casting, and giant interfaces that a codebase has, the more type errors will occur. The more a project is split up into dozens of dependencies and modules and whatever, the harder it is to reason about what a method or class needs passed in. But Typescript projects tend to grow in that direction very quickly, so the need for Typescript tends to become a self-fulfilling prophecy.
As a comparison, most of the personal projects I work on don't have classes at all, they're using a lot of functional interfaces, and they don't include a bunch of random libraries. Most of the dependencies in my projects are libraries that I've personally vetted. Most of my projects are careful about where state is being stored and how its being passed around.
I dunno. All of that is pure conjecture, but people in general are very dismissive of dynamic typing, but it's just not a real problem for me. There's a general consensus that dynamic languages were a mistake, and I don't dismiss the people saying this, but I also pay a lot of attention to where bugs are coming from in my own code, and I can't get past the point that typing really doesn't seem to matter that much in most things I build.
I was on the Typescript train for a while. I still use it in some projects, there are some org structures where it makes a lot of sense. If I'm working with a Java-to-Javascript dev, I want strong interfaces for them. The projects where I don't use it are because I've spent a long time paying attention to where my bugs are coming from. I can't prove to you its not a problem, I can only speak to the experiences I've had.
Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki
#150This thread reads to me like the engineers went into it already knowing they wanted Vue.js, and retroactively doing the necessary mental gymnastics to come up with a rationale. A better justification would have started with "these are our pain points, and this is our evaluation of how these options address our problems." Instead, it's full of weird things like this: >Better support for usage without Webpack/Babel/fro…
They expect to have server side rendering, so end user will get just HTML (except the parts that require js even today), so older browsers should still work
Server-side rendering isn't a panacea. I would be surprised if they were using it to do more than bootstrap an interactive frontend web component, which would then inherit all of the problems I'm referring to. That's how everyone else does server-side rendering, at least.