Todo-MVP: Or 'Why You Shouldn't Use A Web Framework' - The Revenge

David Wickes on November 26, 2018

Earlier this year I wrote: Why You Shouldn't Use A Web Framework David Wickes ・ Jul 26 '18 ・ 4 min re... [Read Full]
markdown guide
 

I think you've got some really good ideas about a few things, and you've also missed (or not yet come to see) the problems that frameworks solve.

Writing everything from scratch is a great way to learn how things work. Maybe you want to understand what really goes on during the request-response lifecycle, or you want to write raw SQL queries instead of using a heavy ORM. The understanding that you get from doing this is super valuable, and every developer should certainly do it on some level. Also, because you have a deeper understanding of a concept it lets you debug other people's code more easily.

I think there are more and bigger downsides to writing everything from scratch though.

Writing from scratch is reinventing the wheel. Sure, you might come up with a better way to do it (maybe, but I probably won't, and definitely not the first time I do it). But practically every web application has a need to send requests and handle responses, and communicate with a database in some way or another.

Because these tasks are so common, people have written code to do the work for them. They have developed methods of dealing with them. You can think about the tasks as "problems" - they're things that need to get done in order for your application to work.

Using someone else's solution to handle requests and database queries just means that you're going to focus on solving different problems. The ones that your application has specific needs for, whatever that might be.

Learning how to solve these problems is valuable, but once you've built many applications, you may be tired of solving the same problems over and over again. This is why frameworks were developed.

Various frameworks might solve the same problems in different ways, but ultimately they do it so that you don't have to. Yes, you're limited to the choices the framework authors made, but in many cases that's okay because you're focusing on solving other problems. Yes, you have to learn how that framework solves those problems, but that's true every time you use code that you didn't write.

The main advantage I see to frameworks is standardization. this matters on bigger teams. You can hire someone that says "I know django and angular" and they can be productive on your project because they've already been exposed to the patterns that django and angular apps follow. They don't have to learn any new paradigms, they only have to learn your project's specific business logic.

I would also argue that frameworks (generally) scale better - not necessarily in terms of performance, but definitely when talking about code organization and design patterns. Having iterated and developed standards over time helps with this a ton. Working on a gigantic rails project is tough (though manageable), but working on a gigantic custom framework involves much more cognitive overhead, especially early on.

Anyway, no matter what you use, you're going to be solving problems. Which ones do you want to spend your time on?

 

Just about everything you're referring to is theoretical. It just doesn't work out in practice. Frameworks only have a small niche in which they're beneficial. In over a decade of programming, having made frameworks, used around a dozen, fixed many, modified many and have seen well over a hundred projects using frameworks I can conclusively say, they just don't work out 90% of the time minimum. Most of the time they're not necessary and are complete overkill.

This is what I've learned to come to expect from a project using a framework (the larger the framework the more so these things are....

Frameworks give you more to do, they reduce standardisation, they significantly degrade performance, they reduce maintainability, they reduce collaboration, they reduce testability, they reduce buildability, they reduce readability, they reduce debugability, they reduce reliability, they increase bugs, they increase the amount of code you need to write, they reduce developer quality, they inhibit learning, they reduce deployability, scale poorly, cognitive load increases, upgradability is inhibited by frameworks, reusability drops, compatibility drops, security is reduced by frameworks, they reduce interoperability, they increase the time it takes to do things, they increase complexity, they reduce configurability, they reduce organisation, etc.

Not a single claimed benefit of frameworks works out in reality even half the time. This isn't a discussion. I'm not talking about theory, I'm telling you the facts. If you go any sample what actually happens in reality that's what you'll get.

There are ample reasons for it and probably not a reason with a significant majority though one reason that stands out is that first and foremost the developer must be able to deliver all of the above and if they're relying on their framework to do it by magic then it'll never happen. It's a myth that a framework will solve all your problems. You have to solve your problems. Using a framework will likely just make things worse if it's on blind faith.

Frameworks causing a deficit in all those areas might be surprising at first but less so when you think about it in the sense that they introduce so much complexity it tends to completely overwhelm developers. Most of whom are afraid of the initial complexity then to solve that unwittingly include ten times more complexity and tend times more to contend with. Superficially and psychologically they might feel better but without a point of comparison they lack the ability to weigh up the additional cognitive cost or to realise that they're so over loaded that everything suffers. There's also a simple fact that frameworks often actually aren't that well written, documented and complicate things by trying to cater to every way of doing things and every use case including the most extreme and complex cases.

In often cases frameworks just give you more to worry about. Frameworks are like inventing a whole new set of languages. You start off having to worry about javascript or PHP and their common libraries or the specific libraries you need for you task. Before long with a framework those things have not only gone away but you also now have to worry about all the additional little languages the frameworks have introduced or created such as typescript, twig, yaml, extensions to HTML, all manner of code to configuration, etc so now basically you've gone from a few things to a dozen things. First you had five problems, now you've got ten problems. As in first you had to learn five things, now you have to learn a hundred, well done.

In terms of being poorly documented, while MDN and the PHP manual really blow a lot of things out of the water (language references tend to end up being quite good), framework documentation tends to be very poor which isn't surprising given just how large many tend to become. It's also a substantial myth that framework developers are better than you. They immediately are not because they do not know in a given point of time your specific requirements, they're not in your shoes, they don't know what you need and what you don't need. Further more they're not actually guaranteed to be good developers, they're only guaranteed to have time to make and share code. Library and framework code, even languages are deficient on multiple fronts all of the time. There's barely a language, framework or library I've used that hasn't had problems on some level including code quality and reusability.

"writing everything from scratch" is something you really need to qualify. I just "wrote everything from scratch" this week. How long does it take to write "everything"? About one or two days. In reality at least for PHP the average application only needs around 100 to 5000 lines of framework. That takes about an hour to month to write, however you don't have to do it all at once, just when you need. Basically you can expect the proportion of framework dev to business logic dev to drop off significantly from the start of building an application. Realistically custom frameworks tend to want to weigh in at around 500 to 1500 lines base on typical project sizes.

Given that's the case, it makes no sense to try to save writing 500 to 1500 or even 5000 lines of code by introducing a million lines of code framework which is a huge amount of additional complexity to maintain. In reality, you're going to spend as much time with your own framework as you are with any other in terms of time spent solely on that. For very small projects you might see a different but anything going for a quarter, six months and definitely a year you'll not receive a benefit from frameworks. If you're doing more lines than that then you're probably doing something more than writing your required framework. When you consider how large frameworks often are compared to the required framework then that should raise some questions.

A lot of people look at a million line framework and think that's how much they have to do. More worryingly, they think that's how much they save. That's not even a framework. That's an inner platform. It wont save you a million lines. In fact you're likely to have to end up writing more to cater to the framework making you have to do things you don't have to do.

"They don't have to learn any new paradigms", really, how long does that take? You're concentrating on the 1% to a few percent at best while ignoring the other 99%. This is the difference between theory and practice. In practice you actually have to quantify these things, it's not just more or less. No one in their right mind would scoff at the concept of making things twice as better 95% or more of the time at the expense of making things twice as worse 5% of the time. I smell here a case of this is not your real problem. You real problem is fear of not being permitted the lead time to get up to speed. That's the real problem we need to look at here and that's where we need to influence the industry towards reasonable expectations, influencing the industry to make frameworks mandatory is not a reasonable expectation nor does it really do anything to really address the root of the problem, in most cases it backfires.

Personally, I hope people continue overusing frameworks as it gives me a huge competitive edge being able to take the efficient path and far more superior path of not using them but the better part of me doesn't want this horror to be inflicted on anyone.

I'm going to conclude this with, I've seen frameworks kill businesses. When they are killed for other reasons, it's because of bad developers. Frameworks don't fix that but often people like to blame that being absent instead rather than blaming people for obvious psychological reasons.

 

Interesting stuff.

How have frameworks managed to kill businesses? was it due to having to refactor the code sitting under them to a new version?

Let me tell you my story.

I work for an online school and 3 attempts were made to rewrite the entire learning management system into symfony, codeigniter, and then laravel. The LMS was written in old school PHP 3 code that had just barely made it's way into 5.2 compatibility. The structure of the site was a loose set of scripts with a few global libraries and no object oriented stuff, relied on input globals, etc.

The codeigniter attempt had 2 super huge controllers but implemented at least 75% of the functionality before a wall was hit with that approach.

The laravel attempt only got 15% of the way there before the programmer gave up.

I got my job maintaining this legacy application and throughout the course of 1 year, refactored it to be compatible with 7.2 and beyond. Only until recently has it seen any object oriented code, which was just an experiment.

The other programmers sold the company on a rewrite by touting the benefits of these frameworks. Last time, the owner was told that we Laravel was great because it could do caching, easy APIs, database abstraction, and had an admin panel addon that would make redoing the backend easy.

None of this stuff materialized and the refactored LMS is running on a 1GB mem amazon instance without caching because it's written more like a C program and has the performance to match.

The laravel backend plugin was horribly buggy and crashy; but that might have been because we had a crap programmer. 100% of the laravel code was written off as a loss, because none of it could be used in the old system - it was too dependent on laravel.

I do wonder if the intense layering of abstractions and the scattering of tiny objects that have maybe 1 or two methods, adding up to 1000's of objects, is even comprehendable to the programmers trying to follow that ideologies.

I tried asking a SOLID devotee writing some popular upcoming forum software how he managed to trace execution in his program and he could not provide me with an answer..

I think a lot of people have these experiences in the business but it's a bit weird that it's opposite to how things like news works. People seem to be very motivated to dish out good news about frameworks but none of the bad news.

I think the people without the time on their hands and that have to actually deal with these problems don't have the time or energy afterwards to then blog about it.

An immediate problem with frameworks is that they want to solve complexity with complexity and if someone can't handle the initial level of complexity nothing will be achieved adding even more.

This might be deceptive as from certain angles frameworks look as if or give the impression as if they simplify things. Somethings with tricks like here's one we made earlier. It's all very well until you want something that's not exactly that.

After sometime between PHP 5.1 and PHP 5.3, frameworks have really never solved any problems, only good developers have. Before that as you go back PHP was increasingly limited and in some cases you might say well maybe there's a little scope. I think they also have some scope in some areas that aren't quite mission critical and can afford a little sloppiness (IE, it just needs to work) that frameworks can empower.

It's a bad but common assumption that frameworks are well written and that the coder can't do better. It's also a bad assumption that frameworks can either contain or enhance a bad developer. A huge complex Gordian knot of a framework is only going to give a bad developer more rope.

without caching because it's written more like a C program and has the performance to match.

That's a story of my life. So often people just try to add another layer which is a problem with frameworks. Often the problem is deeper down and with frameworks the only way is up.

Most SOLID devotees don't understand SOLID. Prematurely inverting dependencies with interfaces and minimising the need for modification relying on extension instead is for public libraries like the Java library where the code is meant to be distributed to millions of people with every possible conceivable use case.

That doesn't need to be strictly applied to a mutable internal codebase. SOLID has also become a fad today, replacing OOP with an over the top militant if it's not following the most extreme all the things rules then it's not good, even if that means prematurely optimising for flexibility when there's no latency doing things on demand resulting in over half your code being unneeded.

The people adhering to these things are psychologically messed up. They want to be superior and that's it really but the fact is they either lack the benefit of intellect or programming experience. Not everyone is like that but for those starting at the bottom, who really want to start at the top, it really brings that nature out of them.

The JS environment has become a bit weird like that (functional programming maniacs send me up the wall) although I tend to worry a bit less as you can often more easily toss out a JS front end and replace it either wholesale or bit by bit. Backends tend to have critical datapaths shunted through then rather than being terminators. Basically, they're in the middle, stuff interdepends on them. It'll be more interesting when JS backends start to become more established though saying that webpack and gulp are a joke and are now pretty much a must have.

I'd just like to say @joeyhub and @theelectricdave that these are some quality comments that I've really enjoyed reading. Thanks!

Especially

Frameworks give you more to do, they reduce standardisation, they significantly degrade performance, they reduce maintainability, they reduce collaboration, they reduce testability, they reduce buildability, they reduce readability, they reduce debugability, they reduce reliability, they increase bugs, they increase the amount of code you need to write, they reduce developer quality, they inhibit learning, they reduce deployability, scale poorly, cognitive load increases, upgradability is inhibited by frameworks, reusability drops, compatibility drops, security is reduced by frameworks, they reduce interoperability, they increase the time it takes to do things, they increase complexity, they reduce configurability, they reduce organisation, etc.

I mean, this is brilliantly put.

I saw Ward Cunningham tweet this:

I feel the same way about frameworks and DSLs - they're designed to negate my generic programming skills and mentality.

You're welcome. I'm glad someone gets it. I've been afraid to even speak my mind on this topic because there is so much freaking resistance to not following php-fig dogma and object oriented fetishism.. It was reading joey's comments and noticing that he didn't get mauled that made me join.

It's a bad but common assumption that frameworks are well written and that the coder can't do better. It's also a bad assumption that frameworks can either contain or enhance a bad developer. A huge complex Gordian knot of a framework is only going to give a bad developer more rope.

This is the thing that sticks to me the most. Having had developed my own framework, i have a yardstick to measure other frameworks by, and they pretty much all fail to stack up to some of the pretty basic function libraries i've put together, in terms of how difficult the syntax is to type, how fast they perform, etc.

( the only framework i found respect for in this regard is the fat free framework )

I always come back wondering who finds these solutions acceptable.
A simple database call in laravel or symfony is about 3 times more complex than i'd like.

Perhaps these frameworks provide acceptable solutions for people who do not know better and are just average programmers. In this case, it might be better for them to be using someone else's solution.

With the code camps churning out hundreds of new programmers per day, i think the framework popularity will only continue over time. This may result in another phase of poorly written, unmaintainable php code - except this time, you also get to figure out what automagic is happening when you try to debug that mess after the original programmer hit a wall and walked away from / failed to complete the project..

 

Writing from scratch is reinventing the wheel.

If I want to correct one idea in this it's the idea that not using a framework means that I'll be reinventing the wheel. A lot of what you say about avoiding the duplication of effort applies to libraries. I like libraries. But why don't I like frameworks?

Use libraries so you're not 'reinventing the wheel' of HTTP message parsing. Maybe you'll use an ORM library to manage your database. Maybe you'll use a thin wrapper over SQL. But if you've abstracted the persistence layer correctly then you'll be able to change your mind depending on your needs and not the capability of the framework.

 

I agree that's true if you have the need to change things like that later. But in my experience, you have to go incredibly far down the road or have really extreme/specialized needs to not be satisfied with an off-the-shelf solution.

Your TODO-MVP has several good examples of how you can do some of these things with little code. I will posit an alternative - you can save yourself a ton of time by using a framework. You'll end up with more total code (maybe), but you'll also have more time to focus on other things.

You seem to be ignoring the time it can take to determine how a framework wants you to solve a given problem. We've spent considerable time on a CakePHP project trying to find the "right way" to solve a handful of problems which could have been solved with vanilla PHP in an hour.

 

I think the "Vanilla JS" approach shouldn't even use any backend. The way you've set up the projects with the backends feel very reminiscent of 90s stuff where every action you took was sent and the page refreshed (I haven't run the code, so I can't say, but that was from reading the Node.js code). Having a global array storing the files, or even manipulating localStorage would be a 100x better way to compare this code to other frameworks.

Just some thoughts from glancing at the project.

 

Yes. That's exactly right. You will be redirected after an action and will see a new page.

So what? What does it miss in terms of the requirements of a todo-style application?

Having a global array storing the files, or even manipulating localStorage would be a 100x better way to compare this code to other frameworks.

Sounds like you're after a frontend only implementation - this project is explicitly avoiding frontend JS. Can I direct you towards the very worthy vanilla implementations on TodoMVC.

very reminiscent of 90s stuff

You make it sound like a bad thing...

 

I checked the vanilla js TodoMVC... and I don't like it. Too much code for problems solved hundreds of times. Take for example the template:

    function Template() {
        this.defaultTemplate
        =   '<li data-id="{{id}}" class="{{completed}}">'
        +       '<div class="view">'
        +           '<input class="toggle" type="checkbox" {{checked}}>'
        +           '<label>{{title}}</label>'
        +           '<button class="destroy"></button>'
        +       '</div>'
        +   '</li>';
    }

And then using string operations the app is replacing values:

            template = template.replace('{{id}}', data[i].id);
            template = template.replace('{{title}}', escape(data[i].title));

So much code... and the more you write the more bugs you may have... this is exactly what we all are trying to avoid - reinventing the wheel again and again.

 

Yes, it is. Networking eats time. Worse, the user experience is quite annoying on bad and unstable connections. Any smooth UX is doomed for people who is acessing the page from another half of the planet.

But not every site strive for smooth UI experiences for their users, which is ok.

Why are you asserting that you cannot have a "smooth UX" with this approach. What is not smooth about how it works now?

I'll tell you what isn't smooth, downloading megs of javascript and executing it on a low power device.

Because I was using 90xx web.

Page refresh doesn't happen fast enough as background interactions and rendering result as it arrives. This implies SOME logic on a client.

This is specifically true for remote sites. You will have at best speed of light delay before retrieving content. In worst case network fluctuations might give very annoying delay just to get new content. Yes, and you customer will be staring at WHITE page, because browser viewport have nothing to render.

This is why I am so assertive.
If you don't like it, fine - learn your way ;)

Modern browsers smart enough to cache your megs once and then transmit pure json back and forth, reducing overall need for bandwidth. Plus it happens behind the scene, so customer might enjoy that spinner animation or enjoy previously loaded content.

You can definitely (and should totally) not bundle and serve megs of Javascripts with each page but cherry pick for each necessity; and we also did invent SSR so you can for sure not show a white page on first load. You can do animations with CSS and handle DOM changes with a library like Preact which is like a handful of kilobytes, and still use plenty of vanilla JavaScript so you keep it fast and lean; even adopt stuff like Tachyons or FontAwesome if you want to ship something professional looking. All of this doesn't require megs and megs, just common sense and some tools made by awesome people you can find around.

Sure you could do it backwards and do it the good old fashioned way of "I click, it reloads", but then when the server will be slow or even go 504 users will complain it's slow and unreliable, while you could've used AJAX (which we've been doing for a looooong while now) and provided helpful, human readable status messages without sending your users out or even losing their work because your API aren't reliable.

You can also do both, use server side templating and use JS to augment the website and cache.

Basically what dev.to is doing and being pretty fast at it too.

There's no single way to build a website anymore and that's great for everyone, yeah the complexity of frontend programming is escalating, but there is a lot of innovation going on at the same time

 

Oh, I'm sorry, I misunderstood the scope of the project then.

You make it sound like a bad thing...

Well as a pure UX standpoint it's very bad as doing anything will prevent use interaction until the state is synced with the server. It's like the AJAX "spinner apps", although those already used client side JS... So admittedly more modern than this 😜

But as a To-do MVP example it is an area where the was none before - and maybe I can contribute with a Django or a Flask app some time!

I'd love to see a Django / Flask / Python pull request from you into Todo-MVP (I'm not very experienced with Python). Please let me know if I can help in any way!

 

A thoroughly interested read. It's nice to stand back every now and then and ask "why am I doing it this way?" Usually the answers are terrifying "we've always done it this way" or "it made sense at the time". I'm totally for a proportional solution. Why build a rocket when you're only going to the supermarket?

 

We haven't always done it this way. We do it this way because we tried the way he's suggesting for years and it was proven hands down to be slower, more expensive, less secure, and infinitely harder to add new head count into...

 

Citation very much needed here.

Again people keep pretending that David and others are somehow not productive by not using a framework. You keep saying it but the evidence in his eyes (and my own) say otherwise.

I dont use a framework for the current project and i am very productive. I see another team using Spring, and they tie themselves in knots constantly trying to understand the damn thing. Who is productive again?

Writing new code is ALWAYS slower than not writing it.

How many people knows Spring?

How many people knows your solution? Only you? Ten?

If you are writing code for money, you should know it is not about your productivity. It is about productivity of people, who would support your product after you.

Usually frameworks wins due to popularity... and it is their core purpose.

There are bad frameworks.
There are misused applications of a framework.

I guess not your one arbitrary ad hoc example team. I work in a company with thousands of engineers and I've worked on teams as small as two and everything in between. I can cite dozens of ad hoc examples as well, but I'll go ahead and point to any job board and the percentage of jobs that state "We want you to not use a framework to work on this project." Any Fermi estimates of how many you're gonna find? I'll go with Zero. The industry runs on frameworks because they work and work well for 99% of what we do in real life every day. Can I think of some situations where a framework would be a detriment? Yes. Can I think of ways to cherry pick libraries to solve those edge case architectures? Yes. Does that matter for the vast majority of bog standard web apps that the vast majority of us churn out week to week? Hell no. Perfectly good frameworks in the wild today remove boilerplate, provide tons of affordances, have solid communities, and make it easier to focus on your use case specific code. Not to mention being able to hire new headcount that can be up and running on real work with very little onboarding. That's why they're used, as many have stated. The difference between you and me is not that either of us can or can't use frameworks to build applications, it's that one of us is on an esoteric quest an the other has better things to do than fiddle with library curation. If your article said, "I know frameworks are super useful but here's some use cases where you should consider not using them and here's how you'd go about it" you wouldn't be receiving all this flack in the comments. Your "This way or the highway because straw man imaginary problems" is why people are crapping all over it.

The difference between you and me is not that either of us can or can't use frameworks to build applications, it's that one of us is on an esoteric quest an the other has better things to do than fiddle with library curation

Actually I'd just rather not have to learn how to use a new framework every couple of years because that's what happens to all of them. I have better things to do than learn some other person's idea of how a web app should be built when in essence all i really need is

main function, start server, with router, routes mapped to controllers... job done.

The fact you are strawman-ing the argument in terms of being "esoteric" is pretty sad.

Re job ads, find any Go jobs with a framework and come back to me. All the job ads I look at in my area dont specify frameworks at all, shrug. They usually just look for good engineers with some familiarity with particular programming languages.

So you're building static sites? Because you haven't listed Auth, Storage, Caching, Queues, Jobs, Search, Web Sockets, API, templating, DI, or any other number of things that are used quite frequently if not 100% of the time on the apps I'm building every day. Your "Job Done" looks a helluva lot different than my "Job Done". And if that's your use case fine, but don't try to pretend that that's common. That's all choices that I can either take the time to make myself and then explain to dozens or hundreds of other people, or I can just say, "Here's the standard way the framework has chosen to solve for it, learn it once and use it for the next 100 apps you spin up. If you run into an edge case we'll flip out the stock solve for something that works for that." You make some super weird arguments my friend...

Chris, Rails has been around for 12 years. I think the first version I used was 3 something, we're almost at 6. It's essentially the same thing.

I think JS frameworks deserve a bit of your distaste but most server side frameworks don't change that fast.

There would be riots if they did.

So you're building static sites? Because you haven't listed Auth, Storage, Caching, Queues, Jobs, Search, Web Sockets, API, templating, DI

All covered by libraries, if and when i need them.

Apart from DI, you dont need libraries for DI (although things like frameworks will trick you into thinking you do)

Chris, Rails has been around for 12 years.

This is a fair point.

I would still contend the overall tone of it being wasteful/impossible to build non-trivial applications without frameworks is bordering on absurd.

Look at most Go projects, you wont find any frameworks there. How are people making "real" things with Go?

I think you conflated two separate answers by two different people 😬

I think both camps have valid points but I've only seen one or two people talking about the value of frameworks in equalizing the developer experience between different levels of skills or in companies with high turnover.

I don't think you always need a framework but I don't also think you never do.

Yes I was trying to reply to both with the quotes but maybe the UX of this site didnt expect such a nested flamewar ;)

