Coding As Little As Possible - Third party packages and when to use them

[Shinka]

Update 12/7/2017: This diatribe is intended for developers using frameworks like Laravel, Rails, Symfony, etc.

TL;DR See list at end of post for features that probably aren't worth the effort to write yourself 

Introduction

When starting a new project, there's a temptation to write everything yourself, from user registration to forums. Don't. You don't need to reinvent the wheel when there are already hundreds of implementations out there. Every hour you spend developing a common feature is an hour you are not developing the core of your game, e.g. breeding or pet customization; and every line of code you write is another line you need to maintain. When you have a fresh, clean slate in front of you, maintenance doesn't seem like a huge concern, but the time cost quickly adds up.

TL;DR Make "Code as little as (reasonably) possible" your driving philosophy

"But..."

"... I just need a lightweight forum system."

The lightest traditional forum system requires at least three database tables (forums, threads, posts) and associated models, each with their own set of validations (threads must have subjects, posts cannot be empty, etc). Then you need authorization guards so only staff can create and delete categories, pin and lock threads, and so on.  This might not sound like a lot of work for someone who can spin all that up in four commands (looking at you, Rails devs), but remember that for every feature, that's another thing you need to write tests for and QA. (You are writing tests, right?)

TL;DR There's a package for that.

"... I need X special feature."

Let's say you want to display a user's title on their posts. This isn't a feature that's going to come in a third party forum package, but it's a feature that can easily be added to one. Good third party packages have interfaces or designs that allow you to tweak or hook into their behavior. For that forum package I've convinced you to use, just open up the post view and add in the relevant property. This is (potentially) one line of forum-related code. 

TL;DR There's not a package for that, but there's a package you can build off of. 

Choosing the Right Package

Caveats

• Only use popular open source software with a permissive license e.g. MIT, CC0, or Unlicense. Most major open source projects use one of these licenses, or some other flavor of Unlicense. If a package's license is not mentioned in their readme section, there's likely a LICENSE file at the root of the repository.
  
• Never trust closed source software that isn't extremely well regarded—and even then, I can't think of any examples beyond maybe plugins for game engines like Unity, which is a different beast entirely.
  

Metrics

When choosing a package, there are four qualities I look at first:

• Features
  
• Extensibility
  
• Contributors, downloads, and community regard
  
• Stability and ongoing maintenance
  

TL;DR You want a package that reasonably fits your use case, is easily extensible or configurable, is highly regarded by your framework's community, has a robust stable release or is actively updated, and doesn't have any major bugs!

(Wait, that TL;DR might have been longer than the section...)

Regard, Downloads, & Community Standards

You don't want to just grab any random package from GitHub's dregs. The number of contributing developers and downloads isn't the end-all metric for package evaluation, but if a package has a dozen contributors and hundreds of thousands of downloads, it's probably good to go. 

If there's not a package in the top three results when you google "<framework> <feature>" (e.g. "rails forums") and if you can't find half a dozen Medium articles about it (because apparently every dev has one of those now!), then you might be out of luck on that one.

Features

Let's continue with the forum example and pretend you're using PHP and Laravel for your back-end. Write down bullet points for all the features you need. An example might be

• Traditional forum structure, e.g. categories > forums > threads > posts
  
• Permissions, e.g. only staff can pin or lock threads
  
• Admin panel to create/edit/delete categories and forums
  
• @mentions
  

Now let's do a quick search for "laravel forum package", and it looks like there are two strong contenders, Laravel Forum and Chatter. Now let's see how they compare to our desired feature list:

• Laravel Forum uses a traditional forum structure, but Chatter takes a cue from Flarum's tag-based structure
  
• Both have a permissions system using Laravel's authorization
  
• Both have admin panels
  
• Neither has @mentions
  

You absolutely need @mentions, so both of those are deal breakers. But wait! There's a package for that!

