What is the support for Dojo community support for Dojo 1.8.1 framework?
Our application use Dojo 1.8.1. What is the impact if we are advised to move to the latest framework ?
Dojo 1.x is pretty much "dead" in the sense that only minor maintenance is done.
Migrating to Dojo 2.x or higher from 1.x is not easy, as there is no out of the box migration path.
Of course you can wrap your Dojo 1.x widgets in Dojo 2.x, but then what's the point of using Dojo? Then you can also use another (more widely used) framework.
I don't want to bash on Dojo, as we use it extensively (and successfully) in our company, but the fact that there is no easy migration path to Dojo 2.x makes us want to transition into a more common framework eventually.
More information can be found here: https://github.com/dojo/dojo.io/issues/153
Related
I'm maintaining a library (MyLib) published on npm that is a vuejs plugin. When I started this library, vuejs was at major version 2.x.x. vuejs now has a new major version 3.x.x that changed how plugins work.
Both 2.x.x and 3.x.x versions of vuejs are supported and will be for a while longer. I want my plugin library (currently version 5.x.x) to be available and supported for both.
Options I've seen or considered so far:
Have 5.x.x as the last version that supports vuejs#2 and 6.x.x and above for vuejs#3.
Easy enough
Doesn't allow me to release a new version with breaking changes that supports vuejs#2 ever if I follow semver rules.
Create a version 6.x.x of my library that supports both versions of vuejs.
Potentially possible, depending on the specifics.
Makes my library bloated because it needs to support both versions of vuejs and have (flaky) runtime version detection to choose the right code path.
Publish a separate library (e.g. MyLib-v2) that supports vuejs#3. Can possibly use a scoped package, but that would force users of 5.x.x of my library to change their dependency name with very poor discoverability.
Not sure how to manage this in a single repo. Monorepo?
Clunky, higher overhead
Is there a better way, or at least a not-awful way of managing publishing my library in this seemingly common scenario?
Use vue-demi. It lets you publish for both vue2 and vue3 in the same project. When using vue2, you have will access to the composition api as well.
https://github.com/vueuse/vue-demi
From the read me:
Vue Demi (half in French) is a developing utility
allows you to write Universal Vue Libraries for Vue 2 & 3
We are working in an environment where the overall web application is maintained by a core team, but developers internal and external use the frameworks and tool to develop on the application.
If the frameworks used are not backward compatible, overtime it will be impossible to upgrade the systems as other developers used frameworks to develop (old versions for example).
We would like to choose a modern JS framework, thinking a bit more serious about Vue.js.
Can anyone share thoughts about Vue.js roadmap and upgradability of the framework as it goes to V3, V4, etc?
Is the core team's mission to keep it the new versions backward compatible? not to break any APIs offered in the previous versions, etc?
I and my team have been using Vue.js for quite some time for almost 2 years. Before that, we used Angular for 4 years.
I can surely say that future Vue.js will not be fully backward compatible with past Vue. This was true when v2 was released. In fact, this applies to any major JS framework out there. Most of them will not be backward compatible. Look at Angular, Hapi, Koa, Rx.js, etc.
There is a good reason for that. JS is evolving in ways you or me as a single person cannot comprehend in one go. Not all browsers support all features. Web components are coming since 2015 and still a way for them to reach a general consensus. For example, in case of Vue 3.0, the idea is to use ES proxies that will probably be backward incompatible. As web components get adopted by browsers, the idea of Vue.js component will change and it will again be backward incompatible.
Having said this, Vue.js is unlike any other framework out there. The core team is trying its best to preserve core framework compatibility. What happened with Angular 1 -> 2 or Vue 1 -> 2, there is a least likely chance of that happening
As long as you are using Vue public API, you should be good. The transition if any will definitely be smooth, less head-spinning and you will have a clear upgrade (read as - temporarily compatible) path.
Graceful evolution is one of the reasons why we are using Vue as our large-scale application framework.
I am using a php dojo v1.4 project with mysql as backend.
The UI looks very basic.
I need to migrate this project to a standard bootstrap admin theme.
What are the steps I need to do?
If backend and general architecture of your application will remain the same, I'd suggest you to start building new UI from the scratch. When it finished, write missing functions, which were previously implemented with dojo using jquery (which comes with bootstrap) or whatever you like.
I assume, that you are not going to use dojo anymore.
If you are facing some specific difficulties, you'd better provide more details in your question.
Is it possible to use a kind of no-conflict (like in jQuery) with two versions of the Bootstrap (2.x and 3.x) on a page?
The question has arisen because of the lack of compatibility of the Joomla 3.6! with the Bootstrap 3.x and intensive usage of the Bootstrap 2.3.2
There is idea to use customized, namespaced version of Bootstrap 3.x. But is that idea viable?
Note: there is solution with template overrides. But it uses a lot of files for overriding and I have to use all of them for each of my 6+ templates
I'm working on a cross-platform solution currently. The solution uses XmlMtomReader and XmlMtomWriter from .NET framework 3.0.
Now i need to know if these two classes (and all the nessasary infrastructure around them) are fully supported in Mono project from the porting-it-to-linux point of view. :)
You can check it on the mono status:
http://go-mono.com/status/
You can also check your code using the mono migration analyser
http://www.mono-project.com/MoMA
I checked they are currently not implemented
The APIs are available on the current Mono 2.6 preview, but they are not available on the 2.4 release (the current official release).