Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WordPress Playground: A WordPress that runs entirely in the browser

developer.wordpress.org

Post reply on HN
Print view View original

81–90 of 221 posts

Re: WordPress Playground: A WordPress that runs entirely in the browser

#81

Post by danielbachhuber »

geocrasher wrote: post #65

I'm curious as to how useful this will be. Tying it to SQLite makes it portable, but abstracting it so that it can be used with any db would be far more powerful. Why? Because the SQLite implementation is enough to get it working in the browser, but it does not make WordPress 100% SQLite compatible. For example, a WordPress site built on MySQL can't be migrated into an SQLite powered WordPress using a common migratio…

> For example, a WordPress site built on MySQL can't be migrated into an SQLite powered WordPress using a common migration plugin. I know, because I tried.

Out of curiosity, how recently did you try?

We're using a new SQLite integration that seems to be pretty good at translating SQL to SQLite: https://github.com/WordPress/sqlite-database-integration

We'd be curious to learn more about how it failed. It's definitely an area we'd like to improve.

Re: WordPress Playground: A WordPress that runs entirely in the browser

#82

Post by SahAssar »

coliveira wrote: post #57
toddmorey wrote: post #14

"Whether you want to build a note-taking application for mobile devices, an automated testing environment, or demo a live WooCommerce store on your site – Playground will support you." The last two make a ton of sense, but the idea of building a mobile app that's powered by Wordpress running PHP in webassembly in the browser is wrecking my brain.

It makes complete sense. Php web stack is very light compared to Python/node, so it makes sense it can be embedded in the browser.

Except this is already running on a js environment in the browser (usually v8 if you use chrome, edge or any of their derivatives, the engine behind node). So you are running something to not run the thing you are already running.

Re: WordPress Playground: A WordPress that runs entirely in the browser

#83

Post by infp_arborist »

whyage wrote: post #6
fredley wrote: post #3

WordPress was where I got my start, a while ago now. From poking around with PHP files, to building my own things, to Django, and on. It would have been inconceivable back then (mid noughties) that the whole thing could be done client side. The Web has come on a long way. These days I tend to hate WordPress with a passion. Occasionally I will be asked to peek at some technical problem with a WordPress installation an…

What no-code alternative would you recommend for pro web designers?

Wordpress + Oxygen/Bricks/...?

Re: WordPress Playground: A WordPress that runs entirely in the browser

#84

Post by Saris »

wg0 wrote: post #60

Reporting from a budget Android Tablet with Firefox, the response times aren't exactly instantaneous but aren't any different than running full LAMP on a reasonable cloud instance or VPS which is surprising to say the least. Also imagine the software layers at play here. Whole PHP Interpreter plus whole thousands of lines from WordPress codebase plus SQLite. Amazing when that's all so much totally useable.

I've always found WordPress performance doesn't change much on lower vs higher end hardware. It seems to be limited by itself.

Re: WordPress Playground: A WordPress that runs entirely in the browser

#85

Post by geocrasher »

danielbachhuber wrote: post #81
geocrasher wrote: post #65

I'm curious as to how useful this will be. Tying it to SQLite makes it portable, but abstracting it so that it can be used with any db would be far more powerful. Why? Because the SQLite implementation is enough to get it working in the browser, but it does not make WordPress 100% SQLite compatible. For example, a WordPress site built on MySQL can't be migrated into an SQLite powered WordPress using a common migratio…

> For example, a WordPress site built on MySQL can't be migrated into an SQLite powered WordPress using a common migration plugin. I know, because I tried. Out of curiosity, how recently did you try? We're using a new SQLite integration that seems to be pretty good at translating SQL to SQLite: https://github.com/WordPress/sqlite-database-integration We'd be curious to learn more about how it failed. It's definitely…

Ok, didn't expect that response! I tried this today.

I admit I didn't try super hard- I have a lot of other things to work on, was a 20 minute curiosity mission. I just downloaded the zip file and grabbed the files out of that. Don't get me wrong- it worked- but I couldn't do an import as mentioned.

If you want lots of detail, I can spend more time on it. Email me at my hn user at the google mail.

Re: WordPress Playground: A WordPress that runs entirely in the browser

#87

Post by radium3d »

