Zend Framework 3 Released | Hacker News Reader

Zend Framework 3 Released

framework.zend.com

93 pointsagopaul91 comments

Interesting. It doesn't amaze me the continued popularity of PHP. The language, framework, and ecosystem just work. Plenty of people well versed in it. It's not sexy, and I've done more than a few years of consultancy there.

New energy in an ecosystem is never a bad thing.

What doesn't "just work" to the same standard? What, among the things anyone uses, are you saying that PHP works better than?

PHP doesn't have the library fragmentation of nodejs or the deployment friction of compiled languages like C# and Java. So when someone says "its just works" they mean they can clone a repo onto a server and see results immediately, without the intermediate steps that other languages and frameworks impose on you.

When I started out making web software 20 years ago the choices for server-side code were essentially C, Perl, or ASP with VBScript. Then PHP came along and made things a great deal easier because managing a server was hard, and PHP just worked pretty much everywhere. In that sense PHP was amazing.

We aren't working in that environment any more. What software runs on a server is no longer up to the hosting company. A developer/devop can configure a server far more easily, with no input from a sysadmin. The process can be completely automated. That change has opened up development options considerably. That doesn't mean writing code in PHP is a bad choice, but it does mean there is a choice. PHP's primary advantage has been eroded to the point where it should no longer impact the decision making process when you're figuring out what to use. Everything else has caught up.

As a Django dev, I don't think its anywhere as easy to deploy Django as PHP.

I would rather work with Pythons virtualenv and pip for dependency management, than I would PHPs Composer.

In terms of initial setup of an application than doesn't use anything but the standard library in either language I would completely agree with you.

Edit: Composer, not Artisan as dependency manager in PHP.

Having worked with both I can say that composer feels way more modern than pip.

As in Laravel Artisan? That's not a dependency manager.

Granted, Composer is slow, but it works so well, mainly when package developers tag and release packages properly though. What issues do you have with it?

If you have XDebug enabled it will slow Composer, but also several patches near the official 1.0 release improved speed massively. If you haven't tried it recently, you should try Composer again.

Except some performance issues composer is GREAT though.

I install prestissimo[1] everywhere now. It improves speed so much.

"composer parallel install plugin" is what it calls itself - it downloads all the repositories before composer gets to the install step and then composer just loads everything from cache - super fast!

[1]: https://github.com/hirak/prestissimo

Wow, didn't know about that, thank you.

Hit CTRL+C in the middle of composer install, and you will probably get an inconsistent state. Following composer commands will throw exceptions and exit. This is not a problem when it's pip.

It's literally six or seven lines in an Ansible playbook

Learning Ansible is not easier than dragging and dropping a file onto a server and having it run with no extra work.

They weren't saying it was hard but that it is not as easy as PHP. PHP is one level up from a static site for most beginners, you can simply drag and drop a file on many shared web hosts and get going. That is the attraction.

That's was the attraction. I guess it still is for very simple web apps that one person can build. It's been a while since I've worked on anything like that. It's probably been a few years since I've even signed up for any service like that. The web has moved on to building more scalable things.

If you're writing something moderately complex then you're very likely to be running it on a virtual instance (maybe more than one) on AWS/Digital Ocean/etc, and if that's the case then you'll go much faster if you have a testable, reproducible build process that your development team can tear down and build back up easily. That is much more complicated than FTP'ing a few scripts to a server and importing a SQL script with PHPMyAdmin, but at the same time, as soon as your service hits a few thousand users with hundreds of them accessing it concurrently, your PHP script FTP'd to a shared server probably isn't going to work very well.

Learning new things is not a reason to avoid moving forwards. If anything, it's why I got in to web dev in the first place. New things are what make it interesting. I don't learn all of them, and I don't switch tools very often, but sometimes something comes along that makes life better. Reproducible builds with Ansible/Puppet/Chef/etc is one of those things.

>That's was the attraction. I guess it still is for very simple web apps that one person can build.

It's better to insist on simplicity at every level, whether you're building "simple one-person web apps" or "complex large-team" ones. In fact simplicity at every level would be even more beneficial in the latter case.

