lucperkins

That's a good point. I hadn't seen things quite this way. But you're absolutely right about complexity being a potential problem. For basic CRUD apps, it seems to me like traditional MVC is absolutely the way to go, hence my bristling at the "MVC is dead" claim, which is really just overblown rhetoric. I can see where move would have its place in "thick" client-side architectures, where you have all kinds of events that are supposed to trigger all kinds of functionality in your view. But I'm not convinced that we need to call that another "framework." MOVE strikes me as little more than a potentially useful abstraction.

No. Sometimes I spend a lot of time and effort seeking out niche genres and digging through blogs and news sites to find "good" music. But sometimes I don't want to put in all that effort, and then putting on "Kind of Blue" or the first Weezer album is "good enough." There is room for both approaches to music listening.

But how often does trying-to-be-better-and-failing come along and torpedo good-enough-for-the-job?

Culinary powerhouse? No. But it is undeniably a powerhouse in delivering food consistently and reliably.

This is true now, but Dart is also less than a year old. I don't have strong feelings toward Dart either way, but these things have a gestation period. Internet Explorer didn't support JavaScript at first either, and Safari and Chrome didn't exist in 1995. So it really remains to be seen.

Agreed on what you said about writing scalable, secure web apps. No question about it.

But I should say as an aside (and you wouldn't necessarily disagree, I don't think) that these kinds of problems are not exclusive to PHP. JavaScript gets you exactly the same result. And try doing something as simple as 0.2 + 0.1 in JavaScript. Oy vey...

I use words like "might" very intentionally! And yes, right you are that my conclusions about things might change radically. I'm already appalled at some of the things that I thought even weeks ago...

Then double freaking high five :)

I think that Sinatra will become increasingly popular within the Ruby community (and financial help from Heroku/Salesforce can't hurt!), but I also think it's interesting that the micro-frameworks inspired by Sinatra (Flask for Python, Express for Node, plus many others), will become the fall-back for more advanced developers because they do a lot less specification and leave a lot more space to the developer.

So I say don't give up on Ruby. And if you insist on Rails-style MVC, there's always Padrino for Sinatra, Tower for Node, etc.

So much going on, so little time...

Absolutely agreed. I really love JavaScript for a lot of reasons, but it still astonishes me that that our lingua franca was designed in 10 days. In 1995. For NETSCAPE.

I'm not so sure I would describe the mishmash as unambiguously depressing. It's also pretty inspiring seeing people using the mishmash in a sort of bricolage kind of way. One thinks of libraries like Underscore and Backbone that seek to account for some of the "deficiencies" in JS.

And don't even get me started on CoffeeScript.

But I think we would both agree that it's strange that no one has come along attempting to really REALLY break the mold by designing a new browser from the ground up that wasn't tied to JavaScript and the DOM (and maybe not even HTML!).

You go first :)

1. I wouldn't want to do anything at a meaningful level of complexity without templates. No question about it. And I think that having so many templating frameworks is wonderful (ERB, Jade, haml, etc.). I was only arguing that PHP lets you dive in without NECESSARILY needing to jump through a templating hoop.

2. Is it unthinkable that a person could start learning web dev and pick up the command line along the way? I started out learning PHP/MySQL on my old Windows machine, terrified of the CLI, and now I do almost everything on it (and have converted my old PC to Linux). If the command line were a barrier at all points in the learning trajectory, then you might have a point. But I also don't think that command line mastery should be held up as a sine qua non of learning web dev.

I agree, but just out of curiosity: what do you think would be the language of choice beyond JS for the browsers of the future?

I honestly don't have a clue. I might guess Python because it's so big at Google and Chrome is already more or less the industry standard.

Right right right. I would add this: Ruby could well be considered "passé" someday (history tells us it necessarily will be), and the Rubyists of the future would really bristle at the suggestion that what they're doing is worth less simply because the market says it is.

Exactly. Correspondingly, my hope (along with one of the folks below) is that advances in hardware will obliterate any speed difference and enable the back end to be king.

Time will tell.

You could be right about these numbers becoming meaningless. But in the meantime, there is a noticeable difference, and that can mean life or death in the jam-packed web dev market that we see today. If cramming as much application logic as possible into the front side continues to shave off milliseconds or even seconds in some cases, then I think that trend will continue.