calibas wrote: post #21
hbcondo714 wrote: post #8

Very modern how they got this to work: PHP runs as a WebAssembly binary MySQL is replaced for SQLite via a WordPress plugin Web server is implemented in JavaScript as a Service Worker

Neat, and here's more info on how they did it: WebAssembly PHP: https://wordpress.github.io/wordpress-playground/architectur... Service Workers: https://wordpress.github.io/wordpress-playground/architectur...

Interesting, seems the dedicated worker in chrome task manager is utilizing 1,135,948k of memory

Re: WordPress Playground: A WordPress that runs entirely in the browser

#88

Post by DaiPlusPlus »

radium3d wrote: post #87
calibas wrote: post #21

Earlier quoted context omitted.

Neat, and here's more info on how they did it: WebAssembly PHP: https://wordpress.github.io/wordpress-playground/architectur... Service Workers: https://wordpress.github.io/wordpress-playground/architectur...

Interesting, seems the dedicated worker in chrome task manager is utilizing 1,135,948k of memory

> 1,135,948k of memory

That's 1.1GB.

That's horrifying because, theoretically, it should be a tiny, tiny fraction of that: on bare-metal we can run PHP + MySQL (let alone SQLite) + Apache within a few dozen MB of RAM.

(Historical personal anecdote: my first-ever dev-server machine I built before high-school ran Windows Server 2003, IIS, SQL Server, and Adobe Photoshop 7.0 (in a Terminal Services session) concurrently just fine well-within 256MB with little-to-no paging)

Let's be generous and assume that 64MB should be a reasonable upper-bound (though I think that getting it under 16MB should be possible), in which case what exactly is the other 1.09GB of RAM being used for?

Re: WordPress Playground: A WordPress that runs entirely in the browser

#89

Post by WorldMaker »

coliveira wrote: post #57
toddmorey wrote: post #14

"Whether you want to build a note-taking application for mobile devices, an automated testing environment, or demo a live WooCommerce store on your site – Playground will support you." The last two make a ton of sense, but the idea of building a mobile app that's powered by Wordpress running PHP in webassembly in the browser is wrecking my brain.

It makes complete sense. Php web stack is very light compared to Python/node, so it makes sense it can be embedded in the browser.

There are plenty of Python apps now running in WebAssembly too. A lot of Node's stack directly runs in browsers (browserify is "ancient" tech at this point and influenced so much of modern "bundling" including Webpack and many things post-Webpack). (Deno's doing its own work with browser-compatible Node APIs, too.)

Re: WordPress Playground: A WordPress that runs entirely in the browser

#90

Post by kodah »

lolinder wrote: post #78
kodah wrote: post #51

Earlier quoted context omitted.

> Most of the gatekeeping of what is and isn't "coding" is done by novices who don't really know what they're talking about. Beginners tend to want a hard line with "coding" on one side and "not coding" on the other, but that's not a very useful way to model interactions with computers. I disagree. There's a meaningful distinction between what is code and what is formatting because the concerns are quite different. T…

I agree that the distinction you're drawing is valuable, but it's not a distinction between "code" and "not code": both aspects are defined with a language that the computer parses, interprets, and executes on. One happens to be a declarative language that deals with the what and why , and the other an imperative one that deals with the how . > Trying to shoehorn peoples attitudes into discriminatory experience level…

> both aspects are defined with a language that the computer parses, interprets, and executes on.

Sure, but low order definitions of "code" being something that takes an input and produces a different output do not relate to the real world unless you believe modern word processors require programmers.

> Referring to someone as a beginner is not discriminatory, we all start as beginners and it's okay to not know things.

I think you're missing the point that the statement you made applies to a wide variety of discussion, not simply binary code|not_code discussions.

> Most of the gatekeeping of what is and isn't "coding" is done by novices who don't really know what they're talking about

This statement would also imply anyone trying to sort out coding from formatting, from styling as a novice. There's a reason we separate these activities in programming that has to do with how you model applications not to mention empowering the people who have expertise in doing them.

While I agree that code|not_code is not helpful, trying to make the definition of code so low order that it's meaningless is also not helpful. There's a bar there that belongs in the middle and I think you both have missed it. I was merely calling out equally harmful wording that you were using to correct harmful wording.

Post reply on HN