I don't think you always need a framework but I don't also think you never do.

I dont disagree at all. I feel like the main point of this post is that it shouldn't be the default position that you do.

I can hire a mid level developer and outsource the cost of teaching them the parts of my code that are just infrastructure and focus on the actual application exactly because I know that they know where the code is put.

How can I outsource that? By using a framework and make sure they actually know it when interviewing.

Could a good developer be brought up to speed in a frameworkless environment? Sure.

Will it always happen? Nope. I've seen the horror of multi year apps written "just with PHP" (I was hired to rewrite it in Django exactly because nobody knew how it worked and they just kept it there as legacy).

It really depends on the people in this framework less space. You guys are capable developers and made a sensible choice.

As a freelancer I came across small agencies with developers with variable levels of skills with unmaintanable apps using a framework. They would have had unmaintanable apps nonetheless without such framework. The difference is that the new set of eyes (me in that case) was able to just focus on the spaghetti app code, not also the spaghetti infrastructure code.

My personal experience of growing big with a framework is that you ultimately will end up just using it as a layer between your logic and HTML, the more your skills improve.

Something like

def action
  # call my business logic, ok bye
  # return some HTML
end

I don't see the big difference in the case of a well experienced developer like you are.

My favorite framework is Flask because it just does the boring parts of web apps and can be plugged with functionality pretty easily. Also has a neat concept called blueprints that allows you to put controllers wherever you want

