✜pixelthing

here here here

title picture for article
◂ back ipadprowebdev

2019 iPad Webdev - Play.js

Run Node.js natively on iPad - for real!

Play.js is so close to being my holy grail of iOS webdev apps, and if you are a React front-end dev, it might well be yours right now.

It’s not just an editor, it’s a fully integrated environment that lets you run Node.js processes and install Node.js modules. Yes really -- this is the app I have been imagining for several years.

Two windows of play.js, running the index.js in the left window, which spawned the internal browser in the right window with the results. And bottom left is the Node.js console.

But, it has some caveats. It curently has a specific focus on three audiences: Node.js app dev, React Native dev, and React webdev (which is currently marked as in "beta"). There is wiggle room to get some other projects working, but I haven’t had much success trying to get Gulp or Vue.js projects running.

The way Play.js works is a little unconventional if you’re used to working with front-end tooling in the command line, although if you’ve used Pythonista on iOS it might be familiar. If your project has a package.json file and an index.js file in the project root -- you click on the play button, and the dependencies will download, and the script will run in an internal browser.

It’s almost magic.

Here’s the magic in action. Press "play" and the app installs the modules and runs index.js

This is running front-end tooling locally on your iPad without any use of a remote or Virtual Private Server (VPS), and without having to limit yourself to developing a flat file site. For this reason alone (plus if you want to develop server-side node apps), play.js has quite a faithful following.

The default project menu, before you expand it. do you know which is the right React project to run?

In practice #

I have to admit that although I do almost every type of Front-End development, building production ready projects in React remains a blind side for me, so my usage of the app is a little on the surface level. I’ll come back with a new review when it supports VueX ;-)

But it essentially does what it says on the tin. The test React projects that I’ve checked out from GitHub with Working Copy are easily accessed in Play.js with "edit-in-place". If the index.js file is in the root and it has a package.json file, pressing play installs the modules and runs the Node.js tool chain.

The file sidebar. The top directory with ".." goes up a level.

The file sidebar is esoteric by design, and having "back to parent directory" buttons as ellipsis’, it would probably appeal more to Linux junkies than strict iOS HIG followers -- but that’s ok.

Apps that have their own file list style still have their quirks. When you add new files an folders, there is no affordance that they have been successfully added -- no toast, no scrolling the file list to them, no opening them for editing. In one session, I eventually found 27 new empty files I’d created without knowing, that I would have seen if I wasn’t working in a large project that required you to scroll to see files beginning with "N" for "New_file". Small stuff, easily fixed (I hope!).

The editor has come a very long way in a year. Building a code editor is always a case of re-inventing the wheel one spoke at a time, but it has progressed from one where the undo function was actually scrambling code for me, to one which feels like it’s aiming for the best of the best. Symbol auto-suggestion seems solid, as does tabbing and syntax colouring. There’s work to be done -- it’s not my favourite code editor on the iPad (yet) -- but the rate of updates leaves no doubt that more is coming.

The traffic-light close/minimise buttons (echoing window controls in OSX) make me smile, but I wonder about the utility of any buttons you have to click twice -- once to enlarge them, a second time to use them.

The Git controls in the sidebar. Also note the traffic light buttons.

Unusually for almost any iOS code editor (please tell me if I’m wrong), it has great Git support, allowing you commit and push from within the editor. The benefit of which becomes apparent next.

Leaving the app will sometimes have iOS killing it from memory -- mainly due to memory pressure I guess. Which is a shame not just because Play.js has to then reload when you return to it, but often because it can’t auto-load the project you left it with. So you have to navigate to the project and file you were working on. The answer to this is of course to try and stay in the app and not leave it-- and the author has done amazing work with adding consoles, browsers and Git support to reduce the need to leave the app.

The in-app browser (that cleverly opens itself in a new window docked to the side of the code) doesn’t have any special functions apart from having a button to load the same page in an external browser (Safari). I wish we could specify the browser to load the results in -- being able to use Inspect Browser would instead would help a great deal with debugging.

The project/app list (default view).

If I’m honest, the most confusing part for me is the project menu. By default it’s a row of unlabelled icons. You can optionally expand them to be a grid of labelled icons. I thought I was colour and icon orientated, but I still can’t get used to remembering if it was the pink or the red React project I wanted to load.

The last thing to mention is that all the example React projects in the app have the code commented that watching has been disabled due to memory constraints. Having a tool chain that isn’t able to live-reload code when a change occurs is a pain -- but I wonder if this is set because Play.js follows the iOS convention of not having a "save" button, but auto-saving on every key change. Certainly, adding watchers back in crashes the app after some quick code edits. I wonder if this is why GoCoEdit is the only IDE that does live-preview -- because it’s also the only IDE that asks you to physically click "save", so isn’t trying to update all the time you have your hands on the keyboard.

Pros #

Cons #

Optional extras #