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.
Related
I'm learning Vue, and it's ecosystem, and now I read about nuxt.js.
As I understand, this is tool which help us to build Vue apps, but don't we do the same with vite.js?
What's the difference between them?
Vite is a build tool like Webpack, that will basically allow you to work locally on your app and build it for production. It will also bring to the table various loaders, Hot Module Replacement capabilities, environment variables, assets managements etc.
Nuxt is totally unrelated to all of this. It is comparable to Gatsby/Next/Vitepress for a React/Svelte equivalent.
It's goal is to provide more capabilities to VueJS. For example, Vue can only be run as an SPA, meaning that you will not get any kind of indexing with search engines, while Nuxt do have SSR and SSG modes that will allow your websites to be efficiently crawled.
It also brings a lot of Developer Experience niceties: auto import of the composition API, of the components, simple routing, huge ecosystem thanks to all of Nuxt's modules, simpler configuration etc...
It's more like VueJS apps on steroids basically!
Also, latest version of Nuxt (v3) works with Vite out of the box. So, both of them are complementary because you need a build tool to work nowadays in the JS ecosystem + you get more features than just VueJS.
There are tools like vite-plugin-ssr and vitesse (created by one Nuxt's core maintainer btw) who can solve the basic needs of statically generating some routes/etc but it's not as powerful, have smaller communities around it and is overall moving a bit slower.
Trusting people who are behind Nuxt/Vite is also an important aspect, and most of them are well known in the community + are serious daily maintainers!
My team and I have a medium-large web application which uses Vue 1 and Vue-router 0.7.
Last days I was thinking about how I can migrate my project from Vue 1.x to Vue 2. In my opinion there are two possible methods:
Stop my web application development and migrate all the platform in
a few weeks.
Do an incremental migration. Some componentes will use Vue 1 and
other components will use Vue 2.
CONSTRAINTS of each option
I can't stop my web aplication because It is stable in a production
environment and I have to add features and fix issues.
I did satisfactory tests with components using Vue 1 and Vue 2. The
problem is that It is not possible to use same Vue-router version,
so I can't share routes and navigate between components...
The best option for my web application could be doing an incremental migration but...could It be possible?
Thank you for everything!
I think it is possible.
The key thing is we have to make sure Vue 2.x and Vue 1.x are able to pass data to each other, and the reactivity should work to avoid complicated blocks of code.
I've made an example here: https://trandinhkhang.github.io
About Vue router, I think we can watch for a property and then do a router.push("some-url") in both Vue Router Vue 1 and Vue Router Vue 2 to navigate. Etc.
My company have the same troubles as yours and migrating a monolith into new platform is hard and seems impossible. Lolz. Incremental migration still the best option here.
VueJS 1.x and 2.x is totally different. 2.0 is written from scratch. VueJS have an awesome migration helper which can be used and it will do lots of work for you.
Read the following migrating guide: https://v2.vuejs.org/v2/guide/migration.html
I am not sure who gig your app is but it should not take more than 2 days for a medium size application.
Here are few points from their official doc:
Where should I start in a migration?
Start by running the migration helper on a current project. We’ve carefully minified and compressed a senior Vue dev into a simple command line interface. Whenever they recognize an obsolete feature, they’ll let you know, offer suggestions, and provide links to more info.
After that, browse through the table of contents for this page in the sidebar. If you see a topic you may be affected by, but the migration helper didn’t catch, check it out.
If you have any tests, run them and see what still fails. If you don’t have tests, just open the app in your browser and keep an eye out for warnings or errors as you navigate around.
By now, your app should be fully migrated. If you’re still hungry for more though, you can read the rest of this page - or just dive into the new and improved guide from the beginning. Many parts will be skimmable, since you’re already familiar with the core concepts.
By the way, You should not upgrade the app incrementally, In my experience, it will be total mess.
As an opensource .Net ECMS, Sensenet seems to have a lot of features, anyway in their developer blog, it seems they are working for an SN7 version with more goodlooking UI.
Do you have any info, when it will be released?
Yes, we are working on SN7 for some time now. Part of that work is to partition this huge product into smaller components. The plan is to release the core layer, the Content Repository (without UI) on github soon. After that the rest will follow gradually, as optional packages. The main focus now is on the platform with an easy-to-use client api.
I want to have Meteor as a server and Ionic2 as a client. I currently have a headache with authentifiacation. It seems that there are two different approaches:
First is use of Meteor server and Meteor client with ionic-angular library. This approach described here
https://angular-meteor.com/tutorials/socially/angular2/ionic2
I guess the advantage of this method is use of Meteor native architecture, on the other hand I guess we're using Ionic2 just like a subframework and maybe loosing some stuff from native Ionic2.
The second is using separate Meteor server ('client' folder deleted completely) and native Ionic2. This approach described here
https://angular-meteor.com/tutorials/whatsapp2/ionic/authentication
This option is vice versa: use of native Ionic2, but it has to use libraries like meteor-client-side, accounts-base-client-side, accounts-password-client-side etc, which I'm not sure are native for Meteor.
The first approach looks better, because there is a ready-to-use UI component for authentification. But I wonder what issues I would have, when I come to the step of completing my applications for different types of devices.
Thank you in advance for your help.
These approaches are essentially the same for the authentication itself.
What you are pointing out is more about what mobile platform to choose to develop and run mobile projects.
In the first case, you use Meteor's built-in Cordova platform to run the app and Meteor's compiler and bundler plugins (like TypeScript package or Meteor core packages for Babel and UglifyJS etc) to develop the app. In the second case, you develop and run the app solely on Ionic 2 CLI.
But from the app logic point of view these approaches are absolutely same: you import the same Ionic 2 components and use the same Meteor packages with the only difference in the second case is that these packages are now NPMs not Atmosphere ones (essentially though they contain the same scripts since these NPMs are built from Atmosphere packages).
The reason why What’sApp clone is built in that way that differs from the Socially’s one is simply described in the README of
the What’sApp repo (see https://github.com/Urigo/Ionic2CLI-Meteor-WhatsApp). If to repeat: since Ionic is a one of the best Web frameworks that specializes solely in building mobile apps, it’s reasonable to guess that it’ll be (and likely it is) much more powerful in building them than Meteor itself. From that point of view the second approach seems more future-proof, I would say. You could think even of building your project in some way that will allow you to substitute Meteor easily with some another framework if you decide to use it at some point in the future.
If you are though concerned about using those NPMs mentioned in the second case (e.g., if the process of building them doesn’t look transparent to you), you could try this project https://github.com/Urigo/meteor-client-bundler to bundle Atmosphere packages you need into separate scripts and use them after.
I've been developing in Aurelia-CLI for about 3 months and like it so far. I think it's a solid framework and obviously escalating in support and usage. That's a good thing!
Before I develop much more of my large app, I'm wondering if I'm using the best build system. I've only tried Aurelia-CLI and am not really familiar with Webpack or JSPM, and therefore I don't know what I'm missing. Are there any clear advantages or disadvantages in using either of the other two build systems, or is using the CLI the most clean and supported approach? Since I'm developing independently, I don't have any external constraints.
Thanks for your help.
UPDATE
This answer is almost two years old. Feel free to research updates and provide another more complete answer and I can replace this answer or point to that answer. Thanks!
Aurelia CLI
Aurelia CLI is great for getting started. It's important to understand that under the covers the CLI is using require.js but proxies the configuration through aurelia.json in your application. This means that you need to understand how to configure aurelia to work with require.js at the moment. Once you need to start configuring to match your workflow or change build steps up it gets a bit cumbersome at the moment. We are working to improve this. There are many features planned for the Aurelia CLI but given at the time of writing this that it is in an alpha / beta state it should generally be used on proof of concept or other smaller apps, not production-ready large scale apps yet.
WebPack
WebPack is arguably the most popular kid on the block at the moment. WebPack is not a module loader, but a bundler. It's important to understand this because while we strive to make Aurelia work great with all module loaders WebPack by default is not in charge of loading modules so a dynamically loaded application requires the developer to expand on this. WebPack is strong in creating optimized bundles and can be easy to use as long as you are comfortable with configure WebPack. WebPack has considerably more GitHub stars due to the popularity from React using WebPack it's hard to say whether the choice is better when using Aurelia simply because of the number of GitHub stars.
JSPM / System.js
Some of the skeletons use JSPM and System.js. The reason is that these are the closest to 'spec compliant' solutions. JSPM tries to help as much as possible when loading from the JSPM registry. If not yet available in the registry you can load from NPM or GitHub directly. From a module loading perspective you use a config.js file that is (usually) automatically maintained when installing dependencies to improve the developer workflow.
Side biased note
On most larger apps at the moment I typically prefer using JSPM / System.js simply because I have a great understanding of the tooling and prefer the control that I am provided. I work on a great number of Aurelia apps that are in production and typically reserve CLI for smaller proof of concept apps and WebPack is a great alternative but I prefer the flexibility and understanding I have with JSPM / System.js at the moment.
The CLI isn't currently feature complete, but it is a much simpler setup. Webpack can basically do anything you want to do, but you'll be maintaining your webpack configuration just as much as you maintain your Aurelia code.
Ok, maybe not just as much, but you'll have to learn Webpack to use webpack. The Aurelia CLI is simple to get started, but has some definite limitations. For example, CSS files that reference external resources won't work w/the Aurelia CLI, but they should work fine with Webpack.
First, I can understand if this post gets shutdown due to its subjective nature.
I believe it's time to re-visit the answers about Aurelia CLI being a second-class tool. I respect both PW Kad and Ashley Grant immensely, but I am just not convinced that a statement like this is true anymore:
There are many features planned for the Aurelia CLI but given at the
time of writing this that it is in an alpha / beta state it should
generally be used on proof of concept or other smaller apps, not
production-ready large scale apps yet.
Notably, I have a production application that way back in the day I started with Aurelia CLI, and changed it to JSPM precisely for the reasons noted. But recently, I rebuilt the same app from scratch using the CLI and I realize that it is much easier to use, particularly managing modules and publishing! And this is an app with Google Maps, Google Analytics, Auth0, DevExpress, Bootstrap, etc.
Just think it is time to give Aurelia CLI a little love. It's ready.
Aurelia CLI is the most preferred option with this announcement.
http://aurelia.io/blog/2017/08/18/aurelia-cli-webpack-update/
Now It has more flexibility for your choice of preferences.