Live data from Hacker News

The MicroPHP Manifesto

funkatron.com

31–40 of 78 posts

Re: The MicroPHP Manifesto

#31

To me the biggest advantage of frameworks is documentation. When you bring on a new developer who has never worked with, say, CakePHP, you can point them to the docs to answer most questions. When you roll your own, you have to either document it yourself (ha!) or become the point man on all questions about how things work. My last company underwent a painful conversion from roll-your-own to Zend Framework. It slowed…

Ha! Couldn't agree more with you!

At my current job we're working with our own framework. I think it has two main downsides for my employers: 1) Employees are difficult to replace - they invested a lot of time in me, to teach me their stack. 2) New employees are difficult to introduce - fresh developers keep asking questions, disrupting the workflow.

For me it's a mixed situation. In short term I know I'm safe - why should they sack me? But in the long run I'll end up with untransferable skillset.

Re: The MicroPHP Manifesto

#32
What I needed in a framework was exactly what the author mentioned, something simple to start but could scale to complexity when needed. I tried a lot of other full stack frameworks and just couldn't get them to do really simple things without extensive customization. They were all very rigid in "how" you do things.

This is the reason I ended up writing my own micro-framework, Flight (http://flightphp.com/). The goal is to be as flexible and extensible as possible, while providing a tiny footprint.

Re: The MicroPHP Manifesto

#33
post #18

For most projects, if you're using PHP, you probably can't eliminate your dependencies. If you really can afford on a project to go super clean and not need a bunch of other libraries, then maybe this is a really good time to be using something other than PHP. I'm honestly not bagging on PHP here. I really do think it has its place, and I was a PHP developer for many years myself. But just as there's a place and a ti…

"if you're using PHP, you probably can't eliminate your dependencies" - since when is a dependency a bad thing? you are REUSING the code in a library because, presumably, you need to. Removing that reusable code means you probably have to write it yourself.

"super clean and not need a bunch of other libraries" - "clean" doesn't mean you don't use other people's code. It just means you made a decision to not reuse their code, which means THEY DON'T FIT YOUR PURPOSE, so you HAVE TO WRITE YOUR OWN thing.

"a really good time to be using something other than PHP" - this is just dumb. why switch languages? what does that have to do with the fact that you chose not to reuse other people's code? you sir have no clue what you're talking about.

"I'm honestly not bagging on PHP here" - bullshit, you're trolling.

"I really do think it has its place [...] But just as there's a place and a time for PHP, there is a place and a time for other languages, too" - So what, PHP is too old for you, son? And what "other languages" might you mean? Keep thinking your is automatically better than PHP. Get off my lawn. And take your arguments with you. Oh wait, you didn't bring any arguments.

"When you have no dependencies on legacy PHP libraries" - legacy? Are you implying that all PHP code is legacy now, because, somehow, PHP is too old for you, son? Or are you implying that the only way to have library dependencies in PHP is to rely on legacy libraries, because, somehow, new libraries aren't being released? Your statement makes no sense.

"the opportunity to go lean and clean" - try some x86 ASM with no dependencies. By your logic, that'll be lean and clean.

"and do what you want -- that's the project to not use PHP" - you must be high, or mentally retarded, or just a bad coder. Who said you can't write code in PHP that does not rely on other libraries? Why would you switch languages? Who said people don't rely on other libraries in whatever your favorite language is?

To sum up, go die in a fire.

Re: The MicroPHP Manifesto

#34
"The MicroPHP Manifesto" is actually "The Lone Programmer Manifesto".

Programming in today's world means working with other people's code. All a framework does is provide a set of design patterns and standards that a group of programmers can adhere to. This encourages code reuse and allows you as a programmer to create "black boxes" - components with a well defined programming interfaces that behave in a consistent & predictable manner.

Real-world example: I'm currently working with a custom-built CMS programmed in PHP. I'm the second man on a what began as a one-man project. The CMS author wrote a bunch of database functions (essentially wrappers for the deprecated mysql_* functions) and dumped them into a file. Now, the author wasn't aware that you can (and should) lazy-load database connections - so every time you need to talk to the database, you have to manually connected using `cms_db_connect()` AND select the database with `cms_db_select(CONST_DATABASE_NAME)`. As pretty much every page initiates a database connection this code is EVERYWHERE.

And this is only the tip of the iceberg. There's also a half-assed MVC implementation, ubiquitous usage of inline CSS, un-encapsulated code, and a butt-load of quirky behavior. Now if the original author had take a little bit of time at the beginning and researched a proper framework or used an existing CMS our project would not be behind schedule - and it would be far easier to add another developer into the mix. All this meaningless complexity because the original author took the "simple" route of not working with a framework authored by third parties.

Re: The MicroPHP Manifesto

#37
This post bothers me a lot, because it misrepresents a very large movement in American music while at the same time decrying the value of community-developed frameworks. Black Flag is a great band, but their "fast and simple" approach to playing music ran into a lot of the same problems that tech startups find when they, too, decide to take a "fast and simple" approach to web development -- those being high employee turnover, extremely low profitability, and a lot of in-fighting.

Black Flag made a lot of junk because they couldn't get the band to cooperate. They had to keep re-doing the same songs over and over because their lead singer kept changing. Talk about a good analogy for unnecessary rewrites! At one point, when the artistic direction and ego situation became especially dire, one side of an album was all spoken word, and the other side was all instrumental. In the end, they just ended up becoming another "metal" band with albums like "Slip it In" towards the end of their discography. Black Flag is a great band, but this post completely misrepresents what they did and what it means, if anything for software development. If it's the story of anything, it's the story of an entrepreneur who kept paying for all the corners he cut.

Rush wanted to write complex albums that dealt with a lot of layered meaning. There was a lot more planning and attention paid to what got laid onto their tracks. In exchange for their hard work, attention to detail, and planning, they were well compensated. They played arenas and sold a ton of albums. Black Flag played VFW halls, and I'll be damned if most of their fans these days didn't just torrent their discography and be done with it. What would you want for your business? There will be no hipsters to fondly nostalgize your unsuccessful web application.

Re: The MicroPHP Manifesto

#38
post #21
post #17

Earlier quoted context omitted.

"I say that, beautiful or not, these two options are the best way to write unmaintainable code that doesn't ever work." I agree that for big jobs, you can't prioritize pretty over featureful, but, respectfully, I think you are overstating your point here: "doesn't ever work." That's simply not true. Have you really never written a working program without a full featured framework? I think one of the points that isn't…

>Probably my biggest issue with CakePHP (what I use) is that when you step outside the standard use cases you fall down a rabbit hole of complexity and peculiar idioms. The result here is that one becomes a "Cake developer" rather than a "PHP developer"; there is a high degree of lock-in and switching the entire toolset becomes difficult and impractical. Totally agree. But that's because of poor design in CakePHP (I…

Please explain reasoning behind CakePHP having a poor design. I'm curious as most people that say a framework or tool sucks actually are just using the framework/tool in an incorrect way, and there is frequently an elegant way to tackle their issues. This applies to more than just CakePHP, mind you.

Re: The MicroPHP Manifesto

#39
I'm a hundred percent with the author on this—most PHP frameworks and libraries are a ridiculous mess. My requirement for using third-party libraries are that they do a single thing, that they do it well, and that they have little or no dependencies. There's no good reason why most third-party code can't be a single class / file.

Our third-party library stack for the (very complex) chartboost.com architecture is made up of simple, modular parts: Paraglide as micro-MVC (one class, and a handful of folder for the base structure), MongoModel (one class, as MongoDB ORM), etc. Most of our third-party libraries are very simple and manageable, the way all PHP should be.

As for code verbosity: everything is auto-loaded on the fly when needed. Our code has practically no `require` statements. We just follow a simple conventions of where to place files and how to name classes, and everything works smoothly and painlessly.

Most importantly in this setup, none of the libraries depend on the framework of choice or on anything architectural. The framework doesn't even require being run in a web environment. This lets us do powerful and flexible things like use Facebook's `phpsh` library to open up a shell that will have our entire environment available and loaded on the fly. We can also switch between dev, production or local environments on the fly.

Post reply on HN