Not if the code you are re-using is not fit for purpose.

Or if it forces you down roads that are not necessary.

Plus almost every framework that has any kind of popularity has books, books written about them. Does that not tell you there is a big cost to using them, at least in terms of understanding them.

 

I think you should differentiate opinion and facts, the most reason framework are used is for good common standards that is hard to get as solo developer something like security stuff, I think if you are creating a simple toy app then that is cool as you can kill anytime.

 

That's your opinion. I happen to know as a fact that (a) I am employed, and (b) I am not using a framework when I build my applications. I do use a number of very nice libraries however.

If you're using a framework to enforce an architecture or code standards then that's a terrible way to avoid talking to your colleagues to reach an agreement on those (mostly bikeshed) issues.

'Security stuff' can usually be handled by either a library, or if you're worried about user data can be outsourced to another identity service.

And, please, although these examples are certainly toys, the idea that anything built without using a framework is a toy is ludicrous. 'Industry standard' and 'best practice' are often just ways of excusing a failure to think for yourself.

 

"often just ways of excusing a failure to think for yourself"

This is a very good thing!

Otherwise, you have to spend years of studying to do anything of significance. Or if you want to go into an area you haven't studied before, frameworks make it easier to do this.

So yes "think for yourself" but not all the time because you'll get less done.

