[lolphp111]

Why? The editor needs a frontend in javascript anyways, so why mot handle this all in real time on the client?

Now they rewrote in PHP, thats probably one of the worst languages out there, and why not rewrite in something compiled if speed was the main reason for a rewrite?

For me PHP sits in the middle as a poor language, and still slow compared to any compiled languages. Also i would want to see some wasm vs php benchmarks they did before starting with php.

Lots of poor decisions from the wiki team.

[znpy]

> For me PHP sits in the middle as a poor language, and still slow compared to any compiled languages.

After switching jobs and ending up in a PHP-based company, I can say that such thing is not entirely true.

Poor language?

Not really, it does a lot of stuff and solves a lot of problems.

Still slow?

Kinda true but not really: php 7.x saw a huge improvements and rumors have it that php 8.x will be getting a JIT-compiler.

Also, from my own observation, most of php slowness derives from the fact that the usual approach to deploying a php web application means using php fpm, that starts a whole new php interpreter for each request.

This in turn derives from the fact that php was born to create "dynamic websites" as in websites that were mostly static but with some occasional dynamic page.

IMHO some framework (Laravel? Symfony? some new player?) should try and start a single php process to handle request and persist between a request and the next one.

Starting a new php process is SUPER expensive: there's the whole fork+exe overhead, I/O to load data from disk, parsing and byte-compiling. every single time. even with opcache, you might skip some of the last steps, but you'll have to re-load cache in the next execution.

[Piskvorrr]

Lots of assumptions from you. "PHP bad, PHP slow, everyone has fast client." Did you assume it was 2010?

[lolphp111]

Well, actually i made zero assumptions. Theres tonnes of markdown editors that work in the browser in real time. I assume the wiki syntax is not that much "heavier" to work with, if it is its another lol for the wiki team.

And by PHP i mean if this rewrite is done partly because of speed, why not build the parser in a compiled language? Its just silly that you have to work with PHP as its one of the worst languages out there in terms of dx and features.

I assume its 2020 where clients are "fast enough" to handle a syntax transformation like markdown -> HTML

[Piskvorrr]

"For me PHP sits in the middle as a poor language, and still slow compared to any compiled languages." No assumptions whatsoever.

2020: mobile clients. Yes, they're where the rest of the web was in 2005. Yes, they're ubiquitous.

[lolphp111]

I cant believe users on legacy phones (phones from say 2010-ish era) would be writing new content on wikipedia actively. I dont care if you have the newest iphone, you still dont write anything, you just read. For those 0.00001% of users who actually create new content they most def are not using a phone to do this.

> "For me PHP sits in the middle as a poor language, and still slow compared to any compiled languages." No assumptions whatsoever.

Its not an assumption. PHP is slower than a compiled langauge. simple and easy. Need speed? Dont do it in a compiled language. Period.

[kmaher]

Not exactly accurate regarding mobile editing. Edits on mobile-heavy wikis are up 18% YoY, which we attribute to improvements in the mobile editing interface. We have people who edit on T9 interfaces. Not many, but they exist.

[znpy]

you probably want to do stuff on server side too.

One of the things that come to my mind is rendering in formats other than html.

wikibooks for example lets you render wikimedia pages into pdf, and that's cool. but to do that you have to parse the page server side.