Another quick search for "laravel mentions" brings up Laravel Mentions. (Do you sense a naming theme here?) Laravel Mentions allows you to set any text input or textarea as capable of @mentions, which is even better than if it was baked right into the forums! This allows you to reuse the same package for @mentions in both the forums and, for example, user profile comments!

On the other hand, if you really do just need a lightweight forum solution and every available package has dozens of features you never intend to use (and that aren't written modularly so they can't be removed), then write your own! You want to weigh features you need against features a package has that you need and that you don't need.

TL;DR Look for packages that reasonably fits your use case, but decouple features where possible (e.g. separating forums and @mentions)

Extensibility

Eventually, you might want to add notifications for things like receiving PMs, a subscribed thread getting updated, and news/announcements. This is best done via events and event listeners or some other kind of Observer pattern, where every notifying action dispatches an event, e.g. sending a PM dispatches PMSentEvent. Both Laravel Forum and Chatter dispatch events, so we're good to go there!

An ideal third party package is easily extensible and configurable—maybe using traits, interfaces, or method hooks! But even easily extensible packages are useless if they don't document how you can extend them.

TL;DR Look for packages that are extensible and have comprehensive documentation

Stability & Ongoing Maintenance

Assuming you're looking at a GitHub repository, click that Commits tab and note the frequency of commits and the dates of the latest commits. If there hasn't been a commit in over a year, that package might not be maintained, and it might not be patched if you encounter a major issue. This doesn't have to be a deal breaker—if the package has had a robust release cycle, is on a stable version, and doesn't appear to have many bugs, then it's probably safe to use.

Now click the Issues tab to be taken to the repository's issues tracker. Take a look at the first page of issues. Are they tagged or marked by contributors, e.g. as "solved" or "not an issue"? Do most of them seem to be due to user error, e.g. migration errors? Then you're good to go! But if the top issue has three pages of users all reporting the same major issue, it's probably best to pass that one by.

TL;DR Look for packages that actively maintained or have a stable release without any significant issues

The Big List of Stuff You Shouldn't Write Yourself

And example Laravel packages!

• Authentication (you should almost never write your own authentication! but Laravel 5 comes with its own auth system anyway)
  
