Show HN: Total.js – Low-code development (Node-RED alternative)
totaljs.com
totaljs.com
"By posting Content to the Service, you grant us the right and license to use, modify, publicly perform, publicly display, reproduce, and distribute such Content on and through the Service. You retain any and all of your rights to any Content you submit, post or display on or through the Service and you are responsible for protecting those rights. You agree that this license includes the right for us to make your Content available to other users of the Service, who may also use your Content subject to these Terms. You represent and warrant that: (i) the Content is yours (you own it) or you have the right to use it and grant us the rights and license as provided in these Terms, and (ii) the posting of your Content on or through the Service does not violate the privacy rights, publicity rights, copyrights, contract rights or any other rights of any person."
If I read this correctly, it is saying that our IP and content we provide (config, nodes, data, etc.) still belongs to us, but they can also use it however they want.
Doesn't this seem a bit extreme? It seems like it could mean zero privacy of the work we do (content added).
A great many services have similar stipulations. This is similar to how GitHub was OK to use all the public repositories on its service as training fodder for copilot. Though there are ongoing arguments as to how this applies to code someone else uploaded: they didn't necessarily have the right to assign those rights to GH so the legal status is less clear than their terms of service might suggest.
Microsoft asserts that it had the right to do this under Fair Use, not the Github user agreement.
> By posting Content to the Service, you grant us the right and license to use, modify, publicly perform, publicly display, reproduce, and distribute such Content on and through the Service.
This says you grant the service a license to store and run your content.
> You retain any and all of your rights to any Content you submit, post or display on or through the Service and you are responsible for protecting those rights.
This says you still own your content and responsible for how it is shared. You only gave the service a license.
> You agree that this license includes the right for us to make your Content available to other users of the Service, who may also use your Content subject to these Terms.
This says you give permission for the service to make the content available to others. It does not mean the service will. This part could be worded better. It is presumably linked to sharing or publishing functionality.
> You represent and warrant that: (i) the Content is yours (you own it) or you have the right to use it and grant us the rights and license as provided in these Terms, and (ii) the posting of your Content on or through the Service does not violate the privacy rights, publicity rights, copyrights, contract rights or any other rights of any person.
This part says you're not infringing anybody else's rights by putting content into the service.
So, yes, they could possibly have made it clearer in the license under what circumstances they would make content available to others, but most people don't look to the license to understand that so it's not uncommon to have language like this.
Truly we are in the dark ages of open source when everyone believes they are entitled to be a monopoly platform.
Starting to sympathize with stallman more every year.
Unfortunately, I still have not found that yet.
Total DB: https://github.com/totaljs/totaldb UI Builder: https://uibuilder.totaljs.com/
We're preparing tutorials and you will see that it's possible to do it very easily :)
Of course, we have some premium components (under the MIT license) that are hidden. Also you can create Flow components directly in Flow, that's amazing!
You could check Budibase, I build a simple customer portal for one of our customers with it.
Now I build a "real" project with Supabase for the backend and Vue.js + Quasar for the frontend. And that comes damn near this vision. Only a dragn'n'drop GUI editor is missing, but with the near zero reload-times of modern vue.js with Vite editing the GUI in code comes near.
There are of course several "frameworks" for Delphi, that offer "building webapps with Delphi and then compiling it to JS & Javascript, but I decided not to go into this direction, because Delphi paradigmns are no good fit for the web and I doubt I'm gonna find anyone else if I'm going to need more manpower.
For Delphi:
* TMS Webcore https://www.tmssoftware.com/site/tmswebcore.asp
* uniGUI http://www.unigui.com/
Delphi Inspired Pascal IDE for the Web:
* Elevate Web Builder https://www.elevatesoft.com/home
* Quartex Pascal https://quartexdeveloper.com/
* Smart Mobile Studio https://smartmobilestudio.com/
I've been giving Storybook[1] a shot to solve this problem. Works pretty well from scratch on new projects, but importing existing Vue components, especially from large third party component libraries, has proven a little onerous so far for me. But maybe you'll have a little more luck with Vue/Quasar.
Would love to hear what you think!
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:
var n = t.getAttribute('name') || '';
if (!n)
return;
var p = t.getAttribute(T_PATH) || 'null';
var c = t.getAttribute(T_CONFIG) || 'null';
var d = t.getAttribute(T_DEFAULT) || '';
var s = '__';
var meta = n + s + p + s + c + (d ? (s + d) : '');
t.$jcwebcomponent = true;
compilecomponent(meta, t);
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.
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".
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?
Just wait until I tell you about the code in your OS, your car, and your phone...
At a glance it looks good, but unclear why one would switch.
- better design collected from our Web components https://componentator.com
- without third party dependencies (in the core)
- online chat support with authors and contributors (https://t.me/totaljs)
A lot of (open source) helpers like
- UI Builder https://uibuilder.totaljs.com (released soon),
- Total DB https://github.com/totaljs/totaldb (released soon),
- OpenMail, OpenTemplates, OpenAuth, etc..
>The main parts of the Total.js Platform are fully open-source
That implies that parts aren't open source?
Mmmm. Guarantees I'll never touch this.
Internally, we have 9 people in full-time employment, they need salary. As a result, we would like to sell some premium components in order to earn money for the next development, but that's a terrible idea according to you. Yeahh, you are really crazy!
A proprietary software house that releases some free software is still a proprietary software operation.
Kudos to the team of total.js. Who cares if they offer some paid stuff; because of the MIT license anyone can. If they don’t do it, someone else can and offer it all the same. As long as vital parts remain MIT, I cannot see how this is a proprietary software operation.
Tl;dr I agree with you, but I don’t see that being the case here
Feel free to email me or contact me via Telegram: https://t.me/petersirka if you want to use some special Flow components.