This platform has been developed for around 10 years, and it isn't easy, but we will keep doing this since it is our hobby.
I do think there's a considerable burden of technical debt in the current code base right now that the company will need to develop a strategy to address, which is absolutely normal for a project of this scope and age.
It's a tough challenge, one I've faced several times.
Given the clear technical talent I see with the project, I have every confidence that it's a challenge that will be overcome, and I'm looking forward to watching the project and seeing how it progresses.
For some use cases, I think it would be fine - internal tools that need a quick and easy solution, perhaps.
But I don't think anyone feels great about building a product on an aging foundation.
Would you select Angular 1 as a UI framework for a new project today?
Also, I think it's hard to make a good argument for single letter variable names, except in very rare cases. Unfortunately, in this code base their use is the norm rather than the exception.
> 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".
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?
Just wait until I tell you about the code in your OS, your car, and your phone...
CSS is Bootstrap 3.
The docs reference Web Components, and I do see the use of customElements.define() so (I think?) it's using "real" Web Components technologies, but the code is indecipherable to me:
Note, this isn't the minified version, it's straight from jc.js, not jc.min.js.Looking through it, most of the code is like this, and there's liberal use of "var". This isn't a cherrypicked example. It looks like it was originally written about six years ago, and I see active commits, so it's really confusing to me why the code base would be in such rough shape.
The components implementation is very pythonic - it passes "self" around to decorate with functions, it doesn't look like it's been modernized to use classes.
From a features standpoint, the project is very cool. My concern with choosing to use it in a production app is the enormous amount of very obvious technical debt that I'm seeing.
At some point, this will either need a major overhaul and rewrite (an extraordinary effort for a project this size), a dual-implementation support (like react and a few others did, with class based and functional APIs both supported) and a long, slow reimplementation path, or a decay into obsolescence as the core frameworks becomes hopelessly outdated and difficult to maintain.
That's a really difficult technical position to be in, and I sympathize with the challenge ahead. Clearly there are very talented developers working on this project, I'm looking forward to seeing how they solve these issues moving forward.