• Forums (if you didn't get that already)
  
• Private messages
  
• Instant messages
  
• @mentions
  
• Tags
  
• Audits, model changelogs, and logging
  
• Authorization (Laravel devs are lucky enough to have that included in the core framework via guards)
  
• User verification (that register -> receive email -> verify registration workflow)
  
• Invite/Beta codes
  
• Friendship systems
  
• Online/recently online users 
  
• Caching
  

 

[Boltgreywing]

I am removing this post as it was emotionally charged and I was in a bad mood at the time I posted it. I reacted badly to a player and it was wrong of me.

 

[Shinka]

@Boltgreywing I totally respect your disagreement, but I'd like to address a few of your counterpoints! (I came back up here after writing the entire post, and I'm sorry it turned out so long! I got wildly out of control somewhere part way through and couldn't stop myself.)

Forums I have to disagree with you on that. Forums are really simple to design. The default behaviour of forums is they automatically send messages to user's inboxes and automatically subscribe users to topics that they don't want. This is bad behaviour and spams the user's mailbox to no end. Private messages are simplistic to design and don't require much code. If you want a two tier message system then you are out of luck because most only work on the one tier system.

Out of the five or so forum packages I've researched, none of them send email notifications out of the box, though this would be very easy to implement on your end with event listeners. Email notification is a behavior that's very prevalent in full forum software—things like MyBB, Xenforo, IPB, and so on—and while I don't explicitly recommend integrating your project with most of those (they tend to have complex admin panels and a lot of features that are ultimately unnecessary when the forum is only a secondary feature) it's extremely simple to turn off email notifications. I just took a look into my Xenforo admin panel, and it looks like I could do so by flipping two or three switches.

Beyond that, forums are simple, at their most basic. But that's still time spent implementing, testing, and future regression testing; which means it's time not spent on your project's core (i.e. most important) features.

I imagine that most virtual pet sims would want the following features:

• Weighted categories, weighted forums, threads, and posts, and their respective validations
  
• Nested forms for threads and posts
  
• BBCode or Markdown parsing
  
• Notifications
  
• Permissions
  
• Pinning, locking, and deleting threads
  
• Permissions
  
• Soft deletion
  

I wrote a very long breakdown of each feature, what would go into implementing them, and time estimates for each; but it was stupidly long so I ripped it out. If you're interested, ping me and I can throw it up somewhere.

TL;DR I estimate implementing the above features would take me ~12.5 hours, including testing; versus finding and plugging in a forum package would take me ~3 hours, including time spent adding in post vistas and user titles. The custom solution estimate is not including front end work—things like general design, AJAX paging or posting, and mobile responsiveness—which offhandedly I might estimate at another 12 hours, depending on design and JavaScript experience. The package solution estimate is assuming it comes with an elegant enough front end. (Out of the packages I mentioned, Chatter has a lovely front end, but Laravel Forum's is extremely basic and would require additional design work.)

(Maybe I'll time myself later and see how long it takes me to whip up a solution with those features. Hmm.)

When your developers are also working full time jobs, your budget is small or nonexistent, and you're trying to get out an MVP asap, 12 hours (we can even bump it down to 8, to be conservative; again, not including front end work) is a lot of time. Or maybe it's not for you—then implement a custom solution to your heart's desire!

Now imagine you have a dev who gets halfway through implementing this and then bails. The next developer has to get up to speed with the already existing code, which might not be particularly difficult but is still additional time.

That said, if you already have a solution for a particular feature that works and does what you need it to do, it's probably not worth ripping it out and replacing it with a package! But if you have a page of eventual improvements you want to make, maybe take a step back and reevaluate. 

I am probably also 100% biased because I'm sick of writing forum solutions and fixing other peoples' forum solutions.

But I'm currently hooking a site up with Flarum, which is a little different than what I've been recommending because Flarum is an entirely separate app that's outside of the main project, and I had to integrate its authentication with the main project's. Still, to write a custom solution as beautiful, seamless, and responsive as Flarum would take me a metric ton of time.

Anyway that is certainly enough of me ranting about forums.

Private messages are simplistic to design and don't require much code. If you want a two tier message system then you are out of luck because most only work on the one tier system.

A basic PM system is simple. But my basic argument stands: it takes time and maintenance, and time is at a premium for small moonlighting teams. If you want to get into things like live/realtime updates, that's trickier. You could do write an AJAX solution, but that can be expensive depending on your request interval; but for proper realtime, you probably need to learn or brush up on sockets, which is time spent getting up to speed, implementing the solution, and then testing it.

I'm not sure what you mean by two tier, so I can't comment on that!

User verification systems are a bit more complex depending on what you are doing. I set mine up from scratch. If you like to see the code for that you can pm me.

I appreciate the offer, but I've setup a couple before. When I'm learning a new web framework, I like to roll my own user authentication and authorization workflow because it touches on a little bit of everything. (Though I would never use any of these auth solutions on a live site!) My bias also comes into play here because if I never have to deal with Rails' mailer again, I can die happy.

Audits I am not using at this moment.

I haven't used auditing before, but activity logs and model changelogs have been pretty vital for my workflow. (Not to mention for support on a live site! Restoring lost items is a cinch when you can see exactly where they were lost.)

So most of things from this list I was able to create with relative ease. Meaning most of things I mentioned don't require plugins.

Gonna skip the rest of your points because most of them boil down to the above. Just because something is easy doesn't mean it's worth the time and maintenance. I've implemented 90% of the features I listed about, as a learning experience or otherwise, and most of them are easy. Most only require one or two models and tables, basic CRUD actions, etc. But it's still reinventing the wheel! If you need a very customized or unusual solution, then that's different. Code away!

Also Bootstrap is a load of bs do not use it unless you want your entire file screwed up!

I very much disagree, but I respect that Bootstrap is not your cup of tea. I'm assuming you're talking about the HTML/CSS framework and not like, bootstrappers. Bootstrap can be a very powerful tool for teams that don't have a lot of design experience. (Back end devs are universally terrible at design, but give me something that I can use as building blocks, and I'm good to go!) Bootstrap's mobile friendly solution is eventually going to be superfluous as flexbox and css-grid pick up traction; but for now, there might not be enough browser support for those to be viable alternatives. The last software company I worked at spent a significant sum of money (a number that about made me swoon) for a UI framework and a few screens for the most important pages—and it was built off of Bootstrap 3! 

Bootstrap-based designs can look rather samey. I can usually pick out what sites are using Bootstrap, but with a little bit of custom styling, you have something decent looking for way less work than it would take to build from the ground-up. 

When I'm prototyping a hobby project, I almost always use Bootstrap, though I've taken a couple other CSS frameworks for a spin.

My advice: Code the sections that make sense to code for and those that are difficult use plugins for. This will keep your sections relatively lean.

I'll qualify my philosophy of "Code as little as possible" with "... as long as the time spent plugging in a good package and adding in necessary features is less than the time it would take to write it yourself." If there are only a couple half-baked private message packages for your given framework, then absolutely write your own! Or if you want a "threaded" system (like how Reddit's comments work, where replies are nested), don't bludgeon an ill-fitting package into the right shape! Don't settle for something that isn't almost exactly what you need but understand the amount of effort it would take to add extra features vs start from the ground up. (Adding in post vistas? Easy. Adding a threaded post system? Probably more work than it's worth.)