That said, I hope you're right. A world in which front vs. back end didn't matter with respect to time would be one in which developers were free to reveal far less on the client side, and that would be a victory indeed!

Nice to see PHP get some love from polyglots!

No, "absolutely everywhere" is not an argument by itself. But sometimes ubiquity is earned.

If Facebook powered its front end using FORTRAN, I would call it a quiet powerhouse, too!

I certainly didn't mean to say that languages like Python and Ruby are inflexible!

What I meant to say is that you can't use either of them in direct conjunction with HTML the way that you can use PHP. This was what I meant when I said "genuine functionality from scratch." Would I prefer Python+Django/Flask for lots of use cases. Absolutely.

As for the "useless overhead," there are things like the command line (which Python and Ruby web dev absolutely demand) standing in the way of some of the other languages. Personally, I strongly prefer the command line for almost everything, but for beginners this is another barrier.

My argument was not for the superiority of PHP over other languages, but rather against its casual dismissal from consideration.

Well said. RESTfulness will ALWAYS have its place, and blogs are the example par excellence. Even in Node, which prides itself on its async/non-blocking capabilities, there are all kinds of ways to incorporate REST.

And now I'm doing some research and finding Catalyst and others. Looks like there's more going on in Perl web dev than I realized. Foot.in.mouth.

That said, I am indeed among the people keeping my fingers crossed for a Perl renaissance in web development.

Maybe. I actually like Perl a lot, and there are lots of things you can do with it that you'd never want to use PHP for. The difference is that in the world of web development (and this is the crucial distinction here), Perl has neither the use cases nor the easy uptake nor the development frameworks (Drupal, Joomla, Zend, CodeIgniter, etc.) that PHP has. And so my comment wasn't against Perl tout court.

I'm not convinced that it will fade, especially given the rise of mobile devices (as the gentlemen has already pointed out) and what I expect will be a marked improvement in browsers in the coming years (Google Chrome/V8 is a good example). The rise of JS libraries that enable you to use models and persistence in the front end make a lot of people really question why going to the server side and asking for a view is always necessary. Still necessary sometimes, absolutely. But better to go to the server side only when necessary.

"Scalable, reliable and robust." Couldn't have said it better myself. Thanks.

I think you're right about a lot of things. Things like Backbone (which I wrote about at http://blog.appfog.com/putting-some-mvc-meat-into-your-app-b...) will make recourse to the back end more and more selective as time goes by. JavaScript is indeed quite a force, and as far as I can tell that will stop only when browsers start reading other languages directly (which is not completely unthinkable, but also not really on the horizon).

My point was not directed so much against JavaScript as against the notion that PHP is simply an anachronism.

There's also nothing stopping you from using lots and lots of front-end JavaScript in a PHP-driven context...

It depends on how you define powerhouse. Is PHP my favorite language or framework? No. But the use cases I provide show that it's worthy of consideration.

Perl, on the other hand...

1. The gentleman's comment was indeed quite curious, and I wish that I could have used this info as a comeback. Thanks! 2. Direct HTML embedding could be seen as a weakness, yes, but that all depends on the kind of project. That's why I describe it as a good language for beginners and don't make any claims for or against it beyond that (beyond its demonstrated scalability, which I can only imagine being quite difficult in light of the security and other concerns that you voice).

You're quite right that the analogy isn't perfect. The point I was trying to make, though, is precisely that PHP development can proceed without any recourse whatsoever to a framework. Jumping straight into web dev without an accompanying framework like Rails or Sinatra is a complete non-starter if you're a Rubyist.

So you're quite right, but I hope you would agree that the Rails/PHP comparison, in spite of its imperfections, is compatible with the point I was trying to make.

A good example for you might be the "jQuery: Novice to Ninja" book. It cuts out a lot of the BS that makes other books annoying and cuts straight to the chase of DOING. Think of a group of sample projects, or maybe even think of a single project to build and build upon over the course of the book.

I agree, although I would argue for making JavaScript your primary language for web development, especially in light of (a) the possibility that has emerged in the past few years of running JavaScript on the front and back end (I'm referring of course to Node.js), and (b) the movement toward doing and more and more on the front end with far more selective recourse to the back end (here I'm referring to libraries like Backbone, Ember, etc.). PHP and Python are both very cool and have amazing communities, but get as comfortable as possible with JS first.