A Replacement for PHP

I asked Quora for ideas for how a replacement PHP might look.

On the whole people are not enthusiastic. Alexander Tchitchigin had an interesting answer, but which focused on the basic theme of “once we move away from PHP’s weaknesses, we might as well use any language.

Which prompted me to write this comment elaborating what I was interested in. Plus some ideas of my own.

I agree that there are downsides to “embedded in HTML”.

But I think we can also see various what I call “pendulums” in computer science. For example between centralization and decentralization. Centralization gives you economies of scale, eliminates redundancy and makes it easier to see the wood for the trees. Decentralization makes it easier to modularize (or divide and conquer), easier to test and find bugs, easier to scale, easier to improve individual modules etc.

The pendulum oscillates because whenever one of these principles becomes more dominant, everyone starts to feel the pain and see the attraction of the other pole. And then stories start proliferating of the virtues of shifting the other way. Once everyone does, of course, there’s a pull back to the first way again. And so the pendulum continues to swing.

Right now I’m seeing this centralized / decentralized tension in ClojureScript web-frameworks. Comparing using Reagent directly with devcards vs. using Re-frame. Trying to decide whether the convenience of the modularity of keeping state decentralized in individual reagent components and being able to use devcards, outweighs the extra transparency of centralizing state in the re-frame db.

Now I think this thing about “MVC vs. templates with code” is another pendulum rather than an absolute principle.

At the end of the day, HTML is the data-structure for the application’s GUI. And the GUI data-structure does need to be fairly tightly integrated with the code. It doesn’t make sense to try to decouple them too much. You need a button attached to a handler attached to some transformation in your business logic. There’s no point trying to keep these things apart. A button without functionality makes no sense. Nor does functionality that can’t be accessed through the UI.

I’m now using Hiccup to generate HTML. And the place to do it is obviously tightly integrated with the actual functionality of the app in the code itself.

Yes, there are still some MVCish intuitions at work. But I don’t need or want a language to try to hard enforce that separation between UI and functionality either in separate files or with separate languages, when a simple DSL in the main programming language is sufficient.

But when you look at a Reagent (ie. React) component it’s basically a Huccup template with some extra code in it.

Now the brilliance of PHP, the reason it’s so popular is that :

a) it’s just there, pretty much always.

b) it simplifies simple sites considerably by automatically mapping the routing onto the directory structure of the file-system. There are many cases when that is fine. Why should I have to hand code a whole layer of routing inside my code when the file system already provides me with a logical hierarchical layout?

I think there’s still value in the “map files to pages” part of PHP. And that’s what I’d expect a “new PHP” to keep. Along with the “available everywhere” bit.

Of course, how it might look, might be more like Hiccup, a light-weight DSL rather than the verbosity of HTML. With each file implicitly mapped to a React component. Perhaps something like I started describing here : Phil Jones’ answer to What’s the best programming language for applications and GUIs?

In that other answer, I talk about what I found interesting in Eve : the event-handling within the language through “when” clauses and an implicit underlying data-structure.

And I tried to sketch what a language that brought events to Hiccup might look like :

 <pre>
    (defcomponent click-counter
        {:localstate ['counter 0]
         :when (on-click "the-button") #(reset! counter (+ @counter 1))
         :view
          [:div
             [:p "Counter clicked " @counter " times"]
             [:button {:id "the-button"} "Click Me"]
          ]
        }
    )
</pre>

Many frameworks encourage you to put components etc. in different files and directories anyway. Why not make this “official” in the same way that Python makes indentation official. And use the directory structure to infer the program structure?

A powerful modern language with the easy accessibility defaults of PHP would be a powerful combination.

The new WordPress is Calypso?

Source: Are You Affected By WordPress Calypso? | PJ Brunet | LinkedIn

Brunet thinks it’s not going to affect free WP users. Maybe.
What would, I think, be a radical move, would be to recreate the PHP model with node.js.
That is, rather like VB.NET embedded VB and JSP embedded Java in HTML templates, to have a simple persistent node server, loading up Javascript embedded within HTML pages. Purists would gag, of course, at violating the separation of concerns, but this would make it MUCH easier for people to port their PHP applications over to a node world.
Perhaps someone like Zend should be leading this. A next-generation, node-based server, which allowed embedded javascript as an alternative to PHP at the back-end.

WordPress.com and App for Mac

Did WordPress just translate itself to node.js?
Big question, will they also open-source this code-base for users to host on their own sites? If so, this is probably the beginning of the end for PHP? WP is certainly the only PHP application I run. And probably the most widely used PHP program in the wild. (Not counting FB here.)
If they aren’t going to open-source it, is this the beginning of the end for WordPress as the world’s most popular Open Source social-software? Is WordPress.com going to try to turn itself into a more closed, “gated” community? With new features only available to users hosting within it? Is it going to become more like Tumblr … or Medium or even FB?
Update : It’s all open-sourced.

This is an absolutely brilliant summary of the virtues of PHP.

The important point is that these virtues aren’t going away. By comparison this seems to miss the point. In 2020 we won’t be programming the web with an advanced Python framework (wonderful as python is). We’ll have something which does what PHP did for CGI or Processing does Java, ie. wrap a purpose built, sophisticated back-end (something like Google Application Engine) in a light, domain-specific language. That language won’t look like PHP. It would be nice if it looked like Python, but I suspect Javascript is a more likely model.

But it will retain the virtues of PHP : none of this fussy separation of presentation and logic; easy discoverability of where URLs go; fast iterative development; big built-in library etc.

(Hat-tip, BillSeitz for the links)

Loads of nice stuff going on in Squeakland.

Showing Seaside demos to a colleague this week made me wonder whether I need to dive back in. It’s been a long time (15 years) since I wrote any Smalltalk. And what with Python, Erlang, GeekWeaver + some C, PHP, Javascript; and Cache ObjectScript (don’t ask!) in day-job, do I have room for Squeak?

But PyPy Goes Squeak looks fascinating.

As does this conference.