Taking PHP Seriously

Could not agree with your statement enough, just like Django really is a heavy burden for python when you could use flask etc... for most things.

for the specific case of templating: you wouldn't want to parse mustache in production, and use a pre-compiled template.

What I think most people are missing about PHP is the incredible ecosystem that emerged in the recent years (especially with Laravel) that helped to speed up the development of web apps by A LOT and removed all the annoying boilerplate.

I know that nowadays there are a lot of fancier languages to write your next project, but I challenge anyone to find anyone that has a similar ecosystem that can do all the following things with just a matter of editing config files basically.

- Create a fully working app with authentication, database migrations, security checks, middlewares, route management, and much more with just one command line ("laravel new project_name") (Laravel)

- Logging in a user with an external service with one line of code. (Laravel Socialite)

- Sending real time notification with any type of channel. (email, socketio, sms, ios/android, ...) (Laravel Echo)

- Create a complete Oauth2 server with all the backend and frontend parts with just one configuration file. (Laravel Passport)

- Make text search with Elasticsearch using external services as easy as making a normal query to the local DB. (Laravel Scout)

- Super easy tu use payment system integration that handles both one time payments and subscriptions with Stipe and Braintree. (Laravel Cashier)

- Optimized and lightweight version of the full framework to get blazing fast APIs. (Laravel Lumen)

- Local web server that automatically creates .dev domains for each project and that works with most PHP projects (not just Laravel) (Laravel Valet)

- Vagrant box with everything you need for a local development web server. (Laravel Homestead)

- Easy frontend assets management (compiling, versioning, ...) built on top of Gulp and Webpack. (Laravel Elixir)

- Provision a web server with all the things you need (security, git push-to-deploy, ssl certificates, queue workers, ...) properly set up with one simple click. (Laravel Forge^)

- Zero downtime deployment with history backup and much more. (Laravel Envoyer^)

- Fully working SaaS app that handles all the boring stuff (subscriptions, invoicing, team management, emails, ...) and let you concentrate on the actually product you want to built. (Laravel Spark^)

- Tons of video tutorials/screencasts/lessons on how to use every aspect of Laravel and much more (PHP, Vuejs, Text editors, ...) (Laracasts)

As you can see from the list, almost everything is related to the incredibly good framework Laravel, that I highly recommend to anyone that is working or will work with PHP.

I especially recommend to all those people that are about to create their next SaaS project to take a look at Laravel Spark. It really puts all the pieces of the puzzle together and it makes your MVP really around the corner instead of months away.

Coming from old-school PHP where I hacked everything together, after learning and switching to Laravel my life as a developer completely changed and now I can't imagine that I'm still using the same language actually. They feel like two completely different things and in my opinion all those people that are talking bad about PHP, they are stuck with old memories of how PHP used to be. Yes, PHP as a language still has a lot of things that needs improving, but PHP as ecosystem of libraries and frameworks is definitely still the king of the web!

The King is dead, long live the King! :)

[^]: These are commercial products but their price is definitely accessible (99$ for Spark and 10$/month for Forge and Envoyer)

It sounds like you're trying to write Javascript as if it were Java. I've worked with developers who did this (e.g. http://chriswarbo.net/blog/2014-03-12-trolled.html ) and I would advise that you instead try to write more idiomatic Javascript, or else use some kind of Java-to-Javascript compiler.

Your critique of Javascript is basically "it's not Java". I could make a similar critique of Java not being StandardML, but it would be about as meaningless:

When we have distinct structures, signatures and functors we can easily understand how they are supposed to be used: you can open a structure, create an implementation of a signature, apply a functor to a structure.

> (And by the way why do you write 'var Person = function' instead of just 'function Person'? The latter is shorter and more readable)

Personally, I prefer "var Person = function Person(...) {...}" since it makes the code more symmetric (the second "Person" makes stack traces more informative). The "function Person(...) {...}" style makes an artificial dinstinction between functions and everything else.

> All these tricks with prototypes and dynamic objects (where you can add or patch properties in objects in runtime) might look good in short samples of code but they are only the source of bugs and cause waste of time to understand what the author meant in real world applications.

Javascript is a dynamic language; there is no ahead-of-time compilation. Things can only be done at runtime, including adding properties to objects. If you mean that mutating values should be avoided, then I would emphatically agree. That's certainly not a Javascript-specific issue though, and Java is just as riddled with mutability as anything else.

I haven't had enough experience with prototypical inheritance to comment on it vs class-based inheritance; I've been burned enough by class-based inheritance that I tend to avoid inheritance in all forms (and OO too, these days).

"fork" is not a major problem in PHP. In Drupal, every single request compiles a file "common.inc", of several thousands of lines of PHP code. That is what slows it down. It's remarkable that PHP still manages to do that in just 100ms.

In Zend Framework it's slightly better because it includes an autoload option, which implies only PHP files that are actually used by athe request, get loaded. That way the overhead is "only" 50ms.