This is way too long of a post, and I'm sorry if I sound like a broken record. No one philosophy is going to fit everyone's needs, but this is mine and it has served me well.

 

[Boltgreywing]

@Boltgreywing I totally respect your disagreement, but I'd like to address a few of your counterpoints! (I came back up here after writing the entire post, and I'm sorry it turned out so long! I got wildly out of control somewhere part way through and couldn't stop myself.)

Out of the five or so forum packages I've researched, none of them send email notifications out of the box, though this would be very easy to implement on your end with event listeners. Email notification is a behavior that's very prevalent in full forum software—things like MyBB, Xenforo, IPB, and so on—and while I don't explicitly recommend integrating your project with most of those (they tend to have complex admin panels and a lot of features that are ultimately unnecessary when the forum is only a secondary feature) it's extremely simple to turn off email notifications. I just took a look into my Xenforo admin panel, and it looks like I could do so by flipping two or three switches.

Beyond that, forums are simple, at their most basic. But that's still time spent implementing, testing, and future regression testing; which means it's time not spent on your project's core (i.e. most important) features.

I imagine that most virtual pet sims would want the following features:

• Weighted categories, weighted forums, threads, and posts, and their respective validations
  
• Nested forms for threads and posts
  
• BBCode or Markdown parsing
  
• Notifications
  
• Permissions
  
• Pinning, locking, and deleting threads
  
• Permissions
  
• Soft deletion
  

I wrote a very long breakdown of each feature, what would go into implementing them, and time estimates for each; but it was stupidly long so I ripped it out. If you're interested, ping me and I can throw it up somewhere.

