> there's liberal use of "var"
> The components implementation is very pythonic - it passes "self" around to decorate with functions
Could you explain why these things are bad, other than "it's not the hip and trendy way to do things"?
Using Bootstrap 3 is a problem because it hasn't been supported for over three years and is no longer actively maintained [1]. This is a problem for many reasons, security and maintenance among them.
The use of var has long been understood to be problematic due to footguns with scoping issues. It's the reason "let" was introduced into the language, and is pretty much exclusively used now.
The pythonic approach isn't a problem per-se, but it also introduces additional complexity which makes maintenance more challenging.
From an organizational standpoint, it's difficult to attract and retain good talent to work on dated code. I don't think any developer would be excited to put "Bootstrap 3" on their resume today. If you can't attract and retain good talent, your company and project will suffer.
Software is like a house, there are many complex systems that need periodic maintenance and updating. Sometimes you can remodel the house to get rid of the aluminum wiring, etc... and modernize it. Sometimes it's cheaper to tear down and rebuild. But I don't think anyone would argue "Well, it hasn't fallen over yet so just leave it".
Would anyone put Bootstrap 3 specifically? Using a newer version is not a massive difference. You'd also put "Ruby" on your resume, rather than "Ruby 2".
How exactly are those problems with Bootstrap 3? Security, in a CSS "framework"?
If it works, it works. You don't have to update everything to the latest version to get some sort of "easy to maintain" badge, things don't change quickly enough for that to make sense. Picking one version and sticking with it is a valid choice for "maintenance" as well as saying "we're gonna be on the latest version within N weeks of release".
I'm deeply confused by your points and similar arguments I've seen in this discussion.
This is an actively maintained project with regular new releases, not some legacy product languishing in maintenance mode. We're discussing it because it was just on the front page of HN.
I find the arguments that the code doesn't need to be maintained, updated or modernized utterly bizarre.
Have you reviewed the source code?
I have.
It doesn't take very long to see that it diverges significantly from current best practices. The code base is difficult to follow, at best.
Would you argue also that the liberal use of global variables and functions throughout the framework is a good idea? And combining that with a home-grown routing and controller framework instead of using express or something similar makes sense?
It may have when this was originally written, but even I (with my NIH leanings) understand the benefits of using battle-hardenend libraries for core functionality, and the dangers of ignoring the module system and polluting the global namespace.
I'm not trying to nitpick flaws, my point is that the project as a whole needs to come up with a plan to update and modernize the code base moving forward.
With projects like node-red, supabase and Directus as competitors, allowing code to rot is going to prevent new adoption.
We're also not talking about some ERP that just needs to be "good enough" to get the job done.
This is a technical platform for technologists. To use to develop new products.
How can an argument supporting code rot possibly make sense here?
Are you going to select this framework for your next project in its current state?