I would hate to see a world without frameworks because the barrier to programming something useful would be higher and deter people from entering the field.

I would hate to see a world without frameworks because the barrier to programming something useful would be higher and deter people from entering the field.

I feel its the opposite and youre maybe missing the point of the post.

In my view, the barrier to entry of programming looks worse than it is because of frameworks.

Look at the code Dave posted. It's not complicated or hard. The point he is making is the barrier to entry is already low, if you look past the hype of FOTM frameworks and just study the basics.

It's just there is a perception that you cant do something "real" unless there's a framework. Learning frameworks is so much harder than learning the fundamentals.

I agree you can do a lot without a framework. But you can do something more "professional" with a framework faster at least initially. To get to that uncomplicated code probably took years of experience. Most people even if they know the basics write bad code and it takes years to make it good and uncomplicated. A framework at least guides you along until your good enough to do those on your own. The real problem comes when trying to throw away the framework when you don't need it any more.

Abstractions are hard to get right. And an abstraction that has been vetted by a community and implemented in code is hard to beat.

Abstractions are hard to get right

Too right they are! Abstracting away a database - awesome. Abstracting away the underlying bytes of an HTTP response - I'm a fan.

But what does, say, Angular abstract? What is the underlying entity that is abstracted by Ruby on Rails?

In my opinion, they are not abstractions at all. They're tarballs of multiple abstractions, an attempt to generalize certain business requirements. I think you'll get so far with this, but in the end (as you rightly say):