TL;DR I estimate implementing the above features would take me ~12.5 hours, including testing; versus finding and plugging in a forum package would take me ~3 hours, including time spent adding in post vistas and user titles. The custom solution estimate is not including front end work—things like general design, AJAX paging or posting, and mobile responsiveness—which offhandedly I might estimate at another 12 hours, depending on design and JavaScript experience. The package solution estimate is assuming it comes with an elegant enough front end. (Out of the packages I mentioned, Chatter has a lovely front end, but Laravel Forum's is extremely basic and would require additional design work.)

(Maybe I'll time myself later and see how long it takes me to whip up a solution with those features. Hmm.)

When your developers are also working full time jobs, your budget is small or nonexistent, and you're trying to get out an MVP asap, 12 hours (we can even bump it down to 8, to be conservative; again, not including front end work) is a lot of time. Or maybe it's not for you—then implement a custom solution to your heart's desire!

Now imagine you have a dev who gets halfway through implementing this and then bails. The next developer has to get up to speed with the already existing code, which might not be particularly difficult but is still additional time.

That said, if you already have a solution for a particular feature that works and does what you need it to do, it's probably not worth ripping it out and replacing it with a package! But if you have a page of eventual improvements you want to make, maybe take a step back and reevaluate. 

I am probably also 100% biased because I'm sick of writing forum solutions and fixing other peoples' forum solutions.

But I'm currently hooking a site up with Flarum, which is a little different than what I've been recommending because Flarum is an entirely separate app that's outside of the main project, and I had to integrate its authentication with the main project's. Still, to write a custom solution as beautiful, seamless, and responsive as Flarum would take me a metric ton of time.

Anyway that is certainly enough of me ranting about forums.

A basic PM system is simple. But my basic argument stands: it takes time and maintenance, and time is at a premium for small moonlighting teams. If you want to get into things like live/realtime updates, that's trickier. You could do write an AJAX solution, but that can be expensive depending on your request interval; but for proper realtime, you probably need to learn or brush up on sockets, which is time spent getting up to speed, implementing the solution, and then testing it.

I'm not sure what you mean by two tier, so I can't comment on that!

I appreciate the offer, but I've setup a couple before. When I'm learning a new web framework, I like to roll my own user authentication and authorization workflow because it touches on a little bit of everything. (Though I would never use any of these auth solutions on a live site!) My bias also comes into play here because if I never have to deal with Rails' mailer again, I can die happy.

I haven't used auditing before, but activity logs and model changelogs have been pretty vital for my workflow. (Not to mention for support on a live site! Restoring lost items is a cinch when you can see exactly where they were lost.)

Gonna skip the rest of your points because most of them boil down to the above. Just because something is easy doesn't mean it's worth the time and maintenance. I've implemented 90% of the features I listed about, as a learning experience or otherwise, and most of them are easy. Most only require one or two models and tables, basic CRUD actions, etc. But it's still reinventing the wheel! If you need a very customized or unusual solution, then that's different. Code away!

I very much disagree, but I respect that Bootstrap is not your cup of tea. I'm assuming you're talking about the HTML/CSS framework and not like, bootstrappers. Bootstrap can be a very powerful tool for teams that don't have a lot of design experience. (Back end devs are universally terrible at design, but give me something that I can use as building blocks, and I'm good to go!) Bootstrap's mobile friendly solution is eventually going to be superfluous as flexbox and css-grid pick up traction; but for now, there might not be enough browser support for those to be viable alternatives. The last software company I worked at spent a significant sum of money (a number that about made me swoon) for a UI framework and a few screens for the most important pages—and it was built off of Bootstrap 3! 

Bootstrap-based designs can look rather samey. I can usually pick out what sites are using Bootstrap, but with a little bit of custom styling, you have something decent looking for way less work than it would take to build from the ground-up. 

When I'm prototyping a hobby project, I almost always use Bootstrap, though I've taken a couple other CSS frameworks for a spin.

I'll qualify my philosophy of "Code as little as possible" with "... as long as the time spent plugging in a good package and adding in necessary features is less than the time it would take to write it yourself." If there are only a couple half-baked private message packages for your given framework, then absolutely write your own! Or if you want a "threaded" system (like how Reddit's comments work, where replies are nested), don't bludgeon an ill-fitting package into the right shape! Don't settle for something that isn't almost exactly what you need but understand the amount of effort it would take to add extra features vs start from the ground up. (Adding in post vistas? Easy. Adding a threaded post system? Probably more work than it's worth.)

This is way too long of a post, and I'm sorry if I sound like a broken record. No one philosophy is going to fit everyone's needs, but this is mine and it has served me well.

