
“Don’t Reinvent the Wheel, Use a Framework” They All Say - mogosselin
http://www.mogosselin.com/dont-reinvent-wheel-use-a-framework/
======
doktrin
What I think is missing from most of these discussions is an acknowledgement
that people, in general (including developers), _learn differently_.

In this context : you're either comfortable not knowing, or you're not.

What I mean by this : some of us are comfortable _not knowing_ how X system
works (temporarily, of course). Some of us can start building things with a
web framework and gradually gain understanding from the top down. _This is
OK_.

However, others (and I include myself in this camp), are completionists.
Abstraction is an annoyance, and _not knowing_ is like an itch that needs to
be scratched. For such people, having significant gaps in understanding a
system model is a _real_ problem. Super duper high levels of abstraction is a
_real problem_.

Different people, different learning styles. For any beginner in any field,
it's important to acknowledge how you learn best and then pick a learning
strategy that's compatible.

~~~
Edmond
>However, others (and I include myself in this camp), are completionists.
Abstraction is an annoyance, and not knowing is like an itch that needs to be
scratched.

I think this a common fallacy that many developers fall victim to. Our entire
modern lives consist of using things we don't understand, by this logic you
should also not fly in a modern aircraft because I am sure you don't fully
understand how they work. Better yet, you should refuse to drive your car.

>Super duper high levels of abstraction is a real problem.

Not at all. If an abstraction saves you a ton of time, you should accept it by
all means. If you are your boss whose money is being wasted because someone
refuses to use a time saving abstraction, I am sure that person would not be
your employee for long.

~~~
doktrin
> _refuse to drive your car_

If I were engineering a car or a service tightly integrated with one, I would
be pretty interested in knowing how cars works.

> _If you are your boss whose money is being wasted because someone refuses to
> use a time saving abstraction_

That's a bit out of context, don't you think? The article was making a claim
regarding how _beginners_ should learn web development - not how businesses
should be run.

However, since you bring it up - in my experience misunderstood abstractions
are at the root of many, if not most, security vulnerabilities. Trusting the
system without understanding it is often quite irresponsible.

~~~
Anderkent
>If I were engineering a car or a service tightly integrated with one, I would
be pretty interested in knowing how cars works.

But if you aren't, you don't. If you're building a web application, you're the
delivery driver, not the mechanic. You just need to know how to use the car.

~~~
doktrin
> _If you 're building a web application, you're the delivery driver, not the
> mechanic._

That's a flawed analogy. Delivery drivers aren't responsible for configuring
or providing maintenance on the packages they deliver.

However, this is drifting pretty far out of scope of the original discussion,
which concerned learning strategies for aspiring developers.

While I think it's a good idea to have an understanding of the systems we
build on top of, that's just my opinion. We'll have to agree to disagree.

------
lmm
There seems to be this puritanical view that beginners should always learn a
low-level language because it's good for the soul or something. Which is
bollocks. To take the Java example because I'm more familiar with it, if I
want to develop a simple Web application with a single form in Java, yes I
absolutely do want to install Spring, Spring MVC and Hibernate. If I'm doing
this to learn Java with a view towards using it in larger applications, it
makes sense to learn the stack I'm going to use for those larger applications.
If I'm writing the app for its own sake, those frameworks still let me code
much faster, and in a less error-prone way, than if I were using raw servlets
or something. And what's the cost? A few tens of megabytes of libraries on the
server? Who the hell cares?

~~~
rmrfrmrf
One of my first full PHP projects was a WordPress site. I was very
inexperienced at the time, but I remember being frustrated at the concept of
the Loop, sub-queries, template overrides, and the like. IMO beginners should
work without frameworks so that they know what's part of the language and
what's part of the framework, especially when the framework has its own idioms
and opinions about proper development.

~~~
lmm
That sounds more like a case of a bad framework (and bad language) than an
argument against frameworks in general. Even if you only ever use a language's
standard library, different projects will use different parts of it, so
there's always going to be some new things to learn when switching projects.

Use an environment that matches what you want to learn, and one that promotes
good development practices. But given how much modern programming is
framework-based, that likely means using a framework.