The real problem comes when trying to throw away the framework when you don't need it any more.

I would love to see a discussion about what frameworks have a good off ramp when you have out grown them. Do they exist? Or what are some techniques to do so? Or which frameworks are the most flexible and let you interchange the pieces?

I would love to see a discussion about what frameworks have a good off ramp when you have out grown them.

Now that is a great question. I think you could dip your toes by Googling 'How I migrated Angular to React' to get some idea.

 

I am not sure of who said that "the idea that anything built without using a framework is a toy is ludicrous". Even if someone did though, saying that "one shouldn't use a framework" is also as ludicrous.

Either has its place for the developer who understands. In at least one project for my clients I don't even have a library. In a few I use libraries and in some more I use frameworks.

They key is understanding the right tools for the job

 

I have been programming for over a decade. I can whip around the base language very quickly.

The requirement of a framework is actually a huge barrier for me because you have to know another language on top that obscures what is happening below. It also reduces performance, and creates a lot of abstract things to keep in mind.

I think learning frameworks first, language second is incredibly dangerous. I have known people who took that route and they've often abandoned projects because they didn't know how to do the difficult thing in the base language.

I have the opposite problem. Throw me some code written in vanilla js/php, and i can quickly grasp it and hack on it. Throw an unknown framework in the mix and i am completely lost due to all the extra abstractions.

 

"why shouldn't use a framework" pretty much tags frameworks as bad news. As a developer who can code with or without a framework, I would say that it depends on what you are coding. Some of the frameworks are unnecessarily cumbersome, yes, but that in itself is not a valid basis for an argument.

For instance, if you to code a clone of a system like Yelp, a framework like Laravel in PHP would 100% be better off than coding it from scratch if you have limited a budget! A biography page shouldn't need an angular scafolding when vanilla Js or jQuery should suffice!

You can move 20 tons in a shot with a 18-wheeler, or you can make about 6-8 trips with an average family truck for the same loads.

 

A biography page shouldn't need an angular scafolding when vanilla Js or jQuery should suffice!

Or, dare I suggest, just some HTML?

 

If just HTML would be enough, people would not come up with css, images, animations.

HTML is okay for info, but it sucks in representation. Fun fact, that any attempt to replace html with anything more suitable just failed (hello flash).

Yeah, you can use some HTML. But such pages have little chance to stand out. For a some weird reason, customers like then their pages look and feel nice.

I think what he means is that you can build your blog with nothing more than your templated HTML - no frontend JS needed. You still can make your page look and feel nice, but without resorting to doing everything on the client.

You can, yes. Moreover, it makes more sense in serverless world to a certain degree.

One might even have a successful commercial html-only project. But I am confident enough to claim it as an exception rather than a rule.

 
 

You always use a framework when coding. The difference is whether it's written by you or someone else.

 

I'd really like to understand what you think a framework is.

 

Let's just say "all the supporting code and how they're tied together".

all the supporting code

So libraries I'm guessing

and how they're tied together

So an 'architecture' in the loosest possible sense.

All code has libraries and an architecture. Sure, I'll buy that.

But not all code uses a framework. A framework is when somebody else other than me has chosen the libraries and the architecture for my project and is preventing me from changing them.

All libraries and architectures are chosen by someone. I'd just rather that someone was me and my team rather than the collected generalizations and compromises that make up a 'framework'.

This is exactly the reason I am not supporting "no framework" idea. You want to make archetectual decisions. Good for you. However I don't want to be that dude, who will be forced to maintain your product after you done playing the architect role.

Or, shall I expect your commitment for next 10 years or more? Should I expect great support for your solution going forward? Should I expect more and more solved technicalities? Will you give me a good documentation?

While I agree that any given framework might be too heavy for certain cases, they save time whenever anyone like it or not. It is too bad, that js offers too many half backed frameworkd and people choose to write their own.
Why franeworks any a necessity? Because every developer faces same technical challenges: DOM manipulation, templatization, communication via protocol, security, auth/authz, localization, event consumption....

Every project is different, yet some technicalities are the same. It is very natural to have shared common high-quality code to solve above with writing less client code. Which means yes - given up some architecture decisions to existing solutions.

But is that really that bad? Shouldn't you worried about solving for your specific client rather worrying for entire developer community? Framework solves for tech stuff, but it does solve for customer domain? What's the reason to increase backlog for yourself and people after you?

Why franeworks any a necessity? Because every developer faces same technical challenges: DOM manipulation, templatization, communication via protocol, security, auth/authz, localization, event consumption....

DOM manipulation? Use a library
Templates? Use a library
Communicate by a protocol (say HTTP)? Use a library
Security?
Auth?
Localization?
'Event Consumption'?

Shouldn't you [be] worried about solving for your specific client rather worrying for entire developer community?

Absolutely. Which is why I solve the specific problems of a client rather than installing the generalized website solution software (which solves problems that my client may not have) and then spending the rest of my life hacking around to make it fit the specification.

That is a real issue; heavily customized 'framework' solutions which are neither fowl nor fish. Developers have adapted the framework so heavily to fit requirements that it's barely recognisable, giving you none of the benefits of the framework but none of the upsides. I think I cover this in my other article.

Lib-way works for small to mid sites, where functionality is segregated and don't overlap, sorry.

There is no one-size-fits all and pushing for a "no framework" feels like it.