@Shinka: I was in the wrong when I posted it as I was emotionally charged. I am very sorry I took it out on you. Its my fault. I am just kind of mad at myself because I am not that good of a pet site developer. I can't even design a simple C++ game for my site, so that kind of contributed to the whole mess. I just don't have as much confidence in game development as I do in other aspects of programming. I need someone to help me out with building my first game cause i know its impossible for me to do this on my own. Can you help me out with the coding?

 

[Design1online]

In some ways I agree, but in others I disagree. One problem I've found when you work with software that has lots of packages (I currently work with one that has 200+ dependancies from other packages) is constant dependency issues and versioning problems. Also, you end up with a lot of extra functionality you don't want and will never use.

There's also the problem with security and quality and trying to link and/or reuse or re-purpose third party software within other third party packages. Take your forums example, having to modify the forums to use your own users table can be time consuming and if not done correctly can easily open huge security flaws.

It's really easy to pick something that looks pretty but is a resource hog or has really crappy security issues. I have seen the projects in code canyon that  look pretty but have scripts with really horrible XSS and SQL injection prone code. I even know of a popular one that would let people upload any file and could delete your whole database or dump it into a downloadable .zip archive.

There is certainly a benefit in having something that you've made yourself and can optimize and customize to your specific needs without all the bloat. I think there's a delicate balance between the two and you have to weigh the pros and cons of going down the dependency/versioning hell path or the DIY path. Something that's well tested, updated frequently (or completely unit tested and stable) and mature can be a good candidate for a third party package. Honestly, I would never use a third party authentication system unless I did a really thorough deep dive on it. They could easily be capturing and sending login information to their own data mining server farm you wouldn't even know it unless you went code diving or were watching your network monitoring console. 

 

[Shinka]

@Design1online

Thanks for the reply and the counterpoints! I bounced around quite a bit to address some of the points I had a lot of feelings about, so sorry if it's a little stilted.

Maybe I'm not emphasizing the important of choosing good packages enough. If it's not one of the top three results when I google "<framework> <feature>" (e.g. "rails forums") and if I can't find half a dozen Medium articles about it (because apparently every dev has one of those now), then I'm probably not interested. But even then, there's no shortage of options.

Also, 200+ dependencies sounds horrifying and is absolutely not what I'm advocating for here.

Honestly, I would never use a third party authentication system unless I did a really thorough deep dive on it.

At least in the Rails community, it's a cardinal sin to roll your own auth—and this is coming from a framework that does half the work of authentication for you via bycrpt and has_secure_password. Devise has thousands of man hours behind it and a large community of developers and users alike who have vetted the system more thoroughly than I could vet something custom. And if a new security vulnerability does come up, it'll be patched before you can even file an issue on GitHub. This is an article that I think explains the trade-offs well, specifically the "The Pros and Cons of Using a Gem like Devise" section.

Devise can get complicated if you want to customize it in a way that isn't built into the configs—but then you have gems like Sorcery that are more barebones but still have the benefit of hundreds of man hours behind them.

It's really easy to pick something that looks pretty but is a resource hog or has really crappy security issues. I have seen the projects in code canyon that  look pretty but have scripts with really horrible XSS and SQL injection prone code. I even know of a popular one that would let people upload any file and could delete your whole database or dump it into a downloadable .zip archive.