------
girvo
We should be careful not to confuse "frameworks" with "libraries". Two very
different things. The former, yeah I agree that newbies should steer clear of
until they understand what's really going on, and have the knowledge to dig
deep and take advantage of the power those frameworks give you, rather than
using them as a folder setup and "automagic".

I'm currently working on a series of articles (maybe a small ebook, unsure
yet) on developing applications in PHP -- sans frameworks like Zend, Laravel,
Symfony. All those force a way of thinking that is _very_ powerful if you're a
good software engineer and web developer, but allow for a novice to build
things while not learning the "right" way to do it.

So, PHP 5.5, Composer, and Packagist, combined with the PSR4 mean that a
complete novice, and a hardened web dev, can take small composable libraries
and create powerful reusable applications and libraries themselves, with best
practices and great code. It's the anathema to PHPs historical shittyness.
It's how I've been building my current startup. It's the future of PHP web
dev, side by side with those big frameworks for when you need the big guns and
a large team, etc.

It's made developing in PHP awesome, and I never thought I'd say that. Now the
issue is in educating others to give it a try :)

~~~
bowlofpetunias
Not quite.

Frameworks and libraries are two different points along a continuous line (not
even endpoints). Not black and white, just different shades of gray.

I haven't looked at Zend in a long time, but the difference between Zend 1.x
and a pile of libraries was marginal, yet Zend was labelled an "enterprise
grade" framework.

(Not dissing Zend, this was a deliberate design approach.)

~~~
girvo
Symfony, Laravel, they all are done the same way. But in practice, people
create libraries _specific_ to these frameworks, and that's where the issue
lies. Less code reuse, more reinventing the wheel, more security issues as
there are fewer canonical implementations and more scattered libs that may be
ported to your framework of choice, but probably won't be...

We can fix this, though. The best part is, the skills learnt and code written
while doing so are completely transferable and directly usable by the big
frameworks too! So, it's a win-win :)

For what it's worth though, yeah I totally agree with you. It's not an either-
or situation.

------
kfk
Well, take what I say with a grain of salt since I cannot call myself a
programmer, but you can’t mix it all. Take Flask, I mean, who the hell wants
to do url routing? Flask does that for you. Take sqlalchemy, who the hell
wants to create an orm? It’s nice to learn the basics, to understand python
well and to understand web development foundamentals like “salted”/hashed
passwords etc. But don’t tell me I should have started from an even lower
level, at some point you have to throw some abstraction. Maybe a good idea
would be to teach a micro and a macro framework and not just the macro? Or
maybe at the end this is not such a problem anyway?

~~~
cushychicken
Flask and SQLAlchemy were my first thought when reading this guy's take on
"don't learn a framework". Very succinct, simple ways to take the drudgery out
of building a backend.

This guy's article reminds me of the guy who did that "Programming is
Terrible" talk on Youtube, where he was describing an anecdote about the
fellow who decided he'd build everything from scratch because he'd understand
it better. That's kind of dumb - programmers have spent the better part of the
last 50 years solving hard problems to get to the point where we are now. Why
do we have to rehash their hard problems when there are still tons more hard
problems we could be applying ourselves to?

~~~
canistr
Totally agreed.

I started out trying to learn and build using Django but it degenerated into
exactly what the author claimed about automagic frameworks.

I switched to Flask/SqlAlchemy and was able to grasp MVC much quicker. It was
more work to do some stuff, but getting a little lower than Django helped me
learn what was happening in routing/views/controllers/etc. Using SqlAlchemy
meant I could stick within my realm of knowledge with respect to Python
without all the fancy stuff within Django.

~~~
cushychicken
Yes! I started tinkering around with learning web development about a year and
a half ago, and started working through the Django tutorial. I had a hard time
seeing where everything fit, and then I saw a post on /r/Python about Flask,
did the tutorial in half an hour, and never looked back.

> _getting a little lower than Django helped me learn what was happening in
> routing /views/controllers/etc._

Definitely. Armin nailed the degree of abstraction necessary to make MVC
pretty easy while giving you some indirect insight about what's really going
on.