So I find this "dead easy deploy is only beneficial for small apps" dichotomy false.

It's a great deal simpler to have a process that runs when code is merged in to a repo than to have a manual process of copying files to a server that relies on a human getting things right. "Dead easy to deploy" these days means "create a process that can run automatically, that checks things worked correctly, and rolls back changes if things go wrong". Doing those things manually is not simple.

If a deploy fails and a client is panicking because their app isn't available, the last thing you want is a team of stressed developers trying to work out which files they need to revert.

"Simple" doesn't mean "easy".

>It's a great deal simpler to have a process that runs when code is merged in to a repo than to have a manual process of copying files to a server that relies on a human getting things right.

Who said it's has to be either one or the other?

The "manual process of copying files to a server" can be done simply by a person for a small scale project, and it also can be automated any way one likes -- e.g. to "automatic copy files to a server when code is merged in to a repo".

"Copy a file to a directory and the server just works and shows it" doesn't imply manual ftp uploading or manual editing of any kind -- it's just so flexible and easy that can it work that way too.

And if anything breaks, it's still simpler to find out what went wrong -- as opposed to some convoluted server deployment process with more moving parts.

Have you ever configured a secure setup for php+httpd? Because it is much easier to deploy a secure userspace python app outside of context of webserver and just proxy to it.

Just run php cgi/fpm as another user? What am I missing?

Open basedir config, separate /tmp, insecure function blacklisting... tons of stuff, php-fpm is the starting point - yes.

It takes much more manual work to set everything correctly than running a python application.

> We aren't working in that environment any more.

"We" are a minority.

The vast majority of websites out there are still hosted on shared servers over which the customer has very little control other than installing and updating WordPress. You might be able to convince cPanel to let you run a Rails app, but the system as a whole was designed with PHP in mind.

The owners of those websites have absolutely zero interest in messing with the server environment. They're not developers. They've probably never heard of devops. They're totally allergic to SSH and can barely even use FTP. And yet, these are the people who, whether knowingly or not, help keep the web as decentralized as it is. PHP was the only language that catered to them 15 years ago, and it still is the only language that makes this possible on a large scale.

I host my blog with NearlyFreeSpeech.net. The whole site is just a couple of PHP scripts. I haven't updated it in almost a year, but it keeps working, no maintenance required. If I had to host it on DigitalOcean like all the cool kids do, it would cost me 10x more in monthly fees (even with the smallest droplet) and 100x more in time. This kind of setup is what I call "It just works." Not dockerfiles and bootstrapping commands and all sorts of dependency management tools.

>10x more in monthly fees

The smallest droplet is 5 dollars a month, do you pay 50 cents a month for your shared hosting?

>100x more in time

Have you even looked into DO or are you just making assumptions? You can create a ton of apps with one click (One-click apps) and install a full stack with WordPress, Drupal, Django, and much, much more, and it just works. If anything, it's the same amount of effort as some cPanel shared hosting.

> The smallest droplet is 5 dollars a month, do you pay 50 cents a month for your shared hosting?

Yes.

> Have you even looked into DO or are you just making assumptions? You can create a ton of apps with one click (One-click apps) and install a full stack with WordPress, Drupal, Django, and much, much more, and it just works.

My company manages servers for non-technical people whose small business or hobby websites have outgrown shared hosting. I often get clients who found out a little too late that running a Linux machine securely and efficiently is much more complicated than deploying a one-click app on DigitalOcean (or a similar service). I sweep in, optimize the hell out of everything, and occasionally patch some gaping security holes. So no, it doesn't "just work". At least not in the long term.

> Then PHP came along and made things a great deal easier because managing a server was hard, and PHP just worked pretty much everywhere. In that sense PHP was amazing.

This. My first web programming was in Perl [1], and using PHP was much simpler to get into. You just uploaded it and it worked.

I think the biggest problem with PHP was it was a hammer and everything looked like a nail. That created a lot of spaghetti code.

[1] I still have a soft spot in my heart for Perl. I don't think it was an issue of "PHP is better than Perl", just that PHP was easier/faster.

There are features of Perl I miss even now. tie for example. ES6's proxies can do something very similar, and that makes me happy.