I would almost never use a closed-source package, which is what it looks like Code Canyon mostly provides. (Forgive me if I'm wrong!) If an open source package has a dozen contributors and hundreds of thousands of downloads, then I feel pretty safe in assuming that it's secure. Open source devs aren't shy with their criticism.

Of course, extremely popular packages can still have some kind of vulnerability—but writing your own code doesn't mean it's going to be free of security issues, either. And the same goes for performance concerns, etc.

But a markdown parser? That's going to be two classes and a couple dozen lines of code, if that. There's not much room to introduce security vulnerabilities—though performance could still be a concern if it uses a metric ton of regex. Then I'd pop into the issues, read a couple articles, and if no one's complained, It's probably solid!

Take your forums example, having to modify the forums to use your own users table can be time consuming and if not done correctly can easily open huge security flaws.

Both forum solutions I linked to assume you're using Laravel's standard auth (and thus a Users model), but they also provide convenient ways to change that if you're not. Thredded (the best regarded forum package for Rails) assumes you're using a Devise or Devise-like User model, but it looks like you just need to change ~3 lines of code to use a different model.

If you're using a quality package, hooking it up with your existing structure should be a cinch. I should have worded the "event hooks" part of my first post better—I look for packages that are easily extensible and configurable.

(Tying into what I said earlier, a search for "rails forum gem" has Thredded, Forem, and Discourse as its top three results. Forem is unmaintained, but that's evident both by the bold text in the readme section as well as the date of its last commit.)

Something that's well tested, updated frequently (or completely unit tested and stable) and mature can be a good candidate for a third party package.

Thank you for putting this succinctly. This is the only kind of package I'm suggesting should be leveraged. Don't just grab random snippets from Codepen or GitHub and assume they're safe.

Also, you end up with a lot of extra functionality you don't want and will never use.

This is a really good point—if a package has a dozen major features that you know you're never going to use, maybe it's not the one for you. I've steered a few people away from using full-fledged forum software like MyBB because it's way too much for what they need.

That said, definitely do consider what features you want now for your MVP vs what you might want to add in the future.

 

[Design1online]

Also, 200+ dependencies sounds horrifying and is absolutely not what I'm advocating for here.

It's not uncommon in large software to see things like this, especially if you're using new web frameworks like Angular/React/Vue, etc.

At least in the Rails community, it's a cardinal sin to roll your own auth—and this is coming from a framework that does half the work of authentication for you via bycrpt and has_secure_password. Devise has thousands of man hours behind it and a large community of developers and users alike who have vetted the system more thoroughly than I could vet something custom. And if a new security vulnerability does come up, it'll be patched before you can even file an issue on GitHub. This is an article that I think explains the trade-offs well, specifically the "The Pros and Cons of Using a Gem like Devise" section.

You're assuming that everyone is writing their game in Rails. There are lots of programming languages out there and this is not a one size fits all situation.

Both forum solutions I linked to assume you're using Laravel's standard auth (and thus a Users model), but they also provide convenient ways to change that if you're not.

If you're using a quality package, hooking it up with your existing structure should be a cinch. I should have worded the "event hooks" part of my first post better—I look for packages that are easily extensible and configurable.

I'm not a fan of things like Laravel and Code Igniter, etc. They often have more issues you need to work around than anything else and once you're writing lots of custom overrides or plugins to make it do what suits your own purposes you may have well just written it yourself.

Of course, extremely popular packages can still have some kind of vulnerability—but writing your own code doesn't mean it's going to be free of security issues, either. And the same goes for performance concerns, etc.

But a markdown parser? That's going to be two classes and a couple dozen lines of code, if that. There's not much room to introduce security vulnerabilities—though performance could still be a concern if it uses a metric ton of regex. Then I'd pop into the issues, read a couple articles, and if no one's complained, It's probably solid!

Of course nothing is perfect, I'm just pointing out that there's a balance and a trade off for doing it one way versus another. Your perspective is from looking at developing with Rails, but what if you're using Angular or Python or Go or React or HTML5? It's not a one size fits all comparison and not all languages even have events you can hook into.

You also have to take into account that third party software comes with licenses and regulations on how you can use it, not all of them allow you to do whatever you want with them which means re-selling something you've made with them can be tricky.

I'm certainly not advocating against them, I've used third party software in my own games, but doing it with a discerning eye.

 

[Shinka]

It's not uncommon in large software to see things like this, especially if you're using new web frameworks like Angular/React/Vue, etc.

I've worked on several large projects (all of which used either Angular or React) and none got close to that high! But your experience is different than mine.

You're assuming that everyone is writing their game in Rails. There are lots of programming languages out there and this is not a one size fits all situation.

I'm absolutely not assuming that. I was using Rails as an example and to make my point more clearly; I'm sorry if I did not convey that well enough. Every major web framework has a community standard auth package or has auth as a core feature (Laravel and Django, off the top of my head). If you're not using a web framework, then you're not the intended audience for my spiel, considering the major differences in plugging in a package between a framework and a vanilla language (e.g. Laravel vs vanilla PHP). I'll tack this onto the top of my original post.

I'm not a fan of things like Laravel and Code Igniter, etc. They often have more issues you need to work around than anything else and once you're writing lots of custom overrides or plugins to make it do what suits your own purposes you may have well just written it yourself.

My experience is extremely different than yours, but you do you. For me at least, frameworks have greatly improved my workflow and efficiency, and I would never willingly write a web app in a vanilla language.

You also have to take into account that third party software comes with licenses and regulations on how you can use it, not all of them allow you to do whatever you want with them which means re-selling something you've made with them can be tricky.

Which is why I am only suggesting open source software, the vast majority of which uses the MIT license. Every package I've discussed or linked to uses MIT—except for Talk, which uses the even more permissive CC0 license. I don't know the last time I saw a major package that wasn't either of those or some other flavor of Unlicense. 

(For reference, MIT and CC0 both allow private use, commercial use, distribution, and modification.)

Of course nothing is perfect, I'm just pointing out that there's a balance and a trade off for doing it one way versus another.

This has been precisely my point, so I suspect we're just talking past each other. 

Your perspective is from looking at developing with Rails, but what if you're using Angular or Python or Go or React or HTML5?

I explained earlier in this post that my perspective is not as a Rails developer (though Rails is my favorite web framework; Laravel is a close contender). The same applies for every other framework, front end or back end. Why write your own Angular pagination when you can grab a community gold standard package that does it better? Unless you need something very specific to your use case, in which case... don't! Like I've said before, devs need to weigh the time and maintenance cost of writing a custom solution vs adapting a quality package.

It's not a one size fits all comparison and not all languages even have events you can hook into.

Which is why I explained in my last post how I made that point poorly and how extensibility in general is an important metric.

 

[Anoua]

I think there is definitely a balance to it and pros and cons for each situation. But time is a limited resource, so definitely something to consider.

You are probably a bit more pro package than I am, but I do agree that they can be a great asset.

And I personally am very pro framework as well. Keeps me from having to rewrite basic functionality (routing system, authentication, and a good orm to name a few). Of course you can roll your own, but for me it's just a waste of time as what is out there is going to be better than what I can do or take way too much time which is a limited resource.

And I think packages can help in that same manor when you really don't need a custom solution. 

However I do see some drawbacks with long term maintainability. 

For example when upgrading my project (Eliyo) from Laravel 4 to 5, it was a big hassle upgrading the packages. I really didn't use a lot of packages outside of the framework, but the one package I am thinking of also had updated versions for 4 to 5, but I essentially had to rewrite that portion of code, because the versions weren't really compatible. My custom code however, upgraded without needing anything additional. 

Now I did have a couple other packages that didn't need anything, which was great, but I remember the one that did. And I would imagine this would have been even greater had I went package crazy using packages for everything.

And I mean there is no guarantee a package will continue to be maintained at all. You can of course try to get a good one that is being updated now, but if your project lasts long term, you might need to rewrite or find a different package down the road. Which is really just a pain, especially for something simple like the Online users list mentioned above. I think in that case the benefit doesn't really outweigh the long term costs. 

However, even with that said, I think they can be pretty useful and can definitely save time while still allowing a more full featured site so are definitely worth considering as an option. Also think the points mentioned of what to look for were great, especially the one about being extendable as you likely will run into something, even if minor, that needs customized.