------
codegeek
I look at this in 2 ways. One is "Learning how something really works and
understanding the core" and the other is "Creating production ready
applications with a tested abstract magical tool". Frameworks are great to
create production ready apps in no time even for a novice. But on the other
hand, they have too much magic at times. Take for example, this code in
Python/Django:

    
    
        user = User.objects.create_user('name', 'email', 'pwd')
        user.save()
    

In 2 lines of magical code, we are able to create a user object and make sure
we are able to save it in the database without worrying about a lot of things.
This is great for rapid app building. But what is really happening behind the
scenes ? Do you really understand the flow for user.save(). How would you do
it without this abstraction ? If you don't understand the core, you will never
be able to become a great developer.

So my advice overall is to learn the core by writing stuff from scratch as
much as possible and really understand how things work. Then, pick a framework
and do the same. So even though you will write crappy bad quality code, you
don't need to release that in production. Win-Win here.

~~~
jiggy2011
The problem is how do we define "from scratch", the common definition seems to
be "Whatever I had to do when I started".

Even if you throw out of the ORM and go with writing SQL queries by hand, do
we need to understand how the database will parse the SQL, how it stores the
data on disk and how it executes the query?

The main reason to understand SQL when building a web application is really
that the ORM doesn't provide a full abstraction due to the differences between
the relational model and the OO model. If we could solve that then we could
happily never use SQL again.

~~~
codegeek
Agreed. There is always a limit when it comes to going low level. Yes it
probably is an overkill to understand how a db parses an actual SQL but
helpful to understand how an ORM converts to a SQL query. This is again
contextual. If you are writing your own database, then may be you do want to
understand the parsing. But for web dev, may be not.

~~~
aaronem
> Yes it probably is an overkill to understand how a db parses an actual SQL

Yes, I've thought that, too, but it turns out that, beyond a certain
relatively low level of complexity, that's a great way to produce SQL queries
which take a half hour to complete.

> but helpful to understand how an ORM converts to a SQL query.

Certainly, because there's a degree of complexity beyond which your ORM's
going to start getting pathological and you're going to have to fall back on
querying the database directly, which see point one.

------
danpalmer
I disagree with this article, almost entirely for the list of reasons given
right at the end of it.

Good development practices and project structure, generally good code
examples, fewer bugs and tested code and re-using code are all very important
things in any development, and frameworks all help with that.

If you are starting some of your very first web development, I'd encourage you
to play around with some low level Node.js HTTP stuff, or even write a web
server in another language, to get a feel for how the request/response model,
HTTP header/body sections, etc, all work.

But after that basic introduction, dive into a framework and learn it well.
The projects I know that were developed 'without a framework' are more often
than not poorly structured, poorly documented, and difficult for new
developers to learn their way around, precisely for the reasons given at the
end of the article.

If you evaluate frameworks for your use-case, and realise there isn't one that
suits you well, then by all means, go and make your own, but don't just make
your application - make a framework _for_ your application, and then use the
framework, it will result it much better structure and better software
engineering practice.

~~~
mattgreenrocks
Industry loves frameworks, because it speeds the commoditization of
developers.

> The projects I know that were developed 'without a framework' are more often
> than not poorly structured...

So why not teach developers _how_ to structure code properly? Teach them about
coupling, cohesion, benefits of immutability and layering. Make them feel when
modules should be broken up, and how they should do it. Expose them to
different architecture patterns used in larger applications. This allows
developers to make _better_ decisions about code, both as they write and
refactor it.

It seems that so much of modern day pop-programmer culture is _what_ framework
they should know, rather than _how_ to build/choose the correct framework for
their needs. Perhaps this is yet another triumph of shiny over time-tested
wisdom.

People have been thinking for a long time about how to build large
applications that aren't horrible to maintain. Don't ignore it because kids on
the Internet are excited about ultracool.js.

~~~
collyw
I would like to think that I structure code reasonably well. I also appreciate
that the Django guys have had years more experience than me in web programming
and probabably know things better. They have probably encountered a few
gotchas that I haven't yet.

And is it really nessecary to write all the update / insert queries for my
dayabase?

~~~
mattgreenrocks
It's not about what libraries you use or don't use. (I write Rails from time
to time, one of the most framework-y things in existence.)

