To use this service, you check to agree to terms which include this:
"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).
There was no longer a time when we changed terms. Our company provides content creator sites such as Bufferwall.com and other blog post apps for blogs (therefore those conditions). But we will update the terms this month by adding some clear exceptions for UI Builder, cloud services, etc.. That's not clear for all. We will get it clarified.
I don't understand what's the difference, will still be horrible have all the thing I do used without consent in a pay service. I dont want to have my security bulneravilities(when not if) being show in mockup of functionality, or have the code of my servers used whiout my consent I feel a paid marketplace could be a better way to monetization, or a way to share explicit, If not you can clone all my company code whiut warrant, or say that mY assets are yours.
> 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.
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.
This type of license is generally required for a service to operate. They could scope it more carefully, but there is nothing _necessarily_ underhand going on here.
> 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.
What's missing is the limitations on how they will use it. They need some license for all of the things listed, but this is the maximum permissions rather than the minimum
When I see low-code, I find myself looking for the Visual Basic of Web. If I could drag and drop a few pre-made controls (including a database control), double click to handle a few events, and have a CRUD app, I would be thrilled.
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.
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.
Not related with Illa. Entire different software. I believe it would be the next big thing because of the rapid features they add in compare with other tools.
Hi - PM from Retool here. Have you tried our product? Should be super easy ~5 min to spin up a table + form CRUD application for your database tables. Plus, we can be deployed on-premise with SSO and source control.
The demo video including writing (or customizing) SQL + doesn't seem to have any sort of graph/node interface at all. How is it related to Total.js / Node-RED? Seems to be a completely different tool.
That's possible with Total.js. We offer a lot of open source apps like Flow, UI Builder (it will be released soon officially - missing only the website) and Total DB (it will be released this week - missing only the website).
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!
Node-RED is really tough for Bun to support because it relies on sloppy mode features like implicit global variable assignment (assigning a variable without var/let/const) and Bun currently treats every file as ESM (and transpiles CJS for compatibility)
For Bun on workflow builders, I'm currently working on making windmill [1] supports bun as an additional runtime to run the typescript scripts/steps. It's not the same as making the workflow engine run with bun (we use Rust) but I thought it might be worth mentioning :)
docker compose up and you're gtg.
We also have helm charts and it can also run from a single binary and a postgresql url. Everything is documented on windmill.dev
I’m still wishing for it to work somehow - either by someone cleaning up Node-RED or by bun being more toleran - because it would be amazing (and very, very useful) to get it working…
This is an extremely cool project, but after browsing the source code a bit, it looks like it's badly in need of modernization.
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);
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.
The code isn't terrible, but it's not clear to you because you don't have the necessary information. The Total.js UI library (jComponent) is now 50% backward compatible with the UI library that you opened in 2014! You must know that we want to keep long-term backward compatibility. It's not a 100% nice code and of course, we will release a new version v20 (of UI library) this or next year cleared from the older code. We must offer stable tools for development, and that's critical for us and our customers.
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 think the project is very cool, and I'm impressed with the amount of functionality it has.
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.
Why can't code just be old? If it's stable, sustainable, and able to deliver on customer needs, then who cares? The only benefit at that point be to prevent people nitpicking that their code uses "var".
In most cases, I'd agree with you - but I think this one is a little different since the customer is a technical implementer building a product.
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.
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".
> This is a problem for many reasons, security and maintenance among them
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".
Bootstrap 3 isn't just CSS, though the project author has stated they only use the grid system, so I don't see a security concern with that, just a maintenance one.
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?
> I don't think any developer would be excited to put "Bootstrap 3" on their resume today
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".
Does anyone know if they are using any UI toolkit for the nodes/edges blocks or have they built it themselves? I am looking for something something similar but for different purpose, just the ui toolkit without any logic built on top of it
JointJS is quite great for that: https://www.jointjs.com, even with the community version https://www.jointjs.com/comparison => we have built some node ui with it and it has been fast, flexible and extensible; maybe not easy to start with, but it was worth it
The registration form is the first obstacle that turns you off. SMS for a confirmation? Sure, let me pull my number in this - the SMS never arrives. Why use SMS in the first place? From the user perspective, it seems like you're following your own ideas that might be quite far from the conventions that exist for a reason.
Total.js Flow is an excellent and modern Visual Programming Interface for low-code development. It's a viable alternative to Node-RED and fully open-source under the MIT license.
Except for Total.js API service, payments and Cloud, all parts are open-source under MIT. All of our projects are under the MIT license, but some projects are considered private.
With no offense intended, I've never heard of it, but.
I would say, compare Luna Park with node red and compare the difference with total. Because this application is an alternative to Node Red.
We did a ton of free components and apps, and we have been doing it for 10 years.
- More than 10 apps
- The number of UI components exceeds 300
- The number of flow components exceeds 100
- More than 60 components in UI Builder
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!
It's very valid to sell premium blocks/packs. It's really amazing to have all the rest in the MIT version open-core. Thanks for that and don't be demoralized by some comments, we don't all think the same.
Somewhere else in this thread I asked for the list of licenses as I see most of these products keep the parts with the most work closed or under a license that many companies won’t touch (agpl or n2n license). It seems that almost everything is MIT; that is pretty refreshing for something like this. Check alternative solutions and you’ll find trivial parts open sourced and the hard parts proprietary or unusable in other software because of the license choice.
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
Our team is currently working on the Total.js Enterprise service, which will provide all premium content (Private Cloud, Flow + UI Builder, CMS widgets, CMS templates, etc.). We are offering these components for testing purposes for some members. The price will be appropriate and not excessive. If someone wants only some parts, we will be able to sell them independently.
Feel free to email me or contact me via Telegram: https://t.me/petersirka if you want to use some special Flow components.
"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).