Use lib X. Use lib Y. Use lib A.
Add glue-code.
After first year, add lib B and lib C
Oh, C depends on another version of A.
Add glue-code.
Oh, now these libs should be mobile friendly...

I would expect framework to guarantee consistency with API and contracts cross-functionality wise. It is expected to minimize glue and boilerplate code.

In the ideal world.

I certainly understand the frustration then new intent and requirement doesn't fit with old framework. Sh!t happens, time to migrate to more suitable tool.

... or change roles and go to java, .net, c# whatever. Those guys stuck with a framework for decades :)

However I don't want to be that dude, who will be forced to maintain your product after you done playing the architect role.

You know that it's possible to refactor and change code right?

If you dont like the way Dave has architected the code (which btw, isn't anywhere near as big as you probably think it is for most projects) then you can just refactor it.

If you dont like how a framework has architected things, well good luck.

I am sorry, but do you understand that refactoring is not supposed to change architecture of an app? At least I call it re-work / re-write / re-fit. It usually insane amount of work for mid-sized codebase.

If architecture doesn't fit and it is too expensive to change it, I would discard it. No hard feelings.

It is not a question of "like" or "not like". Are we professionals or what? If framework doesn't fit - replace it. Customers doesn't care what exactly are you using.

I am sorry, but do you understand that refactoring is not supposed to change architecture of an app?

Says who? Refactoring is about re-expressing code without changing behaviour. That's all it is

At least I call it re-work / re-write / re-fit. It usually insane amount of work for mid-sized codebase.

You only believe this because you are indoctrinated in framework-land where everything feels big and enterprise I suspect.

If you have sufficient tooling and tests you can easily rearchitect how a system is done in a codebase that has no frameworks. Source: Me.

I am sorry, but do you understand that refactoring is not supposed to change architecture of an app?

o_O

Refactoring is a controlled technique for improving the design of an existing code base.
-- Martin Fowler - Refactoring

Design != architecture

Also, refactoring supposed to improve one and only one quality only - maintainability.

Please continue reading and understanding Martin Fowler. I would also recommend to check out Uncle Bob's thoughts on it.

I have now decided that you're trolling me to ensure that I don't get any work done today.

But in case you're not, or anyone wants to take you seriously:

martinfowler.com/bliki/DefinitionO...

and

martinfowler.com/bliki/Refactoring...

If you so like Mr. Fowler, it will be good for anyone to understand his take on architecture:
kylecordes.com/2015/fowler-softwar...

You cannot easily do it. Architecture is too big of change that also invalidates good percent of your test base (integration, system, etc). I am not sure if we are on the same page or not, but I treat architecture as fundamental decisions written in code which defines core properties of a given system. You can change it, but certainly NOT during refactoring. Mostly due to addiction of new properties and removal of others. Switching stacks from java to serverless lamda javascript is an example of architectural decision. Show me code transformation steps from one to another.
Another example is switching MVC to messaging.

Design is more flexible in that sense. Please don't mix system architecture and system design.

If you have tests, you are the king. But I would expect any good mature framework to have more stability than your codebase, btw I have seen your acceptance test.

Don't put me in single camp ;) I am not a framework evangelist nor a binary simpleton.

 

Ill paraphrase Uncle Bob, "frameworks should be a plug-in and not the basis of an architecture".. if the first thing you do when discussing your architecture is pick the framework, you're already wrong. You also are "buying in" to said framework which could theoretically change at any time. You are at the mercy of the author(s). IMO, and how I design systems, architectures are just a tool that is lovely coupled to the core business logic.

 

While this is true and I agree, that choosing a framework should not be the first thing to do when starting a project, we have frameworks for a reason. You can't develop everything from scratch and it's not so easy to do some changes even if we are speaking about purely cosmetic changes like switching from bootstrap to material design. It's just like when building machines - their parts are carefully designed to be transportable... which in turn seems to depend how wide a horse's rear end is...

astrodigital.org/space/stshorse.html

 

I love how most upvoted replies come from people who use frameworks but do not commit to the aforementioned project.
The good framework behaves as a library. It allows to use its features, but it does not dictate how to do that.

 

Frameworks are a result of an incredibly fast and competitive industry, with a lot of passionate people finding new ways of solving problems and sharing them. I like to see no-framework talk, but I think it's so important to know how much frameworks help when building dynamic web apps. Your server-only approach would probably be unaccepted nowadays, if the goal is to have a fast app with rich and dynamic user experience.

Things today are tough for sure. New developers have so much in front of them and jumping to a framework before being comfortable with basic web principles is a terrible approach. But things don't have to be that complicated. Getting started with a framework and seeing which problems it solves does not take a long time at all. Also, there are less opinionated frameworks (React!) that don't enforce architecture, besides the usual component structure that most frameworks nowadays adopted.

 

Frameworks are a result of an incredibly fast and competitive industry.

Yes. The industry of creating frameworks to polish your CV, the cynic in me would say.

Your server-only approach would probably be unaccepted nowadays, if the goal is to have a fast app with rich and dynamic user experience.

Ah, but you know what clients really like? A working app in front of users - and quickly. One without the bells and whistles, for sure. But working, being used and making money.

React!

I remember when React first landed, and the voices went up from the JavaScript community asking 'where is the framework?' 'Where do I download Flux?' they were all saying. Of course, you couldn't - Flux was just the way (some) Facebook devs were using React. Then (after a bit chaos) Dan Abramov branded a CQRS architecture 'Redux' and now we're lucky to have the hundreds of frameworks built on top of React.

 

Great article. I like the advice that you give here, and I am fully on board with you regarding JavaScript frameworks. Some frameworks are good and mostly necessary (ie., ASP.Net MVC, etc.) but these are backed by huge corporations and have support, tons of documentation, and will be around for quite some time.

I think that if someone knows how to write a web application from scratch, using only libraries, then they can easily pick up and learn a new web framework. (Well, I guess 'easily' is relative. Some of those frameworks have quite a learning curve, even for an experienced coder).

However, if a young developer learns web development using a framework, and then moves on to a new project where that framework isn't in use, then he/she needs to either learn a new framework, or actually learn how to code without relying on a framework. How to manage state? How to manage history? How to manage binding? Frameworks have implemented a lot of the boilerplate code to do these things, but they all do them differently.

However, one of my biggest hangups about web frameworks is their transient nature. What happens to that big enterprise project five or ten years from now when FrameworkX has gone out of style and no one knows it or wants to work on it anymore?

How many devs are out there struggling to maintain a big Angular.js application written five or more years ago, which was too big and complicated to convert when version 2 came out, and besides there was no compelling business case for management to allow for a conversion effort?

Now the rest of the world has moved on to the completely rewritten, new and improved Angular, and the company has to try to find developers willing to work on an old, out-of-date framework that no one wants to work on. I suppose this isn't so different from other frameworks of the past, but at least they had a longer shelf life (e.g., ASP WebForms).

And how does one find decent documentation when the frameworks change so fast the documentation can't keep up?

And please don't get me started on the thousands of dependencies these frameworks rely on. It seems to me like a house of cards ready to fall.

I get the arguments about standardization, etc. But that argument only holds so much water. The standards change so fast that the word barely has any meaning.

 

Thoughts

I think you may be missing a huge factor as well. A huge reason to even use a framework to begin with is standards. Everyone knows how to interact with the code and bringing on new employees is as simple as advertising the framework. They will be able to integrate nicely with it very quickly if they are familiar with it. If they are not familiar with but know the language it might take 3 months or so on a large codebase, in my experience.

If you are building your own applications from scratch and you expect your employer to higher people to come in and learn an entirely new application that was built from scratch with no prior knowledge or being able to work with it then you are going to cost your employers thousands if not tens of thousands of dollars when you leave.

You might not see it now because everyone knows the codebase but try to get some new people into it who may have never coded an application before. You're going to make their life hell and they are going to ask 1000 questions they don't need to which also takes away time, money and resources from other parts of the company. Again, talking from experience here. My first company I worked for did this and it was hell but she (the lead dev) thought nothing of it because she was the one who built it.

Bad Premise

Your entire argument is based off of the premise that a framework calling your code is inherently bad. You say your code calling the library is good but the framework calling your code is bad but you have no supporting argument to back that up? Why is a framework calling your code bad?

If you say it's because it makes you too restricted to how the framework does things then why is that bad? If you say it's because of the structure of the code or the methods you use is forced on you then why is that bad?

New Features

Also when you use a framework you have the benefit of tens or hundreds (sometimes thousands) of contributors working around the clock just for you and your software. New features? Sure! just check the roadmap and when new features will be added to your application.

Documentation

When coming to a new framework you have the advantage of having 100's of pages of documentation to come through. Masonite has ~550 pages. This allows new developers to reference the docs instead of ask all those questions. Noone needs to fire off a slack message "how do you set a session again? I can't figure it out".

They can:

* Read the docs
* Check stack overflow questions
* Read community articles about how others did it.
* join official lines of community like framework discords, slacks, email lists etc.

There is much more to using a framework than being forced to code a certain way.

 

Hey Joseph - thanks for your detailed response, and for sharing your experiences. This is great. My experiences obviously differ to yours, but that's being human I guess.

Bad Premise

Why is having my code called by the framework 'bad'? Fair question, and I don't really address it. In a sense, isn't all code being 'called' from something else? Called by a compiler, called by an interpreter... called by the operating system. Something else is providing the environment for what I'm writing.

I guess my objection to the inversion of control I experience with a framework usually comes down to two things: it's hard to debug when it goes wrong, and it's hard to redesign it to fit your needs. It's harder to understand what happens when your code gets called as it's obeying rules that you're not aware of or in control of.

New Features

But do I need any of them? What are the benefits to me? I've seen developers add these features to projects when they're not needed... or worse, when they almost fit a requirement. They will use them, depend on them, develop around them until the codebase is distorted in their favour. And then, ultimately, be let down with them as the final feature never gets implemented.

Documentation

I'm not sure this is an argument in favour of frameworks, or of documentation. Good libraries have good documentation too.

 

I'm not sure this is an argument in favour of frameworks, or of documentation. Good libraries have good documentation too.

it's not the library documentation I am talking about but how your application interacts with them. There is no documentation on "how to create sessions with David Wickes application that communicates with the B2C part" or "how to send a quick email with David Wickes application that communicates with the warehouse."

But do I need any of them? What are the benefits to me? I've seen developers add these features to projects when they're not needed...

out of curiosity, how long have you been in industry? Not being rude but curious. Your experiences are your own and you are entitled to them and I respect them. I am not saying my experience overtrumps your experiences but as someone who has been in industry and have ran some big projects with $60M+ on the line for quite a while I can tell you that requirements always change and if you don't need that ability to send an email that was just added to the new release of XX framework a few months ago, when your boss come back and you and says:

"oh remember that wharehouse app you made to manage all those products? i need you to add a completely unexpected requirement of sending that email directly to shipping with all item details and who the shipment is going to"

Framework to the rescue because a developer coded that for you and you can easily send an email and package it up in a nice "mailable" class you can pass around all parts of your code.

it's hard to debug when it goes wrong,

But isn't that why you have framework documentation, Stack Overflow answers, Slack channels, community articles, online videos you can reference to help you debug that is not available to you if you build something from scratch?

and it's hard to redesign it to fit your needs.

I'll give this one to you. Frameworks generally can be manipulated in the sense of file structure but typically has only 1-3 way to do things like:

  • This is how you send email
  • this is how you interact with form inputs
  • This how you do x, y, z

So yes frameworks make you do certain tasks a certain way but that's not a strong argument of why it is bad imo.

Maybe it is to you but having freedom to code the way you want to code isn't a perfect solution, it has significant drawbacks and maybe that's the point I am making is that this sounds good but it has a lot of drawbacks when you find the can you kicked down the road. I am genuinly curious on your opinion this time next year or 2 years from now or even when you switch employers.

I will be following up with you then 😈

 

Your node.js implementation doesn't sanitize static file path, allowing an attacker to load any file from disk. Framework would have likely prevented that :)

That said, I also prefer to plug in individual libraries into my own architecture rather than hack around some framework's quirks or, God forbid, try to glue several of them together. Especially in the node ecosystem, which lacks real batteries included mega-frameworks a-la .NET.

Your approach in that todomvc code of doing everything from scratch is going a bit too far for my taste, though.

 

Your node.js implementation doesn't sanitize static file path, allowing an attacker to load any file from disk. Framework would have likely prevented that :)

Totally! It's definitely going too far. I'd probably add in a routing library too.

I'd love to see a pull request to add your Node implementation if you're up for it!

 

Sorry, it's not worth fixing IMO.

A framework that parses incoming requests and calls your code is exactly the right choice for the problem of responding to web requests at multiple endpoints. Not for every problem, but for this one, yes.

 

Edit: I just realised, that you assume, that every developer you will meet is a highly capable, very well educated person (probably with decades of experience) who spends hours and hours thinking about every single line of code he/she writes. Meanwhile in the real world we have people with nearly zero experience, who try to achieve results after checking the first tutorial (probably even some portion of it) they find on stackoverflow or google. And this is OK, because most probably the end user need something to get their job done and they need it now, not a decade later.

I carefully read the article and didn't find any real argument against using frameworks. Yes I dismiss all your arguments especially the only real one: that we don't need them, but in fact they save lot of time and this is basically the most precious thing we have in our life. You can do something small like a To-Do list in any language, but when you keep adding more and more featured you will end up writing tons of code and solving problems, that others did before you. Most probably you will need other people to help you. The bigger your codebase is, the harder it will be for them to figure out how it works. This is why framework popularity matters - it's easier to find someone to help you.

 

Love the idea! I have rolled my own as well (github.com/crh3675/nodeii). The one thing that I have found with "roll-your-own", even with simple projects is that if the developer is not disciplined enough to write the appropriate documentation in README files or comment their code, then all others are likely to fail trying to work with their code.

I wish that everyone had the same tenacity, discipline and confidence to build their own custom solutions but the truth is, they just don't teach most of what we do in colleges. What we provide with our vast experience is exactly that, we are "hammer and nails" and modern developers are "roofing tool 3000".

In the hopes of trying to make things easier, smart guys like us have worked to provide our implementations of practices and better tooling - we have contributed to the problem; a simple psychological enabling scenario.

The smarter that 10% of us get, the dumber and lazier 90% of others become because we gave them all the answers :-)

