I've developed my first serious web app / start up, its a social network and took about 300 hours to develop to where it is now. I built it from scratch using PHP, mostly because thats what im best at, but also because i like the idea of knowing all the parts and having total control.<p>To me it seems like using a framework would take away from that control.<p>What does hacker news think about this issue?
Depends... what's more important to you, having control of every little detail of how underlying plumbing works, or increased productivity and the opportunity to spend your (finite) time on things that add value?<p>I mean, think about it... you <i>already</i> don't <i>really</i> have "complete control." You (presumably) didn't code your own OS from scratch in machine language... so why not? Did you code your own web-server from scratch? Your own PHP runtime? IP stack? No?<p>Seriously, nobody does that stuff from scratch because it takes too much time and they'd rather focus on the value they're actually trying to create, as opposed to re-creating the wheel. That said, having the ability to go down to the lowest levels of the stack does have value... when you actually <i>need</i> to change something to achieve your goals. Take the guys who originally built Beowulf clusters... they actually did go in and hack on network drivers and IP stacks and what-not, because they had a unique need (low latency) that required it.<p>Anyway, I'd say apply this by analogy to what you're doing. Focus on adding value and avoid re-inventing the wheel, unless it's just a hobby project for learning / experimentation... but reserve the right to go as low level as you need, if and when you have an actual need.
I'd definetly go for the framework approach. After building apps with and without frameworks, its a lot less painful to build upon something which exists already.<p>There are so many advantages to go framework, I can't tell everyone:
- frameworks are (mostly) under development, so you can benefit from trends and improvements in web development<p>- frameworks are well tested<p>- frameworks are more secure. Do you have all holes for XSS etc. closed? Are you sure?<p>- frameworks have almost always a community behind it, so you benefit from other users knowledge and plugins<p>- frameworks have plugins. You don't have to write anything from scratch, like DB connections, authorization or file uploads<p>- frameworks have documentation. Unless you are the sole developer of your app, you really want to have good docs.<p>Do frameworks have disadvantages? Sure, but I don't think it outweighs the advantages.
I've just spent a couple of years on a project that I've built 'from scratch' in PHP attempting to follow an MVC pattern and trying to do things the 'right way' as I understood them at the time.<p>It's got to the point now where mistakes are coming back to haunt me, and some things that should be easy are not due to decisions made previously. This is compounded by the fact that growth of the code has been somewhat organic, and I didn't have a chance to anticipate some of the things we've done in the last year.<p>The upshot of all this is it's now time to re-write everything, taking the project as it now stands as the 'spec' for the rebuilt version.<p>I've learnt a lot during the project, and I'm a very different coder to the one I was at the beginning. One of the main things I've learnt is that I don't have enough time to be working on the "would be nice"'s in building your own framework, getting results ends up taking priority over taking time to 'do it right'.<p>So for this rebuild I'll be using an existing framework for several reasons.....<p><i>The people building the framework have time to concentrate on how the underlying code is built, and don't have to worry about a specific implementation</i><p><i>As I don't have to worry about designing my application, I have a spec, I can spare the time to learn the framework properly as I re-implement</i><p><i>Once I'm up to speed with the framework I should, in theory, be able to design and build anything in future much more rapidly.</i><p><i>I won't have to write any more bloody boilerplate that I've been re-doing due to my lack of knowledge/foresight in growing my current codebase</i><p><i>It's fun to learn, and peeking inside the framework (possibly because I'll need to bend it to my needs) should teach me new tricks.</i><p>I don't think a decent framework should take away control of your code. I've had the luck to be able to take 4 weeks evaluating some of the options both in PHP and other languages and anything that leaves the underlying code in a 'black box of magic' has been discarded. There are plenty of options out there with excellent docs and api's and lots of room to bend things to your will.<p>My personal choice is to go onwards with Yii, but framework choice is fairly subjective and a whole other conversation.
As a long-time PHP developer, I've worked on both frameworks and from-scratch applications, and from my experience, having even a minimalist's framework goes a <i>long way</i> toward organizing your codebase; it takes a lot of discipline and foresight to keep a from-scratch project organized.<p>If you enjoy maintaining control and knowledge of your entire stack, then I would highly recommend using the CodeIgniter framework. It's designed to take care of most of the tedious bits, while staying completely out of your way when it gets to the actual meat of your project. It's very easy to modify or extend if you need to, with IMO excellent documentation of its API. Yet it still manages to offer enough structure that even I can keep my projects organized with little effort.<p>I know there are a couple forks of CodeIgniter, such as Kohana, but I don't think they manage to capture or maintain the same level of raw simplicity or lightweight feel of the base CI framework. YMMV ofc.
I do not want to weigh in on the issue as a whole, but rather shed some light on an aspect you as a single coder have probably not given much thought to: accessibility and maintainability.<p>When I started using ruby on rails, adhering to all the conventions DHH came up with, especially the directory structure, felt like giving up a lot of control. And I, too, liked control.<p>But I had an epiphany when I first had to work with other people's rails code: Never before did it take me so little time to dive into and familiarize myself with someone else's code. I was productive at day one, while my customer did not really expect any results for the first 4-5 days.<p>So, if you ever plan on having someone else work with you on your code, or you need someone to take over maintenance of it, having a foundation that other people are already familiar with and where there is tons of documentation available, is a huge advantage.<p>But even if you stay alone on this project. With all you have learned, it is possible that you will approach your next project in a completely different way. In that case coming back to your old codebase in 6 months or a year will be painful. Having a consistent framework for all of your projects helps mitigate this kind of pain a lot.
This discussion has a lot of good points:<p><a href="http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html" rel="nofollow">http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_swit...</a><p>Basically, you're not alone in liking that degree of control, but the guy admits that simply using a framework like Rails can help you develop better coding skills in any language, especially if you're unfamiliar with MVC architectures.
If you had learned the right framework, you would be able to develop your next project much quicker, and you'd be a more attractive candidate to companies who use that framework. I guessing the attitude of hn is use the right tool for the job depending on your requirements.
There are some 'skeleton' frameworks available. These provide only the very essentials, like a database abstraction layer, user classes and some useful function wrappers.<p>For PHP, Tyler Hall's 'Simple PHP framework' is a good example.
When you guys discuss frameworks, what exactly are you referencing? I've heard people use that word in reference to languages, CMS', etc...<p>Thanks for clearing this up for me!
well the problem with control is that if you need to stuff people you loose it as nobody would understand yours codebase and try to rewrite it anyway. Framework forces convention over configuration so it easy for newcommers just to grab docs and start coding. Also you can try to stuff some framework-experienced people.
Having been through a similar circumstance (built a huge application by myself, which later grew into my job) -- one of the major difficulties you'll have is in finding anybody else that can understand your code.<p>One of the hidden features for a framework, of any sort, is the general understanding of where things are, or can be expected to be. If I work within the conventions of Django, then when I'm hiring somebody, I can ask them if they know Django -- assuming all other things being equal, they'll have a much shorter learning curve ramping up to learn what I've built because they'll know, in general, where to look for certain kinds of things.<p>If you intend to ever hire anybody, then I'd take every spare minute you have where you aren't coding, and get to documenting the framework you've built.