It's about an industry that insists on re-learning ancient lessons over and
over again. It believes things like "we don't need design patterns, we have
Ruby!" and "we don't need to choose architecture, we have Rails!" It
constitutes a sort of intellectual deference to That Which Has Been Made And
Agreed Upon to Be Good Enough. Meanwhile, the foundational knowledge becomes
something that is ignored or looked down upon, because it's not shiny.

I want developers who are not afraid to rip up parts of the stack and make
them better if they come up deficient. This requires deep knowledge and
ignoring the rabble of people who insist that you "just use X." How do you
think LLVM started?

------
protonfish
Why is web development is full to bursting with frameworks? It is not because
web applications are inherently flawed. I have been doing web dev for over a
dozen years and understand the basics (semantic HTML/CSS, vanilla JavaScript
and Ajax, the HTTP protocol and SQL) and know first hand that these are solid,
clear and logical tools for building network applications. They don't need
Bootstrap, Knockout, Rails or ORMs. In fact, these frameworks are demonstrable
bad due to:

1\. They remove functionality (developmental power) from their underlying
technologies in exchange for making a few types of features slightly easier.
2\. Their abstractions are leaky - they cannot be used to their fullest
potential without also understanding their underlying technologies. 3\. They
add overhead to a project both in optimal performance and technical debt.

So why does everyone flock to frameworks? My best guess is because of a
failure to have resources available to teach web development beginners the
basic technologies and how they work together to create simple, clear,
powerful network applications.

~~~
anonyfox
Perhaps because all these leaky abstractions help me accomplish a new
project/idea in a matter of hours/days instead of weeks/months. And most of
the time a "just works" is more than enough, high-performance and _perfect_
understanding of every piece in the involved stack is a waste of time when you
have dozens of other projects on your todo-list.

When you finally have a single product that is worth optimizing, then you can
dive into the deep details. But mostly you have dozens of throw-away products
before you get the lucky one.

------
pkorzeniewski
Who cares which language, library, framework, tool etc. are you using? Just
get the job done! There is no "ultimate" solution. Software developers tend to
attach too much importance to tech stack - in most cases it just doesn't
matter, as long as it works.

~~~
TeMPOraL
This attitude leads to a world full of crap, where everything crashes all the
time and is slow like hell, while still costing megadollars.

We don't ask doctors, plumbers or auto mechanics to "just get the job done".
We ask them to do it right.

~~~
snowwrestler
Doctors and auto mechanics routinely use tools and abstractions that they
don't fully understand. (Not sure about plumbers.)

For example how many doctors know how a CAT scan works? They trust that the
machine is doing its job correctly, and focus their expertise on interpreting
the results. And a lot of auto mechanic work today involves reading codes off
the car's electronics and looking up the fix. Do you really think every auto
mechanic understands the full hardware/software stack of all the cars they
fix?

Abstraction is not a problem; it is a productivity multiplier. But only if it
is done right.

The biggest problem with software abstractions these days is that their
quality is so low that they can't be trusted. Imagine if CAT scan machines
were built to the quality standards of Django or RoR. People wouldn't stand
for it.

~~~
jasonwocky
> For example how many doctors know how a CAT scan works?

I don't know. Do you? Or are you just assuming that most of them don't?

~~~
TeMPOraL
My brother just went to study medicine; they didn't get to CAT scans yet, but
from what I saw he's learning about ECG, he is expected to understand the
physics and math behind it on a basic level.

~~~
snowwrestler
Doctors definitely understand how CAT scans work conceptually, to the extent
needed to interpret the results, including whether or not the results are
valid. They don't know, and aren't expected to know, how to build one, or open
one up and fix it.

------
specialk
I disagree with this article almost completely.

Frameworks are great for getting stuff done, which is exactly why I do
recommend them to beginners. Beginners are learning code/a new language for a
reason. Usually that reason is to get stuff done. They don't need to know how
the insides of these frameworks work to do that.

As these beginners progress, as they start getting curious or need, for
example, to know why getting your ORM to count the records in the database is
faster than getting your ORM to pull all the records and counting the number
of records in the array, this is when these beginners need to think about re-
inventing the wheel.