Software Development has become so subjective nowadays where every developer that manages to bolt together all of the complex libraries that someone smarter than us created are now experts in their trade.

There is no one-way to anything anymore with software, there is no manual to build the most efficient website or application. It takes experience to "do the right thing" and if a framework is a colossal learning curve for a small team, then it is a bad move.

I appreciate your experience and dedication, thanks for sharing!

 

Nice post Dave.

I do feel strongly that a lot of developers would be better served looking at this kind of code and learning the fundamentals rather than immediately diving into frameworks.

Hopefully this will prove to be a great resource for many

 

In my opinion one is not a developer if they don't understand the fundamentals. Frameworks and library solve different kind of problems but it depends on the project at hand. Saying that frameworks are just bad is an oversimplification, perharps a lack of understanding to some degree

 

Much agreement here. What about svg? I see it as loading resources from many places depending on context. Hence all page formation is dynamic but atomically static.

Most frameworks stand directly in the way. E.g bootstrap can't do ajax well or makes it near impossible. More elsewhere...

 

Thanks for this. Absolutely brilliant. I have always been against frameworks (apart from .NET) generally, although I recognise they have their place occasionally, and after another argument with a frameworker I decided to see if I was alone in this view and found your article. It pretty much says it like I would. Thanks again.

 

I shall keep it short...at a certain level of complexity, frameworks become very valuable. Having a common system of ideas to express ideas with your team that lets you avoid thinking about smaller details is a miracle once a project reaches a certain size. It's kind of like micro-optimizations...if I am sitting at my keyboard worrying about how many CPU cycles a method will consume with absolutely no context or profiling data indicating that I have a problem, I have gone down a rabbit hole and I need to come up for air.

