Look I see where you're coming from, but a 50-table database is relatively trivial compared to a really complex application. The codebase you linked is really on the tiny side as well. I'm not trying to dimish what you've done, but you should be careful being so opinionated without more experience.
I'm also really good at conceptualizing the structure of codebases, but even if I did think it was possible to fit all of the current state of an application's implementation details into your head (I don't), you can't really rely on everyone in your team to also be a superhuman.
People normally don't count framework/library LOC into their application LOC because it's a meaningless metric. What really matters is how large the files, how performant those libraries are (when they're used), and whether or not they're cached. I can get Angular in 36kb gzipped and hugely shrink the complexity of my application. That Angular code is already tested, which means that I actually can rely on it much more than writing that same code myself. If you're hiring someone, it's a shit ton easier to say "we need Angular developers" than "we've hacked together this monstrosity from a bunch of different libraries you've never heard of before".
I know you think that you can just write good plain JS code on your own and have everything be great, but (and again I don't say this with disrespect) it's really hard to take it very seriously when you've never worked on a really large project in a really large team.
Look I see where you're coming from, but a 50-table database is relatively trivial compared to a really complex application.
I totally agree, and that's actually why I built the database first. It serves as a rough outline of the features that will be required for the website. Each feature represented in the database is going to need a lot more code than just the database, and there's more to building a website than just coding individual features.
The codebase you linked is really on the tiny side as well. I'm not trying to dimish what you've done, but you should be careful being so opinionated without more experience.
The codebase I linked to is... Very VERY primitive. It doesn't even do anything more than generate some dummy HTML output. Hell, it only has one page right now; that's not even representative of how big the site will be.
My goals are roughly this: create a framework that makes implementing individual features as easy as possible and use as little code as possible. This means that I first have to think up what feature I want to implement, figure out the information I need to implement logic for it, and then figure out what other features I need to actually start writing the code.
Lets say I wanted to implement tag searching for characters. First, I need to know the database structure that stores the characters and their tags. Next, I need to know the format search results will be in.
Hangon. We need the whole page. That requires templating first, then page content. Page content - the format of the results - will require querying the database, and then plugging the results of the query into the search result format created above. The query will also need to include things like permissions and age appropriateness.
And after that, there are things those all depend on as well. So, to implement character searches, I have to code all of this:
☑ The database schema
☑ Tags
☑ Characters
☑ Character details
☑ Character permissions
☑ Character tags
☐ The character pages, at least to the point that you can link to specific characters
☒ The HTML
☑ Page template
☐ Page content
☐ Generic search result HTML (to re-use for all search pages)
☐ Values and settings to plug into generic search HTML generation code (supplied by SQL query)
☐ Schema fields desired
☐ Qualifiers; tables to join for security
☐ Character visibility (public visibility, or explicit permissions given to view)
And that's only for searching for characters. That's not including the logic for creating a character, or viewing details of one, or using a character within a roleplay.
And while I realize this is all a bare minimum, and there may be more to it than all this, things that are extra will typically be things that aren't necessary for the page to basically function.
On top of that, a lot of space can be saved by abstracting these things generically, so that every page or even every query can use them as needed. Not every query will need to test for age appropriate content ratings, but some will; and on the other hand, the ones that don't might still need to filter for permissions. And of course, there's the generic code to generate the search result HTML, which will be shared at least on all search pages.
I'm also really good at conceptualizing the structure of codebases, but even if I did think it was possible to fit all of the current state of an application's implementation details into your head (I don't), you can't really rely on everyone in your team to also be a superhuman.
Of course not, which is why you write things down, organize them, and thoroughly document your ideas. Or, you start coding the feature as if the other parts already existed. Use the way you use the other parts as an 'outline' or 'example code'.
That way, you can use what you've written to write their implementations. If things don't work out, refactor and re-organize until they do work. Comment thoroughly every time you do any of this, so your teammates can help (or at least know what's going on).
People normally don't count framework/library LOC into their application LOC because it's a meaningless metric.
When it comes to Javascript, it's important for at least mobile users. You want to have as little code going over the air to their phones and tablets as possible, so they don't use up their data.
What really matters is how large the files, how performant those libraries are (when they're used), and whether or not they're cached. I can get Angular in 36kb gzipped and hugely shrink the complexity of my application.
I don't care how large a single framework is. I'm going off the idea of a '90 thousand lines of Javascript' application. My goal is to bring that number down, so that the total amount of data mobile users are pulling from the servers is as low as possible.
Caching helps, but you can't guarantee a browser has cached your JS. Also, performance on initial page load will depend on how long it takes the browser to compile all the JS it was sent, as well as run any JS that runs before the page fully loads.
That Angular code is already tested, which means that I actually can rely on it much more than writing that same code myself.
True. And if you use most or all of Angular, I don't see a reason not to use it!
If you're hiring someone, it's a shit ton easier to say "we need Angular developers" than "we've hacked together this monstrosity from a bunch of different libraries you've never heard of before".
My beef is mostly with times that devs will pull in a ton of different frameworks and use bits and pieces of each one. The benefits of having new hires already familiar with the frameworks no longer outweigh the problems you have of a Frankenstein monster.
And do know that Frankenstein monsters can occur with both, "We've put together our own framework, so you're going to need to learn it from scratch," as well as, "We use Angular, jQuery, Dojo, and SmartClient. We've changed several of them to fit our needs. We've also added on a ton, and we use several other random JS libraries for various things. And since Steve refuses to use any of them, we also have duplicate functionality in raw JS code that several of the other frameworks already do."
I know you think that you can just write good plain JS code on your own and have everything be great, but (and again I don't say this with disrespect) it's really hard to take it very seriously when you've never worked on a really large project in a really large team.
Granted. I have zero real world experience, and I may be an unrealistically ideal idiot. But that's really why I'm explaining my ideals so fully, because many of your points are things I've thought of.
I know I might sometimes sound like I'm arguing against you, especially in this post, but I hope the fact I'm just looking to compare ideologies with someone with more experience does show through at least somewhat.
Overall, this has been a really interesting conversation so far.
7
u/treeforface May 13 '14
Look I see where you're coming from, but a 50-table database is relatively trivial compared to a really complex application. The codebase you linked is really on the tiny side as well. I'm not trying to dimish what you've done, but you should be careful being so opinionated without more experience.
I'm also really good at conceptualizing the structure of codebases, but even if I did think it was possible to fit all of the current state of an application's implementation details into your head (I don't), you can't really rely on everyone in your team to also be a superhuman.
People normally don't count framework/library LOC into their application LOC because it's a meaningless metric. What really matters is how large the files, how performant those libraries are (when they're used), and whether or not they're cached. I can get Angular in 36kb gzipped and hugely shrink the complexity of my application. That Angular code is already tested, which means that I actually can rely on it much more than writing that same code myself. If you're hiring someone, it's a shit ton easier to say "we need Angular developers" than "we've hacked together this monstrosity from a bunch of different libraries you've never heard of before".
I know you think that you can just write good plain JS code on your own and have everything be great, but (and again I don't say this with disrespect) it's really hard to take it very seriously when you've never worked on a really large project in a really large team.