I would mostly agree, but given my latest attempt at getting PHP based media server (Spotify clones) working, I wouldn't say that "it just works". Even with the documentation fairly good for all three solutions I tried, I managed to get non of them working.

Wordpress is an example of a PHP application that just works and deploys easily, but it also not using a lot of libraries. My take, and it may very well be wrong, is that the ecosystem is a nightmare in terms of deploying application. There's everything you could ever want though.

Of cause my experience may be down to the applications I tried to deploy.

The adoption of PSR-7 and the other PSR standards has made framework interoperation infinitely easier, and it's great to see Zend following the community in this regard. Combining their decoupled packages with those from the PHP League[0], for example, along with best-of-breed third-party libraries such as Monolog will mean that developers get to take advantage of amazing tools without worrying about writing yet another wrapper layer (I'm looking at you, Symfony bundles and Silex service-providers...)

Ah I remember it like it was yesterday. After years of doing work in the Java and Scala ecosphere I took a gig at a mortgage company doing PHP. Composer, Larval, Symphony2, Silex and a dozen other things made it seem to me like PHP might not be too bad. I might even have some fun!

Then the day I started I learned the sad truth. The "Technical Architect" laid down the law: all applications had to be written in Zend Framework 2 and nothing else. I gave it a chance, read all the docs and wrote an app in it. Suffice to say there was a scarce community and lots of defects. I also found how it worked overly complex. Imagine taking spring and asking "how can I make this harder and in PHP?" That's how I found the dependency injection framework to be.

Suffice to say I only lasted 3 months before moving on. ;-)

This sounds like one of those Whisper fake stories or a r/thathappened post, especially with the "suffice to say" and the smiley at the end.

I used ZF2 during the beta, and the activity on SO, their IRC and their forums were high even then, so I can't say I recognize what you say about the scarce community.

I also used ZF2 for a project (shortly after release) and I agree with your assessment of the community: there was clearly a lot of interest and contributions.

That being said, I also agree with carrja99's comments regarding the complexity and defects. Many things felt unfinished, and documentation was pretty poor if you wanted to step outside the boundaries of what was covered in their example applications (which was unfortunately necessary for my project). I ended up reading a great deal of framework code for that project.

I'm not doing PHP at the moment, but I don't think I'd even consider ZF3 at this point given how many other strong frameworks are available.

Ah that's what it was! I had to fix issues with components like the select group on a regular basis.

The if channel was actually quite active I think I was recalling the difficulty of using build tools with... Perforce.

i used to use ZF1. it was a good framework back in its days. than ZF2 come along with its overcomplicated boilerplate configuration and its backwards incompatibility. it was unusable with almost non existing community, so I took a time to look elsewhere and switched. I am happy now with my current framework and can't care less for ZF.

As someone who doesn't generally like PHP very much, I have to say that ZF1 was quite nice because of its simplicity. Too bad they abandoned it.

Now ZF2-3 have nothing to distinguish themselves from the other frameworks.

This just reminded me that, I'm a Zend Certified PHP Developer . Those days :))

Another ZCE here :)

Ah, nice. So you have an actual certificate which states that you are very good at remembering useless details from a programming language manual?

I always flat-out refused to become a Zend Certified Engineer. I'm perfectly willing to gain a certificate for my actual programming capabilities, but not for how well I can remember details in a manual.

grumble grumble standardized tests

Did you ever take the test?

There wasn't all that much about 'remembering useless details from a manual' in it. I've taken the cert twice (5.x and 5.3 IIRC) and in neither case was there much in the way of 'manual trivia'. Far more were scanning a piece of code and being able to determine what the outcome was (error? if so, which one? if not, what's the output?) than haystack/needle issues.

Funny you say that. In some other programming community, when one of the consultancy shops was questioning the community what they think of certifications, they were surprised to read that I was one of a few who said certifications are useless and especially so in programming. What it also reminds me of is one job interview where instead of the scheduled pair programming session I had to program my 3rd (IIRC) working program for them to show again that I can code something from scratch. In that case I didn't recall all the pieces of the framework/api from memory, and having to consult a reference book made me fail the test. If a certificate of Foo API Expert would have saved me that failure, then maybe it's worth something, but other than that a certificate says nothing about a developer.

You can say that. But, then I was introduced to real programming. :)