And then there's maintenance...I can write some pretty clever and efficient code, but turns out some of my coworkers disagree about that statement ¯_(ツ)_/¯

 

A lot to take in. Valid points from both sides. Thanks Dave

 

What i have done is build my own basic framework, which i use as basis for my projects, but it is really tiny, so only has needed things that i always use in my projects, then if i need some other things ill write it then and there, and add it to my collection of additions, so i can quickly grab it and add it if needed, this simplifies my projects, keeps the code tight, while still being reuseable in other projects, for example, if im building a site for a customer, then throwing in the blog unit, instead of rewriting, and then its added, but i still know my framework down to the core, since i build it from ground up. so, frameworks are useful, but available frameworks, tend to be extremely bloated, since they have to cater to so many whatif situations

 

As several have stated, frameworks do provide a standard. They try to standardize the architecture and basic how-to's.
Pros:
-- restricts style
-- provides libraries
-- developers with experience 'should' be able to get up to speed quickly
Cons:
-- restricts style
-- adds a lot of unused libraries
-- developers still write 'logical mazes'

I do love Vanilla JS, jQuery, and can code in Angular, AngularJS, and Vue. What I'm finding is ... I still fall back on the vanilla and jQuery when it makes sense. Yeah it's good to not re-invent the wheel ... except a lot of wheels take turns you may not need.

 

Hi everyone. Really glad that this piece is inspiring so much enthusiastic debate. Could we all please try and keep it friendly and civil in the spirit of Dev.to

 

That TODO app looks really cool :) I have a similar app I want to build. Do you think it would be possible for me to somehow re-use some of the awesome patterns you've built?

 

Yes of course you can use these ideas. Don't do anything evil and have fun!

Note to self: add license to project.

 

Very opinionated, biased and low quality of post.

  • You didn't answer well "Why let them call you" is bad ? It's one of the most powerful idea in software engineering.

  • What's the purpose of the demo's source code ? To demonstrate you can re-invent the wheel ?

  • And you put your website on a technical post like this, for marketing inside a technical article ?

This is total crap and non-sense. I hope dev team should remove this post.

 

Very opinionated

It's certainly an opinion, but 'total crap'???

There's no reason to attack anyone here, this community is meant to be an open place for developers, a place to expose your opinion (with respect, a LOT of respect).

You might disagree with David, but this sort of comment is destructive and must be avoided.

 

Treat this as my opinion. It's the kind of posts i don't want to see on dev.to, yours might be different.

That's a form of censure, not an opinion.

It's completely understandable that you disagree with David, but expecting that he doesn't publish his ideas is not and is against dev.to code of conduct:

Being respectful of differing viewpoints and experiences

Thanks for reminding.
The crap point is not about technical viewpoint, it's about the intention on marketing side on a purely technical article.

Where is the marketing? He's not trying to sell anything

I believe there's been some misunderstanding here.

The problem is not that you disagree with him, or even think that he's doing something bad to the community (which he isn't).

The thing is that, if he had done something wrong or broken some rule, the ideal course of action would be to a) report abuse; or b) explain what rule is being broken and attempt to mend the problem.

Attacking his ideas and opinions is not the way to achieve a respectful and diverse community

 

This is total crap and non-sense. I hope dev team should remove this post.

I suggest you try this report and see how far it gets you. Just because you dont agree with a post does not mean it is "total crap" and should be removed.

 
Sloan, the sloth mascot Comment marked as low quality/non-constructive by the community View code of conduct

It's total crap to me, does it make any sense ?

Try and use your imagination.

Imagine a developer who has lived in the world of frameworks, and lived in the world of building systems from libraries.

Now imagine they weigh up the pros and cons of both and have decided that they prefer not to use frameworks.

Those are NOT devs in the first place!

A developer SHOULD understand the implication at the "vanilla", library and framework level in the first place.

If you took most JAVA, C, C#, PHP,...developers today and told them to code in machine language, they would be like sheep watching tv.

There is a reason we have higher programming languages. Likewise, there are reasons we have libraries. See where am going with this?

code of conduct - report abuse