I understand that there are basically two ways of deploying a vue app. One is to include the library directly with:
<script src="https://unpkg.com/vue"></script>
and the other method is to use vue cli, then build with npm
I saw many tutorials, but I could not get a quite understanding of what exactly is different, or what are the advantages of each side?
Vue can be used through -
CLI - es NPM / yarn to install Vue. Sets up default config pretty nicely
NPM - (or yarn) install Vue directly and configure yourself [recommended for large projects]
CDN - refer directly through in your HTML /script
If you want to just include Vue in your script that has a larger objective, or accomplish something 'comparatively' simple, just use CDN. This is a good way to use the power of Vue without worrying about the intermediate build steps specific to Vue. Your completed product will continue to refer to Vue from CDN.
Also, each CDN lookup will mean an additional server request - this is likely to serve content faster than your own server, but an additional lookup nevertheless. Having tens of CDNs is not ideal.
For larger projects, NPM is ideal. You would want the power of Single File Components with (files with a .vue extension) that play well with editors, and provide a more structured way to develop the application (incl. things like scoped CSS).
Also, the build step through local Vue is a must if you use functions not supported by browsers today, or want to support older browsers.
https://v2.vuejs.org/v2/guide/installation.html
Related
I have noticed theese two methods for generating a new vue project:
npm init vue#latest
and
vue create <projectName>
Both seem to do the job, but very differently, they boundle very different packages.
Even tho you ovbiously modify the project to your liking, is ther a better start for my project requirements?.
The project i'm talking about, is going to be a single page web application using typescypt, ESlint and tailwind.
Also I have seen that the two methods do not just install unrelated software from one to the other, for example state management is handled by different libraries, and if I am not wrong Vite is the equivalent to Babel.
I am just starting with Vue, and frontend in general (tho i have used Angular), I am more prominently a backend dev, so i am not used to most of the software used here, and I do not really know what they are used for....
To ease finding the solution for others, as commented by Estus Flask, The oficially recomended by the vue devs currently is
npm init vue#latest.
This will set up a project using Vite and Rollup, wich is the currently recomended stack.
The other method is a deprecated one. as it gives you the old stack recomendation, Vue CLI and Webpack, this other stack is currently not enforced by vue devs.
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
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.
I have an online site and Im going to overhaul it. While I cannot find any information about if I can use npm and some kind of package manager (e.g Webpack) on live site which is on shared host (which has latest Node.js, npm support etc), Im going to develope it locally and worry about "publishing" it later on.
Is there a way to somehow covert my current downloaded project to npm project or Im better off just starting a new project? This is rather confusing, I've never used npm before.
Im using WordPress, everything is run with PHP atm but Im going to overhaul it and use Node.js.
NPM can be used to collect and manage Javascript dependencies for the browser so as to create a stand alone front-end JS app. BUT, bower is probably a better choice.
NPM is designed to manage Javascript dependencies for projects that use NodeJS or use the CommonJS module format for requiring modules.
Bower is specifically a package manager (like npm or composer) but it is meant to manage browser based javascript dependencies.
Currently, javascript doesn't have a formally defined module/import system, so a number of competing require() functions are been produced. NodeJS comes with a require() function that searches the npm/ folder for modules. Browserify is a pre-processor that can scan the npm folder for a dependency and all of its dependencies and bundle them into 1 file for a browser to download (because browser's don't have a require() function because the JS standard doesn't have define one)
I might be rambling here, but you should probably look at bower, and then - at some point in the future - look at either browserify or requirejs to combine and optimize all the JS plugins for your front-end app.
Edit for clarity:
Basically there are 2 engines to run your JS application: the browser or NodeJS. NodeJS needs npm, the browser has no idea what npm is. If you want to write a clean, single page app, all JS front-end for a PHP backend, you don't need NodeJS, and therefore don't need npm. Using npm will prematurely complicate the development of a front-end browser app because it will force you to decide on a require() implementation (Browserify or Requirejs) right from the start.