That's actually not true. Moving from V2 to V3 is pretty simple, there are only a relatively small number of changes. However, V3 introduced great new features that projects like Vuetify and Bootstrap want to take advantage of. So it's the choice of those frameworks to rewrite how they use Vue in order to move to Vue 3 instead of porting what they have.
You apparently happen not to like Vue, but that doesn't change the fact that it's one of the two most popular web frameworks and has been stable for many years now.
Well, if it weren't, I'm sure we would have seen a faster migration - but we haven't and bootstrap-vue still only has experimental support for Vue v3 and I couldn't get it working. It is far from only me whinging about this swap. It has caused issues for a lot of people.
No, that isn't at all true. I chose Vue to be the main support library for people who had minimal HTML experience but who wanted more than Dashboard could easily offer. There were some very important reasons I did that. Most of them revolved around the fact that it was vastly easier to adopt for people with minimal front-end development skills than the other mainstream frameworks. And that it didn't force you to use a build-step, even their documentation allowed for non-build use and examples.
I also chose bootstrap-vue to go with it because it massively extended Vue and gave a decent out-of-the-box layout and style - again without any need to do a build step. Was well documented with a useful set of components.
What I don't like is that the Vue project has followed the path of so many frameworks over the years in that they have taken a massive leap in complexity. Making it much harder for people to get started. That large change has also disadvantaged many open-source developers who have limited resources to adjust to such big changes.
It is this thinking that has led me to focus ever more on vanilla HTML (and incidentally also keeps me from switching to TypeScript). While HTML, CSS, and JavaScript are going on their own awkward journey's of complexity, they remain the "vanilla" choice around which everything else is forced to revolve.
Therefore it is much less likely that I and uibuilder users would one day wake up to find that a major rebuild is forced on us due to breaking changes. I think that if I hit that wall, I might have to give up because I don't have the time or energy. So I'll avoid it as much as is possible.
Node-RED's big driving force is its ability to lower the "cost" of entry to developing complex data processing. One of uibuilder's driving forces is to try to do the same for creating data-driven web UI's. The use of standardised data schema's that follow HTML, the use of nodes that output standardised data configurations and a single module that converts the data to HTML. All without the user needing to worry about it - unless they choose to, and if they do, they will be using familiar concepts that lead them to vanilla HTML. Skills and knowledge they can use as a foundation and that are reusable anywhere.
People using uibuilder don't need to learn a new framework (but can if they choose to). And gradually, I'm reducing the need to know HTML - though without locking people out from learning since uibuilder can now create HTML - which you can then save and reuse if you like. So just like Node-RED provides a back-end node.js environment, uibuilder provides a front-end HTML/CSS/JS environment.
Well it was. And then it wasn't. The downside of frameworks.
By the way, if we want to continue this discussion, can we please move it to another thread so that this one isn't hijacked. Thanks.
I think you're confusing whose fault it is. The required changes from Vue 2 to Vue 3 are minimal. I did them in an hour for FlexDash. If you google about migrating from Vue2 to Vue3 it's really little and easy.
For Vuetify the "porting" took a long time because the Vuetify team decided to rewrite to take advantage of the new features in Vue 3. They opted not to just port to Vue 3, they opted to rewrite. You can't fault Vue for offering new features and another team choosing to rewrite.
I don't track bootstrap-vue, but I suspect the same is happening. You are faulting the wrong project. Vue has been incredibly stable for over 6 years.
I'm sorry, but your are mis-representing the facts. Vue 3 is actually not more complicated than Vue 2, as far as I can tell the implementation is simpler.
Also, it is patently false that it is harder to get started with. The full Vue 2 API remains there, so the same code still works. There are just some minor changes having to do with what's global and what isn't. This is something a beginner doesn't notice at all (as long as they use the right getting-started boilerplate).
The Vue 2 style "options API" is also not a second-class API: the Vue team has stated clearly that it's there to stay because it makes it very easy to learn Vue. The lower level "composition API" introduced in Vue 3 is there for more advanced projects, and in particular UI layers like Vuetify and Bootstrap (which is why they chose to rewrite their stuff).
Therefore it is much less likely that I and uibuilder users would one day wake up to find that a major rebuild is forced on us due to breaking changes.
This is a funny one:
Vue 2.0 was released in 2016. It still works great. Moving a project to Vue 3 is a breeze and there's no forcing function to do the move 'cause Vue 2 is still well supported.
Vue 3.0 was released in 2020. It still works great. It is still current. The Vue team has stated that they are not working on a new major version. So we're not looking at a move to 4.0 coming up real soon.
UIBuilder 5.0.0 was released april 2022, UIBuilder 6.0.0 was released december 2022, the front-end library changed, major changes in functionality, the recommended way to build a UI changed, the way to use Vue changed, the ui_cache changed, and more. Looking at the UI builder evolution over the last year alone shows that everything is still changing quite dramatically.
Look, I like that you develop UI builder and I wish you all the success. I really do. Node-RED is about openness and flexibility and it's good for everyone to have multiple web interface options.
However, I really don't appreciate when in practically every post of yours you piss on other projects about stuff where the facts actually point in the other direction.
I don't intend to get into an argument over it as it serves no purpose. You have a different perspective on Vue - possibly because you use it a lot maybe? But it would be better to perhaps acknowledge that other people's perspective and experience may be different rather than "patently false".
The old library still works. The new one has mostly the same basic features. Nobody is forced to change. And they won't be for the foreseeable future. The new library requires less boilerplate code but fundamentally works the same way as before. Old code still works.
Not really, there are new options, the previous ways still work.
It is indeed but the old stuff still works just fine.
v5 to v6, the only real major change was the jump from node.js v12 to v14 in line with Node-RED itself. This doesn't need new code or changes to flows.
I really don't think you are reading many of my posts if that is what you think. So please don't make unwarranted accusations. Not helpful to anyone. The rapid move of the Vue project from v2 to v3 has annoyed many people, that is demonstrable and searchable fact. It has caused much confusion for people trying to use Vue with uibuilder, also demonstrable fact. I still like and use Vue, also fact. And uibuilder still has more examples - for both v2 and v3 than any other framework. So I absolutely see both the strengths and weaknesses of it as a tool. But the world moves on.
I will continue to explain to people who get caught out by the move why it has happened. I will also explain to people why I've moved away from frameworks and am trying to expand what uibuilder can provide without them. Vue happens to be a useful explanation point as is the evolution of Angular and some other advanced frameworks.
I am a great believer in open standards and open data and this shapes the development of uibuilder. But there is plenty of room for different tools to be added to Node-RED, providing different capabilities for different use-cases and different styles. I will also continue to advocate the best tool for a specific use-case whether that is one I've developed or one that someone else has - just as I have for over 10 years now.
