5 ms·

"The learning curve these days is not a new language (it takes a proficient programmer just a few days to get her arms around the basics of a new language). Th

by rick888 16y ago

"The learning curve these days is not a new language (it takes a proficient programmer just a few days to get her arms around the basics of a new language). The learning curve is with the framework." This is my main problem with this line of thinking. Developers aren't actually developing anymore. They are mashing together frameworks. I've looked into frameworks like Django. It's not good because it abstracts away the functionality of the database. It's nice that everything is an object, but if you want to do something more complex and go around the framework, things get messy and start to feel hackish. I am a PHP developer and I generally don't use a PHP framework. I have my own set of classes that I wrote (and improve on). I have also used the smarty template engine in the past, which works really well for keeping HTML separated from the actual code (and it has built-in caching). Jquery is also great for the front-end. I started development with pascal, then moved to c/c++, and finally PHP. I like PHP because it is a high-level enough language that makes development easy, yet it's still powerful enough to allow for complexity and lower-level functionality. The c-style syntax doesn't hurt either. PHP 4 and below had many security issues (what were they thinking with register_globals?), but 5.1+ has made some major changes.

commanda 16y ago
You say you don't believe that mashing together frameworks is actual development, yet you recommend the jQuery framework for front-end coding. Do you draw a distinction between front-end and back-end - is front-end work not really development? In my experience, the time it takes to become proficient with an existing framework is generally a lot shorter than writing a framework yourself. And, generally, the existing one will have been vetted by thousands of people before me.
- terryjsmith 16y ago
  jQuery is nice because you can jump back and forth between it and "regular" Javascript. Inside your $(id).click() function you can just as easily call document.getElementById. jQuery even provides you access to all of the DOM level objects in case you want to escape outside of it for a bit. Most frameworks do not let you do this and you have to actually have to work at it/hack at it to use functionality that isn't provided by them.
- dinkumthinkum 16y ago
  Well, one major reason to use jQuery, besides all of the cool APIs, is that it encapsulates most of that messy browser specific stuff you have to account for which is not that analogous to what you have to do with most programming languages.
- rick888 16y ago
  "You say you don't believe that mashing together frameworks is actual development, yet you recommend the jQuery framework for front-end coding. Do you draw a distinction between front-end and back-end - is front-end work not really development?" I use it sparingly. Mostly because there are many quirks between the various browsers and jquery seems to have a pretty good handle on it. As an example: rather than using one of the many bloated pagination libraries I found based on Jquery, I rolled my own in less code. It ended up much smaller because I didn't have to incorporate everything in the existing libraries. Most frameworks throw in everything, because they have to account for all possibilities, rather than just the ones that you need. You end up with bloated code, unless you know how it works behind the scenes (and many times even if you do, you can't take out the parts that you don't need).
dasil003 16y ago
> This is my main problem with this line of thinking. Developers aren't actually developing anymore. They are mashing together frameworks. Usually you have one framework and then you mash together a bunch of libraries. The framework exists as a way to abstract the most common functionality of your chosen platform. A good framework eliminates a lot of boilerplate without getting in your way when you need to go beyond the common functionality. The ironic thing about your post is that PHP itself has a bit of a nascent framework quality to it. It was developed before web frameworks of course, at a time when everyone was writing Perl CGI scripts using a bunch of libraries. The revolutionary aspect of PHP and mod_php in particular, was that it had automatic hooks into all the common aspects of the HTTP cycle, including the page metaphor, which meant you could change a static page into a dynamic page with no effort. PHP was state of the art when websites were mostly still just pages. Serious programmers laughed of course, how could you build a serious application in this glorified templating language? So they continued to develop their "proper" frameworks like Struts, Zope and countless others rooted in the experience of GUI developers from ages past. However as web development experience and understanding matured, there was a widening gap between PHP and the enterprise frameworks. And this gap is squarely where Rails was dropped in 2004. There are so many things that are common to all web applications that PHP doesn't handle. DHH's brilliance was not so much in the details of the original Rails code, but in picking and choosing best practices and unifying them in one package in a minimal way. I think this was instrumental in web framework developers from all languages re-evaluating what was really necessary and what cruft could be eliminated. Nowadays Rails is pretty enterprisey in capability, but it still avoids most of the overhead present in enterprise frameworks of 10 years ago. The minimalist torch has been carried forward by upstarts such as Merb and now Sinatra. The strength of these various frameworks is that they do things that tens of thousands of developers need to do every day in a standardized way that's had massive input and refinement over time. When you use these frameworks you can hire people and they hit the ground running. When you use your own personal library then every new developer has to get up to speed on your dime, and you foot the bill of maintenance yourself rather than gaining the advantage of a large open-source community.
blacksmythe 16y ago
>> I generally don't use a PHP framework. I have my own set of classes that I wrote (and improve on). In other words you have written your own framework that suits you well. I would guess the only thing that stops this from being a general purpose framework is documentation and marketing.
- j_baker 16y ago
  To be fair, a couple of classes domake necessarily make a framework: http://en.wikipedia.org/wiki/Hollywood_Principle http://en.wikipedia.org/wiki/Hollywood_Principle