I'm a firm believer in 'you should re-invent the wheel once and once only',
but never ever ever use the wheel you just built. That way you should
understand what a framework or any lower layer of abstraction is doing for
you. Whomever wrote the framework will also most likely have a better solution
that has tested more edge cases than you did, you have less code to maintain
(yay less teechnical debt!) which is why you never use your own wheel. Re-
invent the wheel so you have a better understanding but that's it.

If we keep expecting beginners to understand every level of abstraction that
we have created for them they'd be writing a web-server in assembler, not
solving any of the problems they have, become disinterested and giving up or
never ever ever shipping any of their code ever.

~~~
scarecrowbob
I totally agree.

Practically, it doesn't matter if you start with a framework: work with stuff
long enough and you will either have to figure out the internals of your tools
or you won't. If you do, the you learn, if you don't, it wasn't relevant
anyhow.

------
danso
Yeah, while I support the Learn to Code movement, it is dismaying to see so
much of it focused on frameworks, i.e. basically Ruby on Rails. It's a simple
play for monetary desire, I know, so to tell a novice, "Well, if you get a
strong understanding of Ruby and programming in general, learning Rails is
pretty straightforward"...is just going to confuse and frustrate them because
they've heard about how it's _Rails_ that brings in the money, so why not skip
the middleman (Ruby)?

Web frameworks consist of a lot of things besides pure programming. And these
beginners barely understand programming...hell, they barely understand basic
file systems that don't involve folder icons. And so all of this
stuff...databases, MVC design, object-oriented concepts, dev ops,
debugging...oh, and the entire world of front-end design...is thrown at them
in such a way that there is no way they can decouple what are mostly
orthogonal concepts.

It'd be fine if these beginners couldn't write a optimized SQL query in place
of ActiveRecord...that'd be _perfectly fine_ to work with. But I'm talking
about a much deeper level of confusion. I once worked with a Rails self-
learner and he wanted to throw up a single web page, with a sortable table
that had a trivial number of rows (i.e. the data could all fit on one page
without being cumbersome)...he could not, for the life of him, figure out how
to do that in such a way that didn't involve creating a new Rails project and
deploying it to Heroku.

It's not that I'm against teaching frameworks...it's just that for beginners,
it seems like a very convoluted way to do so, and one that could be very
unproductive in the end.

~~~
collyw
"Web frameworks consist of a lot of things besides pure programming. And these
beginners barely understand programming...hell, they barely understand basic
file systems that don't involve folder icons. And so all of this
stuff...databases, MVC design, object-oriented concepts, dev ops,
debugging...oh, and the entire world of front-end design...is thrown at them
in such a way that there is no way they can decouple what are mostly
orthogonal concepts."

On the other hand, you don't need to use all these things.

When I learned Java, we were told don't worrry about "public static void main"
just now, it will become clearer later. It did. I don't remeber them ever
explianing that line, but explaining all the parts of it at different times.

Likewise, using Django or Rails, I am sure you can have a basic development
server set up, and just let it call your code much like pressing a button
would have done in visual basic in the past. You don't need to overcomplicate
things.

------
cangelis
Framework is a development platform which generally contains tools, libraries
and architectures etc. So you can't say Wordpress is a development platform.
Wordpress is just a CMS, nothing more.

> The problem is to always tell beginners (or let them think this is a good
> idea) to start with a framework / cms because “you shouldn’t reinvent the
> wheel”.

Learning a CMS and Framework are not same. Learning CMS is user stuff, but
learning a framework is a developer stuff.

> When they should use a framework:

> When they need security features (login, session management, etc.). It’s
> often a bad idea for beginners (and even experts) to write code related to
> those areas and use it in a live application. But you still should know the
> language basics.

You can't provide security by learning a language basics. You should read
books, articles about web security (independent to the language)

> 1\. Customization can be difficult in complex code.

> Take for instance Liferay. Liferay is a big web development platform. If you
> want to start a membership site...

Your example is not a framework.

> 2\. Debugging is usually more difficult when using frameworks.

> Frameworks are good at throwing unreadable meaningless errors.

Are you sure you have used a framework before ?

