Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The MicroPHP Manifesto

funkatron.com

Post reply on HN
Print view View original

21–30 of 78 posts

Re: The MicroPHP Manifesto

#21

Post by zfran »

sequoia wrote: post #17
jrockway wrote: post #7

Real-world applications are complicated. There are three ways to handle this problem. The first is to not handle the problem. Implement something "simple" that doesn't work in uncommon cases. This seems nice because there isn't much code and there isn't much complexity. But that's because your program doesn't actually work, which is usually considered a bad thing. (This program right here -> "" The second way is to "…

"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 used it too).

>What I see in this post that I agree with is the idea that PHP tools should be more modular and decoupled, so you can grab a full stack bundle if you want, but can use modules piecemeal if you don't. Currently, the latter option is lacking in PHP.

Actually, it's not. Take a look at Zend Framework and you'll see that you have a TON of modules for doing all kind of stuff and if you want you could use just the core ones and ignore the rest. It works so well that I even use components in non-Zend Framework projects.

Re: The MicroPHP Manifesto

#22

Post by strmpnk »

jrockway wrote: post #7

Real-world applications are complicated. There are three ways to handle this problem. The first is to not handle the problem. Implement something "simple" that doesn't work in uncommon cases. This seems nice because there isn't much code and there isn't much complexity. But that's because your program doesn't actually work, which is usually considered a bad thing. (This program right here -> "" The second way is to "…

The fourth option is to break your problem up. Not all problems should be handled in one pass by one giant program.

Re: The MicroPHP Manifesto

#23

Post by drumdance »

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 us down in the short term, but there was a huge payoff in developer productivity in the long term.

Re: The MicroPHP Manifesto

#24

Post by zbuc »

jrockway wrote: post #7

Real-world applications are complicated. There are three ways to handle this problem. The first is to not handle the problem. Implement something "simple" that doesn't work in uncommon cases. This seems nice because there isn't much code and there isn't much complexity. But that's because your program doesn't actually work, which is usually considered a bad thing. (This program right here -> "" The second way is to "…

I don't think the article "suggests that you eschew option three" at all.

The author recommended several microframeworks. He's arguing against large, monolithic frameworks and pointing towards a more pragmatic, YAGNI approach.

Use a small framework that gives you simple things -- URL routing, JSON parsing, etc. Maybe a base application structure to keep things sane.

You can do a lot of very useful things in a small, reusable microframework that don't have the level of complexity of a larger framework like Zend.

edit: I knew your name was familiar. Good work on Catalyst. My choice in framework really depends on the project.

Re: The MicroPHP Manifesto

#25

Post by hullo »

sequoia wrote: post #17
jrockway wrote: post #7

Real-world applications are complicated. There are three ways to handle this problem. The first is to not handle the problem. Implement something "simple" that doesn't work in uncommon cases. This seems nice because there isn't much code and there isn't much complexity. But that's because your program doesn't actually work, which is usually considered a bad thing. (This program right here -> "" The second way is to "…

"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…

symfony2 (which the OP picks on a little bit) has taken exactly this approach, there's much more emphasis on the components than the framework as a whole.

Re: The MicroPHP Manifesto

#26

Post by jqueryin »

jrockway wrote: post #7

Real-world applications are complicated. There are three ways to handle this problem. The first is to not handle the problem. Implement something "simple" that doesn't work in uncommon cases. This seems nice because there isn't much code and there isn't much complexity. But that's because your program doesn't actually work, which is usually considered a bad thing. (This program right here -> "" The second way is to "…

    If it looks like a nail and feels like a nail, don't use
    a sledgehammer.
We should all be pushing for "the right tool for the right job"; a concept that is both language and framework agnostic. When you start your next project, take a moment to think about all of the core components and modules that will be necessary to complete said project.

Many of us (including me, at times) have forgotten our primary role as an application architect. We need to take a giant step back to look at the project from a bird's eye view to gain some insight into how to solve the problem(s) in an efficient and timely manner.

Re: The MicroPHP Manifesto

#27

Post by davidu »

This is the nature of languages, particularly scripting languages. Fundamentally, the creators of PHP are not representative of the mainstream users of PHP. That's a problem.

Just look at perl6.

Use the parts of PHP that matter most to you.

Re: The MicroPHP Manifesto

#29

Post by jQueryIsAwesome »

strmpnk wrote: post #22
jrockway wrote: post #7

Real-world applications are complicated. There are three ways to handle this problem. The first is to not handle the problem. Implement something "simple" that doesn't work in uncommon cases. This seems nice because there isn't much code and there isn't much complexity. But that's because your program doesn't actually work, which is usually considered a bad thing. (This program right here -> "" The second way is to "…

The fourth option is to break your problem up. Not all problems should be handled in one pass by one giant program.

Yeah, i vote for that one; i try to code in little modular pieces; and if a connection is needed i try to make it as short and simple as possible.

Re: The MicroPHP Manifesto

#30

Post by nickasloan »

Great post. I'd like to call attention to one point he makes:

"It doesn’t mean that stuff is bad, in the grand scheme of things. It doesn’t mean it has no value or is the wrong approach for many. But it’s the wrong approach for me, for sure."

Let's face it, the differences among Zend Framework vs Symfony vs Limonade vs Rails vs Django aren't really that big of a deal for most of our projects. In fact, I don't know if I've ever worked on a project that any of those frameworks couldn't solve effectively. The fact is that for the simple database web apps that most of us are writing, these decisions are not very critical.

It seems to me that Ed recognizes something that no one talks about as much as they should. The important consideration is not "Which tool is right for the project?". Most of the time "Which tool is right for the developer?" is the question that the success of a project hangs on.

Ed and his coworkers at http://gimmebar.com recognize this. They have adopted Javascript as the lingua franca that allows their frontend and backend developers to work together harmoniously. Developers working in harmony can achieve great things. The 5 Days of Gimmebar are proof enough of that (http://blog.gimmebar.com/post/12793742161/5-days-of-gimme-ba...).

Ed says that a simple framework with useful single-purpose third-party components is the right choice for him. Maybe it is for you too, maybe it isn't. I think the important takeaway from this post is that we should all strive for the self awareness that allows us to recognize what will let us work most effectively. I know I've been giving that question a lot of thought lately myself.

Post reply on HN