Hacker News Reader

Comment by jakobe | Hacker News Reader

That's why I still use vanilla PHP & Postgres for web projects. I don't use any hot new technologies, I don't use frameworks, I don't do unit testing. I try to use as little client side JS as possible. Whenever possible, I use static HTML.

The advantage is that I can create a working prototype in days. I can show something to the client very early, and I don't spend months to fulfill specifications the client didn't really understand in the first place.

When I leave the project, any PHP developer will be able to pick up and implement changes within hours. My code isn't elegant in any way, but it's simple.

View on HN

I hope no one looks at this as advice... I was in this position for a long time, and looking back, it's a completely unsustainable (and, in my opinion, irresponsible) method of development.

Problems with PHP itself aside, rolling your own from scratch only ever works out well for projects that start small and stay small. Even if the code is sane and readable, a developer starting with a site like this will need to understand either all of the patterns that are being used or to read and understand all of the code before being able to confidently and effectively work with it.

Contrast this to a framework, where similarly-sane code will yield something anyone with experience in the framework can almost-immediately begin working with.

Both have an up-front cost; however, the first incurs that cost every time any new developer starts working with any project done in such a way. The second is incurred once, period, making the startup time on any project on the same framework dramatically lower.

Frameworks are by no means a silver bullet, but their utility should not be underestimated, and the very nasty maintenance cost effects of the parent's post should be similarly understood.

The most important thing about a codebase is how it is designed at a large scale, its architecture. Using a framework often dictates a specific architecture, and this might lead to more manageable code bases.

But you can come up with a clear architecture without using a framework. For example, most projects I work on are well suited for a modular design. I can build them from many small, independent parts. So I write lots of PHP scripts consisting of some SQL queries on top and some presentation logic below. Introducing an ORM and separating Model/View/Controller would just add unnecessary complexity!

In my case, modularity ensures maintainability; there's no need for anyone to read all of the code before they can start working on something. Reading all of the code is only necessary if you write spaghetti code; but inexperienced developers will have no problem writing unmaintainable spaghetti code using any choice of framework!

I don't use any hot new technologies, I don't use frameworks, I don't do unit testing. I try to use as little client side JS as possible.

When I leave the project, any PHP developer will be able to pick up and implement changes within hours.

Famous last words for PHP apps rolled from scratch with no unit tests.

I find the most utility of unit tests, aside from basic validation and regression testing, actually comes from the fact that you are documenting usage examples of your entire API.

Indeed. This aspect is especially useful when new developers join the team and they have questions about which modules and methods to use for common tasks.

Hmm , I kind of have the opposite experience having picked up a bunch of PHP projects over the years.

Without tests I have less confidence with modifying another persons code. Without a framework it can be difficult to figure out the structure unless there is good documentation or the project has been well designed and structured (almost never the case).

Also I tend to either find problems with SQL injection,XSS or CSRF because they don't have a framework to help solve these or they have implemented their own solutions which are inevitably buggy or weird in some way.

Well he was talking about a prototype. You don't necessairly need to worry about such things if you're just bashing something out as a showcase, otherwise I'd agree.

That said, they don't allow SQL injections because they don't have a framework, they did it because they're stupid. Using a framework (and following the docs) will help save us from their stupidty, but so would learning about security issues.

Frameworks are largely about speed. They should make you develop quicker because loads of code is pre-written and generally it is of a higher quality than what you'll knock out in a few days because hundreds of man hours go into those libs.

That doesn't make any sense.

Once you learn a singular framework, it cuts out any additional effort you need to go through to create said prototypes and you end up with a prototype that can be extended to production standard.

Sure you need to spend the time to learn it, but that's a one time deal for the most part.

I took the same approach for a while up until I started rolling my own framework to speed things up. Now I just stick to Yii + postgres. Backend gets developed first with Yii's code gen tools, then the sexy ajax fun gets put into the clientside and the auto genned CRUD code gets extended to pass any additional fields I need back to the client.

Yii's CRUD code gen is incredibly nice to work with off the bat, so it really comes down to customizing json form validation messages and packing some partials views in with the response.

edit: It has ended up being that a good 70% of my time in web app dev is devoted to the tedium of changing little UI crap (Can this blue pop a little more? Can you put some shadowing here? I like this slider but I'm not feeling hyped about it... repeat ad infinitum), and not so much with complex backend work. It takes about two days, as you said, to get the server code going strong, and then two weeks to move divs around by an em here or there.

I prefer microframeworks like Flask, because I can get prototypes up in hours that incrementally become what it's supposed to be, scaling well to a large complicated application with deployments, unit tests, and documentation.

...you lost me, I was expecting to read something like "as all the interesting stuff happens on the client side anyway" after the first part with using vanilla PHP, but you didn't, so you would either end up with a "thin-client + thin-backend" (which is close to... no site/app at all), or you end up with spaghetti. Care to share a github link of such a website or web-app to see for ourselves how easy it is to "pick up and implement changes within hours"? I bet it's more like diving headfirst into a pool of spaghetti once the project grows past a point...

I'm not really seeing how what you are saying is any different then Django, Rails, Flask, or Sinatra for me and many others. I can stand up and prototype really fast in any of those frameworks and not have a mess of php left over at the end. That's kinda what those frameworks are made for. The op couldn't do that because he didn't know what he was doing. Which is fine we all start somewhere but we shouldn't choose worse tools just because we don't want to learn how to use the better tools. Things like Django's admin interface and Rails scaffolding are huge boosts to productivity I can't imagine giving those up out of a lack of knowledge or laziness. I don't mean to say you are a bad developer or lack knowledge but you reasoning is the exactly why these frameworks were created in the first place.

> When I leave the project, any PHP developer will be able to pick up and implement changes within hours.

Congratulations. But will they be able to make changes without breaking what you did? That's the mark of a good developer. Anyone can make something, but it takes real experience and constant thought about how your code will be observed by others down the line to make a truly great product.

> Problems with PHP itself aside, rolling your own from scratch only ever works out well for projects that start small and stay small.

Small projects were what PHP was initially designed for. By the way the OP is talking, I believe that he's working on mostly brochureware or at least small/simple apps that don't require 24/7 monitoring or maintenance.

This is good advice, as long as one reads it as "implement with technologies you know and trust". I'm the same way, in a sense, but my technologies list is much longer than PHP + Postgres. It gives me an advantage of having many tools in my toolbox.

Sticking to proven technology like PHP and Postgres I think is solid advice when you actually have to deliver something.

Avoiding frameworks, unit tests and client-side JavaScript is probably not as helpful. True, they can add bloat and complexity if you don't learn how to work with them.

Check out a framework like Laravel. Once you get over the hump you won't want to look back. I have my own framework called Phreeze which of course I'm partial towards but there are more recognized ones out there.

Some of the fun for a lot of us is to try out new technologies, when creating a new projekt. It simply motivates me more, when I also have to learn new stuff, and not just do the same old.

The world isn't in black and white; it's possible to choose something between the two extremes. Sure, don't blindly jump to the coolest new thing, but also don't stop trying/learning new things.

Did you miss the part where blaming the framework/tools was a mistake?

you are trolling, arent you ? :P

Reply on news.ycombinator.com