tl;dr Framework and CMS (or portal) are not same stuff.

~~~
mogosselin
Well, the goal of the post was to also demonstrate that frameworks, libraries
and web development platforms are often called "Frameworks", which they are
not.

------
pekk
Most people starting without a framework are going to make a bunch of errors,
which is OK up to the point where they are collecting cash for work which is
broken or fragile. It's definitely not OK when their app contains other
people's data and they are writing all kinds of security bugs they didn't even
imagine possible.

------
jpswade
If your mother wanted to make her own website, what would you advise her?

Would you tell her to learn HTML, CSS, PHP and Javascript from scratch or
would you recommend Wordpress?

~~~
hluska
That would depend on why my Mom wanted to build a website.

If my Mom wanted her own website because she wanted a place to share her
writing, or some photos, I'd suggest that she install Wordpress, find a free
theme and work with it until her site is set up how she wants it (or just give
up and invite me over to help).

On the other hand, if my Mom wanted to build a website because she was
interested in learning how to develop web applications, I'd likely have to
start her off with HTML and CSS (then introduce Javascript once HTML/CSS sink
in). When my Mom really wants to learn something (especially something
technical), she needs to see how all the component parts are actually built so
that she has a full understanding. A full understanding of the smallest
components makes it easier for her to understand bigger concepts. When it
comes to web development, understanding how a document full of angle brackets
can render as a web page would make everything else fall into place.

To complicate things, if my Dad wanted to learn how to develop web
applications, making him start at HTML/CSS/Javascript would almost guarantee
failure. My Dad operates best when you throw him in the deep end. He would do
best if he downloaded an open source Rails project, figured out why it does
what it does, and then modified it to do something different.

I struggle when it comes to the why. My Dad is extremely mechanical and he was
a police officer. Perhaps working with a police force caused him to look at
events as a byproduct of an entire system? Or, maybe this is straight up
nature and his brain is just built differently? Or, maybe his parents did
something in his first few years of life?

------
coreymgilmore
I agree. I think you should start with basic HTML/CSS/JS. Otherwise you will
never learn the basics and figure out what/how the frameworks actually work.

Take Bootstrap for example. A beginner starting with frameworks might think:
"Cool, if I add class this and class that, I get styling and layout". When in
reality you need to know that class name means nothing, it is the CSS in the
back that is doing everything.

Start basic, otherwise you will never know how exactly the frameworks work.
Plus, you will never be able to write your own frameworks/libraries/code since
you didn't learn it!

PS: The answer "just use a framework" = add a whole new file to use 10 lines
of code and bloat your website with extra files and slow load times.

------
gabemart
I don't think the article does a terribly good job of arguing the point, but I
agree with the thesis in so far as it applies to my very limited experience.