- rick888 16y ago
  "In other words you have written your own framework that suits you well. I would guess the only thing that stops this from being a general purpose framework is documentation and marketing." In a way, yes. It's a boiler plate of classes that I use for most projects (db, sessions, and some other helpful funcs that I built). If I could take out all of the crap that I don't need that is usually in most frameworks, I might consider using one.
  - yxhuvud 16y ago
    Take a look at Sinatra.
    - dagw 16y ago
      Or Flask if you want to use python.
silvertab 16y ago
> I've looked into frameworks like Django. It's not good because it abstracts away the functionality of the database. It's nice that everything is an object, but if you want to do something more complex and go around the framework, things get messy and start to feel hackish. I was thinking the same when I first worked with frameworks (Rails at first, Django now...). First there was the honeymoon phase, where it seems like the framework does everything you need... then you start to encounter the first problems (i.e. try to do something thats a bit more complex...), and you start thinking; Well, the framework does everything for you 90% of the time, but the 10% when it doesn't makes up for the time you saved... But I found that after working with a framework for a while (almost 2 years with Django in my case) you get to know its strength and its weakness, and you get to do more complex stuff a lot more easily (for example, I often resort to raw SQL with Django, it's just a matter of doing Model.objects.raw() ). In the end, I think it's worth working with a framework because well, obviously it prevents you from having to re-write boring boilerplate/glue code, but it also (usually, or perhaps I should say, hopefully) means you are working with a well-tested codebase on which to build up on. In my case, I would say the time it took me to really learn how to work with Django was worth it today, if only for the time it makes me save now!...
brendoncrawford 16y ago
Ah yes, the inevitable "I write my own framework" post. This completely overlooks the fact that with a well-known framework you have thousands of other developers available to help you if you should run into a problem. It also overlooks the value of not re-inventing the wheel. > I've looked into frameworks like Django. It's not good because it abstracts away the functionality of the database. The Django ORM is no more or less easy to do your own queries as CakePHP, Propel, Doctrine, Hibernate, or SQLAlchemy: blogs = Blog.objects.raw('SELECT * FROM myapp_blog')
- mgkimsal 16y ago
  "with a well-known framework you have thousands of other developers available to help you if you should run into a problem" Not always true - I'd say often not true. 1. I have to learn where to get support from these thousands of other developers. 2. I have to read through dozens of posts from others asking the same questions I have, but often phrased inconsistently. 3. I have to figure out which answers are correct, and which are wrong, and which were correct 2 years ago, but aren't right currently because 2 libraries are now deprecated. 4. I have to learn enough about the framework to be able to formulate coherent questions using the proper terms and express my specific problem. 5. I have to deal with 0 people responding after 4 days of posting. 6. I have to deal with responses just being "me too". 7. I have to deal with responses being "RTFM" or "LMGTFY". 8. I have to deal with well-intentioned people who ask me for help replicating my setup in their environment so they can help me. And there's likely more variations I could think of that make the magic "there's thousands of developers to help" argument null and void in many situations.
  - hdctambien 16y ago
    I think stackoverflow.com pretty much solves all of these problems for you.

by rick888 16y ago

commanda 16y ago

You say you don't believe that mashing together frameworks is actual development, yet you recommend the jQuery framework for front-end coding. Do you draw a distinction between front-end and back-end - is front-end work not really development? In my experience, the time it takes to become proficient with an existing framework is generally a lot shorter than writing a framework yourself. And, generally, the existing one will have been vetted by thousands of people before me.

terryjsmith 16y ago
jQuery is nice because you can jump back and forth between it and "regular" Javascript. Inside your $(id).click() function you can just as easily call document.getElementById. jQuery even provides you access to all of the DOM level objects in case you want to escape outside of it for a bit. Most frameworks do not let you do this and you have to actually have to work at it/hack at it to use functionality that isn't provided by them.
dinkumthinkum 16y ago
Well, one major reason to use jQuery, besides all of the cool APIs, is that it encapsulates most of that messy browser specific stuff you have to account for which is not that analogous to what you have to do with most programming languages.
rick888 16y ago
"You say you don't believe that mashing together frameworks is actual development, yet you recommend the jQuery framework for front-end coding. Do you draw a distinction between front-end and back-end - is front-end work not really development?" I use it sparingly. Mostly because there are many quirks between the various browsers and jquery seems to have a pretty good handle on it. As an example: rather than using one of the many bloated pagination libraries I found based on Jquery, I rolled my own in less code. It ended up much smaller because I didn't have to incorporate everything in the existing libraries. Most frameworks throw in everything, because they have to account for all possibilities, rather than just the ones that you need. You end up with bloated code, unless you know how it works behind the scenes (and many times even if you do, you can't take out the parts that you don't need).

dasil003 16y ago

> This is my main problem with this line of thinking. Developers aren't actually developing anymore. They are mashing together frameworks. Usually you have one framework and then you mash together a bunch of libraries. The framework exists as a way to abstract the most common functionality of your chosen platform. A good framework eliminates a lot of boilerplate without getting in your way when you need to go beyond the common functionality. The ironic thing about your post is that PHP itself has a bit of a nascent framework quality to it. It was developed before web frameworks of course, at a time when everyone was writing Perl CGI scripts using a bunch of libraries. The revolutionary aspect of PHP and mod_php in particular, was that it had automatic hooks into all the common aspects of the HTTP cycle, including the page metaphor, which meant you could change a static page into a dynamic page with no effort. PHP was state of the art when websites were mostly still just pages. Serious programmers laughed of course, how could you build a serious application in this glorified templating language? So they continued to develop their "proper" frameworks like Struts, Zope and countless others rooted in the experience of GUI developers from ages past. However as web development experience and understanding matured, there was a widening gap between PHP and the enterprise frameworks. And this gap is squarely where Rails was dropped in 2004. There are so many things that are common to all web applications that PHP doesn't handle. DHH's brilliance was not so much in the details of the original Rails code, but in picking and choosing best practices and unifying them in one package in a minimal way. I think this was instrumental in web framework developers from all languages re-evaluating what was really necessary and what cruft could be eliminated. Nowadays Rails is pretty enterprisey in capability, but it still avoids most of the overhead present in enterprise frameworks of 10 years ago. The minimalist torch has been carried forward by upstarts such as Merb and now Sinatra. The strength of these various frameworks is that they do things that tens of thousands of developers need to do every day in a standardized way that's had massive input and refinement over time. When you use these frameworks you can hire people and they hit the ground running. When you use your own personal library then every new developer has to get up to speed on your dime, and you foot the bill of maintenance yourself rather than gaining the advantage of a large open-source community.

blacksmythe 16y ago

>> I generally don't use a PHP framework. I have my own set of classes that I wrote (and improve on). In other words you have written your own framework that suits you well. I would guess the only thing that stops this from being a general purpose framework is documentation and marketing.

j_baker 16y ago
To be fair, a couple of classes domake necessarily make a framework: http://en.wikipedia.org/wiki/Hollywood_Principle http://en.wikipedia.org/wiki/Hollywood_Principle
rick888 16y ago
"In other words you have written your own framework that suits you well. I would guess the only thing that stops this from being a general purpose framework is documentation and marketing." In a way, yes. It's a boiler plate of classes that I use for most projects (db, sessions, and some other helpful funcs that I built). If I could take out all of the crap that I don't need that is usually in most frameworks, I might consider using one.
- yxhuvud 16y ago
  Take a look at Sinatra.
  - dagw 16y ago
    Or Flask if you want to use python.

silvertab 16y ago

> I've looked into frameworks like Django. It's not good because it abstracts away the functionality of the database. It's nice that everything is an object, but if you want to do something more complex and go around the framework, things get messy and start to feel hackish. I was thinking the same when I first worked with frameworks (Rails at first, Django now...). First there was the honeymoon phase, where it seems like the framework does everything you need... then you start to encounter the first problems (i.e. try to do something thats a bit more complex...), and you start thinking; Well, the framework does everything for you 90% of the time, but the 10% when it doesn't makes up for the time you saved... But I found that after working with a framework for a while (almost 2 years with Django in my case) you get to know its strength and its weakness, and you get to do more complex stuff a lot more easily (for example, I often resort to raw SQL with Django, it's just a matter of doing Model.objects.raw() ). In the end, I think it's worth working with a framework because well, obviously it prevents you from having to re-write boring boilerplate/glue code, but it also (usually, or perhaps I should say, hopefully) means you are working with a well-tested codebase on which to build up on. In my case, I would say the time it took me to really learn how to work with Django was worth it today, if only for the time it makes me save now!...

brendoncrawford 16y ago

Ah yes, the inevitable "I write my own framework" post. This completely overlooks the fact that with a well-known framework you have thousands of other developers available to help you if you should run into a problem. It also overlooks the value of not re-inventing the wheel. > I've looked into frameworks like Django. It's not good because it abstracts away the functionality of the database. The Django ORM is no more or less easy to do your own queries as CakePHP, Propel, Doctrine, Hibernate, or SQLAlchemy: blogs = Blog.objects.raw('SELECT * FROM myapp_blog')

mgkimsal 16y ago
"with a well-known framework you have thousands of other developers available to help you if you should run into a problem" Not always true - I'd say often not true. 1. I have to learn where to get support from these thousands of other developers. 2. I have to read through dozens of posts from others asking the same questions I have, but often phrased inconsistently. 3. I have to figure out which answers are correct, and which are wrong, and which were correct 2 years ago, but aren't right currently because 2 libraries are now deprecated. 4. I have to learn enough about the framework to be able to formulate coherent questions using the proper terms and express my specific problem. 5. I have to deal with 0 people responding after 4 days of posting. 6. I have to deal with responses just being "me too". 7. I have to deal with responses being "RTFM" or "LMGTFY". 8. I have to deal with well-intentioned people who ask me for help replicating my setup in their environment so they can help me. And there's likely more variations I could think of that make the magic "there's thousands of developers to help" argument null and void in many situations.
- hdctambien 16y ago
  I think stackoverflow.com pretty much solves all of these problems for you.