I have few queries related to the EOL of VueJS 2:
From Wiki link here:Vue.js - Wikipedia , I learn that Vue2 is having EOL in Sep 2023. Is this correct?
Where can we find the Last minor version of Vue2 i.e 2.7 as mentioned here ? If we will start using 2.7, how long it would help us to buy some time for migration to vue 3?
We have VueJS2 application and if we fail to migrate to Vue3 due to some reasons before EOL(using migration guide here: Introduction | Vue.js), What will be the impact?
Will we stop getting any security updates? OR Can we still expect critical security updates?
I hope we would still continue development using VueJs2 and npm install would continue to work for dev environment setup? Are there any chances of one or more dependency stop getting downloaded? (for example node sass etc?)
Are there chances that as the browsers will continue to update to the latest versions and cause some functionality in VueJS 2 stop working and we wouldn't be able to complaint since it’s already EOL?
I believe since no upgrade will happen to VueJS 2, we wouldn’t be able to expect any support for new features in browsers. Is it correct?
Your response will help us to understand and plan the things much in advance.
Will we stop getting any security updates? OR Can we still expect critical security updates?
EOL usually means the same thing on any ecosystem. It stops getting updates to allow moving on to the next thing. It'll still work but it's going to be just like that unless someone continues maintaining it in some way.
if we fail to migrate to Vue3 due to some reasons before EOL, What will be the impact?
You stop getting updates.
Vue component/libraries/plugin developers might write less Vue 2 code and more Vue 3.
If they wrote a Vue 2 code then use that. If there's none, you write one.
I hope we would still continue development using VueJs2 and npm install would continue to work for dev environment setup? Are there any chances of one or more dependency stop getting downloaded? (for example node sass etc?)
You can still continue working on it. It will install as long as it is still hosted on npm.
Are there chances that as the browsers will continue to update to the latest versions and cause some functionality in VueJS 2 stop working and we wouldn't be able to complaint since it’s already EOL?
I believe since no upgrade will happen to VueJS 2, we wouldn’t be able to expect any support for new features in browsers. Is it correct?
Vue is a library for rendering elements and I don't think it uses or ever will use any browser-specific code.
Related
I have a rather large Vue 3 application (~550 components). It takes two minutes just to run vue-cli-service serve and around 20 seconds to re-build it after each change. Hot reload stopped working a long time ago so it always needs to be refreshed in the browser even after a small style change. Moreover, the app is still not finished and it will probably get 2-3 times this big in the next year so it will probably be even worse.
Because of these problems, I've decided to migrate it from Vue CLI to Vite. I have already resolved a lot of problems and the app seems to work with Vite now with so much better loading times.
However, it sometimes gets stuck when I start a dev server (vite command) and open it in a browser. The page keeps loading and I can see a lot of pending requests in the Network tab of Chrome DevTools. There's nothing special in the output of vite --debug and running vite --force doesn't help either.
When this problem occurs, the browser always loads a lot of modules (~900) and then it gets stuck on 10-20 modules. The status of all these HTTP requests is simply Pending and they never finish. There are no errors in the browser or on the command line.
I don't think any particular file causes this. Maybe the problem is in my deeply nested folder structure with a lot of re-exports using index.ts file on each level. It mostly gets stuck on my own modules but I've also seen cases when it was waiting for a module of some external library.
Has anybody experienced a similar problem? How did you solve it?
EDIT: I have discovered that this issue only occurs in Chromium-based browsers (Google Chrome, Brave, etc.) on Linux. It works without any problems in Chrome on MacOS and Windows as well as in other browsers (Firefox, GNOME Web, etc.) on Linux.
Thanks to this comment, I realized this was a problem with the file descriptors limit.
On Manjaro Linux (Arch-based), I was able to solve it by adding the following line to both /etc/systemd/system.conf and /etc/systemd/user.conf file:
DefaultLimitNOFILE=65536
After this change, Vite works without any problems in all browsers.
I am being thrown a half backed, undocumented, non-handover project of VueJs with few other components as frontend and express as a backend. (Old developer who was maintaining things on git is abscond)
Backend/Express part I've figured it out most of the things but I got stuck on frontend part which is served using express_static
For VueJs I don't know what other things are depending
Is it using yarn or npm for build/deploy ?
Using mostly command line
What should be my starting point to look into project
Build/deploy yarn <> npm is interchangeable.
Is it possible to convert Individual .vue file to .js file and deploy it?
What other tips and tricks you suggest for making quicker changes live on productions without major disaster (on front-end side).
What is the fastest way to hack things in this situation :)
Is there any docs what happen internally? - Curious to know!
Thanks
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.
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.
I am curious to know why when I create a new Aurelia project, each project installs +600 node_modules. Understandably, the modules collectively don't take up a lot of space, but are all of these modules necessary? I was under the impression that Aurelia's aim was to help developers move away from depending on 3rd party libraries so it seems odd that each project comes with a massive dump of 3rd party libraries.
My guess is that you are starting your project from CLI - which comes preset with HTTP server, ES6/2015, SASS, live-reloading and more.
I created clean Aurelia project and looked at the package.json - there were 5 dependencies and 34 dev dependencies. Using all of above mentioned tools is somewhat standard in today's JS web development, and generating project from CLI reduces time needed for upfront setup. All of these features come with their own dependencies, and that's why node_modules/ folder grows rapidly.
The bottom line is - you could start new Aureila project with much fewer dependencies. On their home page you can find starter project with just three. But that also means that you won't have access to most of the tools used today.
Also, and correct me if I'm wrong, I haven't got the impression Aurelia ever aimed to move devs from third party libs and modules, just to be modern, fast, and unobtrusive.
All modern web frameworks have a host of tooling. The reasons in no particular order -
1. Transpiling ESNext or TypeScript - if you want to write in Future JavaScript but have it work in all browsers, you need this step. Both Babel and TypeScript tooling comes with extra stuff too. If you want to see coverage (everyone does) there's another tool.
2. Testing - Unit test and End to End testing require testing frameworks, test runners, and if you want to write like above (esnext or TypeScript) you also need transpiling.
3. Module Loading / Bundling - Require.js, JSPM/System.js, WebPack, etc... are used to allow your code to actually run in the browser. Without a module loader you could not break your code out in to separate files. Without a bundler you would be loading a lot of extra files in production.
4. Serving your application - If you want to run your app locally you need a way to serve it up and watch for changes.
5. Debugging - You want to debug? Now you need a way to debug the file that gets served to the browser back to the original source.
6. Linting - Lint your code base for style consistencies.
Each of these packages usually have their own dependencies, and they get pulled down as well.
This convention of small packages that have a single focus is arguably better than massive packages that do everything for you. This allows you to remove a package and replace it with the one that does the same thing but in a way you want it.