I made A Soft Murmur [1] without ever having written a line of code before.
(There are literally comments in the code like "oh, so that's what an array
is".) I originally planned to use jplayer [2] for the audio because I believed
it had very good cross platform support. But after I dug down deeper (and
wasted quite a bit of time), I discovered that for what I actually wanted to
do (control multiple audio streams from the same set of controls), jplayer had
poor cross-platform support: for example, on iOS every audio stream has to be
started by a user action, so it's not possible to play multiple streams by
tapping once. There were a number of problems like this. The issue was,
because I was so much of a novice, I didn't know how to assess jplayer's
limitations to the degree that a more experienced developer would have before
choosing to use it.

Similarly, I used jQuery Mobile [3] to create mobile-friendly sliders for
audio volume control, but then spent a long time working out to disable all
the other things jQuery Mobile does by default.

I ended up using raw HTML5 audio elements, and I kind of wish that I'd
implemented the sliders and the rest of the controls in vanilla js rather than
jQuery and jQuery Mobile. I would have learned more. As it is, my
understanding of what jQuery actually offers is hazy because I'm unsure about
how much I could have done without it.

My takeaway is that until you know the basics of a language, you can't tell
what tools you need or the limitations the tools you chose will impose on you.
I think it's far better for beginners to start using the absolute minimum set
of tools (in my case, hand-coded HTML, CSS and JS) and then add more complex
tools when one encounters a problem one can't solve with what one already has,
or to optimize something one already knows how to do.

[1] [http://asoftmurmur.com](http://asoftmurmur.com)

[2] [http://jplayer.org/](http://jplayer.org/)

[3] [http://jquerymobile.com/](http://jquerymobile.com/)

------
jiggy2011
If you write without a framework and you want to create robust programs,
you're going to spend a lot of your time learning to deal with deficiencies of
the web which you wouldn't have to worry about if you were learning native
mobile or desktop development.

Do we really want to force people into learning how to wrangle strings from an
<input> field into valid dates or how to manually CSRF proof their forms to do
basic web-dev?

~~~
mogosselin
Well I think that a beginner should try to do this by hand at first. Not
necessarily in a production application, but to learn how it works.

The difference between Web development and desktop development is the HTTP
protocol which is responsible for security issues and other behaviors
(sessions, cookies) that you need to understand if you want to build solid
applications.

Just the difference between client and server side validation is often not
understood by beginners, which is a big problem.

If somebody rely on the framework to do all the job, he's going to have
security issues in his applications and other weird behaviors (double submit
when refreshing a page, etc.)

~~~
jiggy2011
If somebody wanted to learn Desktop GUI programming we wouldn't usually tell
them to learn the low level APIs for drawing rectangles on the screen or
manually handling keyboard input, we would point them to a framework and
widget toolkit for the platform.

The point of a good framework should be to pave over the cracks like double
submit bugs, since they are not really things than anybody should be wasting
brain cells on.

~~~
mogosselin
I disagree on that point. Web development is not the same as Desktop dev.
Because HTTP is something you should know if you want to code solid and secure
Web applications. If you don't know how it works, you'll end up with forms
validated only with JavaScript, double submit because people are loading
pages, etc.

------
al2o3cr
Eagerly awaiting the 2016 HN top article, "Stop Telling Development Beginners
To Use An Operating System, Thanks". Make your own lightsaber, kidz!

~~~
mogosselin
lol! you didn't code your own OS? ;)

------
westurner
1\. WordPress is an application with a plugin API. It is not a framework.

2\. Writing a web application without a framework is a good learning
experience. For anything but small-scale local learning experiences, the risks
and costs of not working with a framework are significant. [It is probable
that I, with my ego, would "do it wrong" and that a community of developers
has arrived at a far superior solution.]

One of the best explanations for what advantages a framework offers over
basically just writing your own framework I've found is in the Symfony2 Book:
"Symfony2 versus Flat PHP". [1]

[1]
[http://symfony.com/doc/current/book/from_flat_php_to_symfony...](http://symfony.com/doc/current/book/from_flat_php_to_symfony2.html)

------
badman_ting
Arguing about frameworks is getting incredibly old.

~~~
NAFV_P
Totally agree, I would rather have heated arguments about error handling and
unrolled loops.

~~~
badman_ting
Variety is the spice of life!

------
jayvanguard
I agree with the sentiment but not with his categorizations. For me, a library
is something you call that does not impose an overall structure or set of
processes on your code. You call it and control it while a framework calls you
and imposes flow and structure on your code.

This is why frameworks aren't great for beginners to learn on. So many
decisions are taken a way from them they don't gain an understanding of what
is really happening.

jQuery is a DSL which makes it a bit tougher to categorize. You can use it as
a library, but in general it will end up taking over more of your application
structure and flow control if you use it well.

------
xyzzy123
So the other issue with not using a framework is security.

Modern frameworks have a level of built-in mitigation for the common stuff
like XSS, SQLi and CSRF and so on.

The problem is that most developers don't even understand all the things their
framework is doing for them.

Non-trivial PHP code written without the aid of a framework is a great morale
booster for penetration testers.

------
sudomal
I can fully appreciate this. Abstraction takes the fun (or spark) out of
programming, all we really do these days as developers is glue framework
components together.

~~~
ben336
Unless you're programming in Binary or manipulating the hardware directly,
every programming task is built on layers of abstraction. You just have to
decide what level is best for you and the project you're working on.

------
lo_fye
They should _write_ a framework. You learn a lot that way, and it helps you
determine what you need from a good framework in future.