I'm actually quite glad I got this certification. It directly led to my current job, if nothing else. But it also forced me to learn more about PHP and become a better developer.

Genuinely curious about it: what are the reasons to start a new project on PHP?

One would be that PHP is all you know, another might be "wordpress".

Hiring pool (especially if you're aiming for low cost remote contractors)

How do you measure code quality and maintainability in that scenario?

Same way you'd measure it with in house developers.

Professionally, I work full time as .NET architect, but for my own projects, I always use PHP.

1) It just works. 2) Plenty of great frameworks. I especially love Laravel, which has _everything_ from a great IoC to ORM, as well as a huge community around it. 3) It's so easy and quick to get started. 4) HHVM (and also PHP 7) just makes PHP fly.

The main reason is that it's the least-competitive language to hire for in the Bay Area. There are other reasons too, though.

Laravel is easily competitive with Rails and Django. PHP7 is usually faster than Python and Ruby in most cases (it's roughly surpassed Facebook's HHVM). Composer and the PHP ecosystem give you very wide and convenient access to high-quality vendor libraries for just about anything you need (similar to gems/npm).

It's not as if it's broken. You can write a fantastic web application or web service using PHP. You can make a mess out of it for sure, but I've seen plenty of Rails projects turn into a big mess too.

Large community. With recent updates its fast and has modern features. A lot of PHP developers out there so hiring is not an issue (you just need to filter out the bad ones - and there's a lot of those too).

If your project is primarily web based its a really good choice.

At the end of the day though PHP is just a tool and what matters is how you use it and what's the outcome. If you are familiar with it then why not use it?

I personally feel like the biggest shortcoming of PHP is its legacy and the huge amount of bad code that you can find by searching on Google.

For me it's mainly because of Laravel. Everything just works as I would expect, to a level I can often figure out how to use internals without consulting the documentation. With that said I mostly have experience with PHP so perhaps there are superior alternatives in other languages.

Are there anyone still using Zend? I know most companies in France use Symphony.

Symfony is huge all over Europe (at least), but Zend is still used in projects started before Symfony matured, e.g. Magento.

I've been using ZF1 and then ZF2 for the last 4 years. The learning curve is a bit steep, but when you understand how the framework works, then it's a breeze to work with. I just had to learn by trying and looking at the sources, since the documentation is quite poor.

I never used Symfony, but I'm curious to hear from someone who tried both (ZF2, Symfony 2), what they like best of Symfony. Might give it a try in the next projects

I've never used Zend, but was tasked with creating a new web app for our customers.

I did some research, and after reading this article comparing the PHP frameworks [0], I ended up choosing Laravel, which I think was a great choice. The documentation seems quite good, and there seems to be a strong community. I found this site which has video tutorials that teach the framework https://laracasts.com/

After sitting through a few lessons, I was off, and finished a production ready web application in about a week, and was really proud of how it turned out, especially since I do systems administration for a living and not development.

[0] http://zenofcoding.com/2015/11/16/the-great-php-mvc-framewor...

We have a million line codebase that uses a bunch of ZF1 functionality (validation, database, web services, ...) plugged into a bespoke core. Overall I can't say we had any complaints. What we used from it worked well, and adapting it to our needs was relatively easy. We never did use any of the MVC or routing features though. And we never upgraded to ZF2, mostly because there wasn't any real reason to.

This reminds me... Does anyone actually run zend server? At a previous gig they standardized on zend framework 2 and were adopting zend server. I told them I thought that was a mistake given Nginx and PHP-fpm but I didn't stick around long enough to see how it panned out.

Too late. Way better alternatives exist nowadays.

The components are now no longer or less intertwined with others and are therefor more easily used by other projects. Basically like the symfony components are used everywhere.

A little competition or alternatives is always good.

Are you referring to other PHP frameworks?

Ur/Web is my favorite for many reasons. https://air.mozilla.org/ur-web-a-simple-model-for-programmin...

As someone who is currently stuck managing a Zend 1.9 project, if I ever see another Zend project it'll be too soon.

I absolutely hated ZF1. ZF2 was completely different story though.

Huh, interesting. I thought ZF2 was still getting ironed out. I've been a little out of touch with the community.

I have worked extensively with PHP, Python, Ruby and Node. I love PHP for deployment of end user apps. It just works. It literally takes minutes and you can be in your app rather than struggling with the language ecosystem.

It takes a lot of work and thinking to get to this state that is easy to overlook but it reflects a respect for users from the developers. And it shows. All the top apps in terms of deployment are PHP. I will ignore the many criticisms against it, they may be valid or they may not. The bottom line is utopianism is a deadend, there are always upsides and tradeoffs. PHP is improving and will continue to improve and is relatively simple to learn and use. Kudos.

Python is really a fantastic asset to the community. It's relatively simple to use and deploy thanks to its wide support on most Linux distibutions. I hate complexity and there are tons of interesting things in Python beyond Django. The server story could be improved but its not a deal breaker.

I think Ruby and to some extent Node but Ruby more so shows a thorough disrespect near hostility for the user. Deploying a Ruby app is always time for trepidation and you can be sure it is going to take time unless you are extremely well versed and upto date on the ecosystem ie a developer with a Ruby focus and perhaps that's why Ruby is best used in SAAS scenarios. I have deep doubts on the user focus of developers who expect users to deploy their Ruby apps.

There are tons of issues that crop up, from getting the base environment up and you do need a dev environment which has its own pitfalls and gotchas as gems may need to be built. Then there is the decision of where the gems should be, using things like RVM, Rbenv or the system ruby, the users who should run it and all the shenanigans that comes with it. Then deploying the apps themselves in terms of using things like Bundler which needs its own knowledge base and servers which could mean compiling Passenger with or without Nginx or using Unicorn. That is a lot of know how and it's a complete mess.

Updating apps can be equally troubling. There is no knowing which Ruby gem dependency could fail, which library may be needed, and that particular library may not be in your running distribution so you may need to compile it and that could start a long time consuming chain. This is millions of user and dev hours wasted for nothing, literally, that could be resolved by the developers and is much worse than anything you can throw at PHP which looks almost angelic in comparision. The deep knowlege required makes Ruby and Node extremely unpleasant. It should not take this amount of know how to simply deploy and use an app.

HN is dev focussed and it makes economic sense for devs to have expertise in the most rewarding languages, but this should not detract from the weakness and strengths of languages and I think it does.

So how do you "relatively simply" deploy python on the server? you have to know and work with pip, virtualenv, uwsgi, nginx, supervisor. Much more painful than composer, nginx and php-fpm. Using apache is even easier.

Disclaimer: maybe I'm doing something terribly wrong? I don't have much experience deploying python. If so please tell me.

The best way is with docker. But besides that, you usually only have to mess with uwsgi, and nginx once. You don't need virtualenv if you only have one python app on the server. You could however deploy a virtualenv, I have seen some people use the virtualenv as a large distributable, and just dropped that on the box with the code. But ultimately, if your not using docker, you could be using PAAS, AWS Elastic Beanstalk, Heroku, Google App engine, they all do this for you.

I was thinking about the case of a simple digitalocean/ec2 VPS, not a PAAS. In the end I realized that I don't need virtualenv and that makes things much simpler, except that every single blogpost/tutorial/info for beginners suggested using virtualenv and I was lost.

why I have to use zend? I have found it so complicated and there is no good support recourse for it

Wait, people still use PHP for new software?! And here I was thinking the industry had modernized...

Tell me what should "the industry" be using to be modernized? And, more importantly, why?

A language with some consistency would be a start. Go, TypeScript, Elixir are all superior to PHP in that aspect.

PHP lacks consistency in naming conventions, function signatures (is that a string or bitmask I'm supposed to pass?) and tons of other things.

I could write a novel about it, but there's already multiple websites/articles dedicated to PHP's inherent design flaws:

http://phpsadness.com/

https://whydoesitsuck.com/why-does-php-suck/

https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

Plus it's limited in capabilities compared to stuff like Node.js (or other libuv bindings), considering we get stuff like Hot Module Reloading, isomorphic/universal applications, simple websockets integration, all of which PHP is either incapable of providing or provides inferior solutions due to limitations of the PHP language or Zend Engine.

> PHP lacks consistency in naming conventions, function signatures (is that a string or bitmask I'm supposed to pass?) and tons of other things.

Welcome to Javascript?

PHP is still very web focused (server side), Javascript is a much better general purpose language, with more domains where it can be used and IMO a way much better language than PHP.

I agree that JS is a better general-purpose language than PHP, but it's still about as "Web focused" as PHP.

As far as general-purpose scripting languages go, it seems like Python has been the go-to choice in a whole bunch of domains for a couple of decades, for example:

- Unix scripting (the reason it's part of almost every distro's base install; I think even OSX includes Python)

- Desktop GUIs (GTK, wxWindows, tk, etc.)

- Non-Web, performance-insensitive games (i.e. pygame); these have always been outnumbered by Web games though, mostly with Flash and recently some with Javascript/HTML5.

- Scientific computing and data analysis (numpy, scipy, pandas, etc.); R, MATLAB, etc. are big too, but I wouldn't call them general-purpose.

About five years ago, I would occasionally run across some non-Web thing written in Ruby; i.e. I would find a CLI program which claimed to solve whatever problem I was tackling, then after about an hour battling with rubygems I'd rage quit and move on.

Within the past couple of years I've noticed a trend that these sorts of projects now tend to be written in Javascript, and its npm which makes me nope out after an hour.

Still, those have only been a tiny proportion of the applications I run across, so I certainly wouldn't recommend Javascript (or Ruby) as a general purpose language for publically distributed, non-Web applications, since a) their installation mechanisms don't seem battle-tested enough and b) very few people seem to be using them in that way.

If we're pulling alternatives out of a hat, I'd say that extrapolating the line from PHP to JS (i.e. more consistency, less bloat, fewer spandrels, safer by default, etc.) we'd reach Racket.

> A language with some consistency would be a start.

Your forget what species you're talking with here, and the language you're using to communicate right now :) When has Homo Sapiens ever exerted consistency in language design?! - really, programming languages are more like tools for communication that tools for solving technical problems, and they exhibit all the flaws that you see in other communication tools made by humans...

Not that this will ever change your mind, but there are excellent libev and experiment libuv bindings for PHP. Using ReactPHP (no relation) or Icicle allows for high performance asynchronous event loops. Just an interesting tidbit.

PHP is actively being developed with ton of new features added. It has a lively framework landscape with new versions released all the time. You can't get more modern than that.

Indeed, PHP is part of that industry. Some parts of the PHP eco-system are even leading the way, believe it or not.

Laravel is the best example for this, with spin-offs in several other languages. (Fair notice: many of the ideas in Laravel are not new, but borrowed/inspired from C#, rails and others)

* Node.js frameworks inspired by Laravel: http://www.adonisjs.com/, https://quorrajs.org/

* Python: http://www.pylonsproject.org/projects/pyramid/about, https://github.com/aacanakin/glim

* Java: http://wings.loonydev.com/

and so on

In other news, the `trait` type was recently popularized by PHP and can now be found in many languages: https://en.wikipedia.org/wiki/Trait_(computer_programming)

I doubt traits were "popularized" by PHP. PHP 5.4 was released in 2012, when most of the other listed languages had traits already.

those other languages weren't popular. hence "popularized"

What does Pyramid borrow from Laravel? I thought it grew from repoze, which was started a while before Laravel.

Yeah, and repoze was a refactoring of Zope which has one of the longest web framework histories around.

i stand corrected

I have no doubt there's plenty of innovative PHP libraries and frameworks, I (and many others) just believe they would be even better in another language ;)

Time will weed out the good from the bad, and clever people will surely bring over the good stuff to their favorite languages. Why not be part of that yourself?

For what it's worth I given up on PHP, after using it as my go-to language for about 16 years. I'm drinking the golang cool-aid and never coming back!

Reply on news.ycombinator.com