Parsoid in PHP, or There and Back Again
phabricator.wikimedia.org
Parsoid in PHP, or There and Back Again
1–10 of 75 posts
Re: Parsoid in PHP, or There and Back Again
#2I'm actually curious why PHP was chosen instead of Rust or Go given that the parsing team wasn't familiar with the language. I understand that MediaWiki is written in PHP, but it sounds like they were already comfortable with language heterogeny.
They claim,
> The two wikitext engines were different in terms of implementation language, fundamental architecture, and modeling of wikitext semantics (how they represented the "meaning" of wikitext). These differences impacted development of new features as well as the conversation around the evolution of wikitext and templating in our projects. While the differences in implementation language and architecture were the most obvious and talked-about issues, this last concern -- platform evolution -- is no less important, and has motivated the careful and deliberate way we have approached integration of the two engines.
Which is I suppose a compelling reason for a rewrite if you're understaffed.
I'd still be interested in writing it in Rust and then writing PHP bindings. There's even a possibility of running a WASM engine in the browser and skipping the roundtrip for evaluation.
Re: Parsoid in PHP, or There and Back Again
#3I'm actually curious why PHP was chosen instead of Rust or Go given that the parsing team wasn't familiar with the language. I understand that MediaWiki is written in PHP, but it sounds like they were already comfortable with language heterogeny. They claim, > The two wikitext engines were different in terms of implementation language, fundamental architecture, and modeling of wikitext semantics (how they represented…
Probably parser is bunch of regex-es that noone understands. So they just converted to code to php without touching the expressions.
Re: Parsoid in PHP, or There and Back Again
#4I'm actually curious why PHP was chosen instead of Rust or Go given that the parsing team wasn't familiar with the language. I understand that MediaWiki is written in PHP, but it sounds like they were already comfortable with language heterogeny. They claim, > The two wikitext engines were different in terms of implementation language, fundamental architecture, and modeling of wikitext semantics (how they represented…
> Parsoid/PHP also brings us one step closer to integrating Parsoid and other MediaWiki wikitext-handling code into a single system, which will be easier to maintain and extend.
I assume that Wikimedia works on a rather tight budget. Choosing (and unifying on) tech stacks with a larger supply in devs seems to be an economically reasonable choice.
Re: Parsoid in PHP, or There and Back Again
#5Reintegrating the parser into Mediawiki's PHP core goes beyond performance. Many prominent MW features -- particularly the visual editor, translation functions, and mobile endpoints -- depend heavily on Parsoid/JS, which required running it as a Node.js microservice, something not all smaller (or especially shared-hosting wikis) could manage for quite some time.
Bringing Parsoid closer to core makes it easier for non-Wikimedia admins to use more of MW's modern core features. The performance gains are a nice bonus, and I suspect are related to the general improvements into PHP 7.2.
Re: Parsoid in PHP, or There and Back Again
#6I'm actually curious why PHP was chosen instead of Rust or Go given that the parsing team wasn't familiar with the language. I understand that MediaWiki is written in PHP, but it sounds like they were already comfortable with language heterogeny. They claim, > The two wikitext engines were different in terms of implementation language, fundamental architecture, and modeling of wikitext semantics (how they represented…
Probably parser is bunch of regex-es that noone understands. So they just converted to code to php without touching the expressions.
My suspicion is correct - code is full of things like: /\[\[([^\[\]])\]\]|\{\{([^\{\}])\}\}|-\{([^\{\}]*)\}-/
Re: Parsoid in PHP, or There and Back Again
#7I'm actually curious why PHP was chosen instead of Rust or Go given that the parsing team wasn't familiar with the language. I understand that MediaWiki is written in PHP, but it sounds like they were already comfortable with language heterogeny. They claim, > The two wikitext engines were different in terms of implementation language, fundamental architecture, and modeling of wikitext semantics (how they represented…
> I'm actually curious why PHP was chosen
From the article: "However, by 2015, as VisualEditor and Parsoid matured and became established, maintaining two parallel wikitext engines in perpetuity was untenable"
They didn't write it in PHP for speed, that was merely a side effect. They wrote it in PHP so they could have a single language for the system.
Re: Parsoid in PHP, or There and Back Again
#8I'm actually curious why PHP was chosen instead of Rust or Go given that the parsing team wasn't familiar with the language. I understand that MediaWiki is written in PHP, but it sounds like they were already comfortable with language heterogeny. They claim, > The two wikitext engines were different in terms of implementation language, fundamental architecture, and modeling of wikitext semantics (how they represented…
[deleted]
Re: Parsoid in PHP, or There and Back Again
#9I'm actually curious why PHP was chosen instead of Rust or Go given that the parsing team wasn't familiar with the language. I understand that MediaWiki is written in PHP, but it sounds like they were already comfortable with language heterogeny. They claim, > The two wikitext engines were different in terms of implementation language, fundamental architecture, and modeling of wikitext semantics (how they represented…
> Parsoid/PHP also brings us one step closer to integrating Parsoid and other MediaWiki wikitext-handling code into a single system, which will be easier to maintain and extend. I assume that Wikimedia works on a rather tight budget. Choosing (and unifying on) tech stacks with a larger supply in devs seems to be an economically reasonable choice.
Wikimedia is swimming in donations. More than $100,000,000 yearly since 2017/2018.
Re: Parsoid in PHP, or There and Back Again
#10Almighty Zeus, please smite PHP and all code written in it from all the records of humanity. This language is too disgusting and wrong to be used by anyone, ever.