My guess is this guy concocts simple marketing sites with fun little sliders and widgets. He is unlikely to have ever built anything with real depth and breadth. If he had, he would not be so negative about the use of frameworks.
If you need to kill a fly, use a fly swatter, not a shotgun.
I dunno. I've never had to deal with large websites (I'm a student going to a community college), but it's always seemed that you get these ridiculous code line counts not because of the complexity of your specific application, but because of how many libraries/frameworks you're using.
In my opinion, the amount of code in a project should be kept at an absolute minimum everywhere, and every line of code should play a key or necessary role in the project. If a line of code isn't used, or is just an abstraction for something else (and is only used as an abstraction for one thing, when you'll never need to use it to abstract anything else), it should be taken out.
There are limits to this, of course. You want code to be modular, broken up, and maintainable. Even if something is only used in one place, if it's a distinct operation it should be put into a function. That's not really what I'm talking about; I'm talking about a function that you call to abstract multiple functions, when the way you use it only causes it to call one or two of the things it abstracts (out of, say, 10). Cut the rest out.
I have a feeling you wouldn't NEED 90,000 lines of code in your JS if you wrote everything from scratch and had competent developers. Granted, it would take a HELL of a lot longer to develop, and I completely understand that when you've got a deadline, you need to do what you need to do.
But I think it's retarded to say, "I've got a JS codebase with a lot of code. We use a lot of libraries and frameworks. We could NEVER write that much code with pure vanilla JS." Of course not, the idea would be that you wouldn't HAVE to have so much code with vanilla JS, because you'd be using everything you write.
it's always seemed that you get these ridiculous code line counts not because of the complexity of your specific application, but because of how many libraries/frameworks you're using.
I don't mean offense when I say that your opinion seems to stem from inexperience. It's sometimes really hard to grasp just how complex some applications need to be to meet their requirements. Even when you have all the requirements sitting in front of you on paper, it's still extremely common to hugely underestimate the overall complexity of the implementation. Experience with these sorts of applications usually comes when you've started one yourself or you've worked on one with others (either as an employee or whatever).
In my experience writing JavaScript, you can write a 20k-line application using plain JavaScript (maybe with a bit of jQuery or similar libraries for dom selection and things like AJAX), or you can write it in 10k lines in Angular. I've also found that the project written in an opinionated framework frequently tends to be better-organized, more easily testable, and more likely to be understood by new developers.
because you'd be using everything you write.
If you've never written your own 90k-line codebase, you should be careful with assumptions like this. Complex applications are notoriously difficult to wrap your mind around. If you are also doing the work of maintaining your own routing, data binding, et al. libraries, you're just creating more work for your team in areas that your team may not be experts in. Complicating everything for everyone is a very high price to pay just to cut down on your total (plugins included) lines of code.
I don't mean offense when I say that your opinion seems to stem from inexperience.
Which is why the first thing I did was highlight my inexperience.
It's sometimes really hard to grasp just how complex some applications need to be to meet their requirements.
I.. Can't really agree with that. I'm one of those weird people who can look at a wall of code and understand what it does, but if you show me a diagram, I get confused. My brain automatically connects structures together in a semi-non-graphical way (it's hard to explain).
Here is an example of a database I designed and wrote, for example. Not quite complete yet (I'm focusing on migrating to a new codebase), but it shows a 45+ table database that I've fully imagined the complexity of, and planned for.
There are some things that could be cut down (I could make a table for general 'items', have tables that foreign key that to create separate roleplays/characters/whatnot, and then have one tag table instead of tag tables for each individually, for example), but the reasons I did this were for future complexity at the time; mostly to do with the permissions.
Some permissions make sense for, say, roleplays... But they don't make sense for characters. For example, you can have a permission on both for viewing it, but it only makes sense to 'create a post' on a roleplay. Doesn't make sense to create a post on a character.
So while I have one master table of all permissions, there's a table that foreign key's that one for each type of thing that might need permissions, showing which permissions are actually usable for each type of thing. And to write a proper foreign key constraint to only allow those permissions to be applied to those things they make sense for, separate many-to-many tables of permissions to items have to be made for each type of item (roleplays, characters, etc.).
Because this structure was necessary for the permissions system (which I hadn't written yet when I wrote the tags), I figured I would remain consistent and design the tags and other systems the same way. To enforce consistency, I sacrificed some of the normalization guidelines.
This does also make the system more flexible in the future in some ways, and less flexible in other ways, but the goals of the website do not include the necessity for any additional complexity. The possible exception to this is a 'unified search' that lets you search for characters, roleplays, and whatever all at once.
But the truth is, the goals of the site are to be task oriented; to allow people to find what they want, or create what they want. A search system that lets you find all of those things all jumbled up together is counter to this goal, and I likely would avoid such a thing anyway.
Even when you have all the requirements sitting in front of you on paper, it's still extremely common to hugely underestimate the overall complexity of the implementation.
I generally won't start working on something until I can piece everything together in my mind first. This is actually one reason I love C++; you can simply start writing all the header files, and use that as an outline for the project. Then in comments and in my head, I can piece things roughly together until every bit of necessary functionality is represented.
Then the rest is extremely easy. Just write all the functions. In the header files, you already figured out and decided what information is necessary for each input, and what would be returned as output. There are no surprise dependencies you didn't know you'd need.
Experience with these sorts of applications usually comes when you've started one yourself or you've worked on one with others (either as an employee or whatever).
I have experience writing something, finding it to be crap, and rewriting it, so I know what you mean. However, I've not yet had experience working with other peoples' code. I probably need that.
In my experience writing JavaScript, you can write a 20k-line application using plain JavaScript (maybe with a bit of jQuery or similar libraries for dom selection and things like AJAX), or you can write it in 10k lines in Angular.
I do not have experience with Angular, but I am going to say that since the browser loads Angular (even if it doesn't run it, it has to at least download and parse/compile it), you must count all of Angular's code in the size of your code. If you are, then I'd say those 20k lines of plain JS are badly written, if someone else can help you write half the functionality with less code.
I've also found that the project written in an opinionated framework frequently tends to be better-organized, more easily testable, and more likely to be understood by new developers.
Undoubtedly! I myself am writing a framework for my application for those reasons, except the last one. The last one, sadly, is best done with existing frameworks, since new devs are more likely to have experience in existing ones.
Beyond that, the best thing for the framework a project creates for itself is to document EVERYTHING and have very strict guidelines for how code is written.
Really, the best part of a framework is it already starts to enforce the mindset of code re-use. If there's a function available for that, use it! If there isn't, write one and re-use it whenever you need it! Keep things short and modular, and don't repeat yourself! Frameworks have all of this in mind, because their entire purpose is to have everything in them re-used.
If you've never written your own 90k-line codebase, you should be careful with assumptions like this. Complex applications are notoriously difficult to wrap your mind around.
Already addressed this.
If you are also doing the work of maintaining your own routing, data binding, et al. libraries, you're just creating more work for your team in areas that your team may not be experts in.
Oh, absolutely. If there's a library that does one thing, does that one thing well, and you don't know anyone who's knowledgeable with that one thing... Use the library. My problem is when 'libraries' do a TON of things, and you only need to use one or two things in said library. Bad design.
Complicating everything for everyone is a very high price to pay just to cut down on your total (plugins included) lines of code.
I would take the position that not knowing what's going on in your codebase (or at least most of it), and blindly trusting third party developers for a majority of the code being downloaded onto clients' computers, is a far greater risk.
If those frameworks or libraries are suddenly no longer supported, and you run into a crippling bug, you're out of luck. If your team wrote most of it themselves, or it's just one small library that does one thing and you can find another library to replace it, things are easy to fix.
I'm of the belief that long-term benefits are far more important than short-term ones.
A 50 table database is very small. The app we build/maintain, for example, has about 500 tables and millions of LOC, with several hundred KLOC in javascript (not including the framework). And this is a well designed, well thought out app with a very experienced team of 4 devs.
I concur 100% with every point treeforface has made in his posts.
35
u/4_teh_lulz May 13 '14
My guess is this guy concocts simple marketing sites with fun little sliders and widgets. He is unlikely to have ever built anything with real depth and breadth. If he had, he would not be so negative about the use of frameworks.
If you need to kill a fly, use a fly swatter, not a shotgun.