What are the downsides of installing Vuel.js with a script src link? - node.js

I am new to programming and I learned how to use laravel and vuejs (which now ship together in laravel 5.3). I'm only practicing Vuejs right now, and was wondering what is so wrong with installing Vuejs using a simple src link rather than going the complex way of installing with npm and node.js, which is another learning curve for me if I have to learn it down the road anyways. Thanks for answering, I just don't understand what could be wrong with a simpler minified src link for a Vue.js installation.

If you use standalone version of Vue.js via a simple minified src link, it will come with a template compiler. The Vue component templates will be compiled in the browser environment for every user, before rendering. Therefore it will be slower compared to the runtime build option.
If you create a project using npm and vue-cli, you will get the runtime build of Vue.js, which will also package the vue app into one single app.js file, thus minimizing network requests for your production app. Your users will have a much better experience.
If you are only getting started, you can go with the simple minified src link for now. Once you get used to the framework, you can start using vue-cli.

Related

How to use node_module packages correctly

So, I'm heading to new territory in web dev.
I set up a basic npm project using npm init in my project folder. I don't have angular, react or any other Dev framework running. Basically I want to get started with some npm packages to easily update the things I need.
For my first test I picked bootstrap and font-awesome.
For testing I have a http-server running and displaying a index.html file from the public folder.
The site I'm displaying is a basic html site for now. How do I actually implementy packages the right way? Using <link rel="stylesheet" href="/path/to/node_modules/..."> is one option but not actually the way it is done, right?
Or will it be repacked once I'm ready for production. Since node_modules is not going to be transferred to the prod server.
Thank you very much in advance!
there is a difference between running javascript in nodejs and the browser javascript engine.
although nodejs is built on top of v8 javascript engine, nodejs is different in some ways, here are 2 of them:
nodejs is used mainly in server-side programming, where javascript is used for client-side
nodejs has builtin libraries which are not in the javascript specifications
if you are developing a client-side in nodejs (using react, angular or any other client-side frameworks), you will have to "convert" (a process called transpiling) it to run within the browser.
there are several tools which can help you in the process of transpiling your code. some famous ones are webpack and parcel in conjunction with babel (to pollyfill) to "build" your project and yield a bundled (few javascript file, usually one, that bundles all the javascript code into one of more files) javascript file(s), which are loaded by the webpage.
as you can see, once the project is bundled, node_modules directory has no use -- exactly what you want.

Vue Micro UI/Web Components Development Workflow

Seeking some ideas on how to better improve my teams local development workflow...
We have a Vue CLI shell application project that runs locally via node. Then we have a number of small Vue CLI web-component applications that served up via node.
When the shell is ran it reaches out to each web-component application retrieving a manifest.json file which tells the shell where/when to display the respective web-components.
Our web-component applications are built using something like...
vue-cli-service build --target wc --name foo 'src/components/*.vue'
Having to continuously build the web-component projects after making a code change... debug... and then rebuild again seems cumbersome. This is a new application so at the moment the codebase is in constant flux.
Was hoping someone may have suggestions on how or tools we might use to increase our productivity.
Don't overcomplicate things.
Here's Nuxt.js
As far as I can tell it does everything you want to do straight out of the box. Just set up a basic hello world project with Nuxt and see if it does everything you need it to do for you. It uses Vue.js and Webpack to build the exact same type of application you'd be developing otherwise with Vue, it just has a nicer layout and easier workflow in general. It supports hot reloading on file changes, you'd just run nuxt in the root folder of your project and a local server is started that hot reloads your project whenever you save changes to a file. You then distribute it either as a static application with nuxt generate or build it as a server side rendered application using nuxt build and nuxt start.

What's the lightest way to automate .vue file compilation without webpack?

I'm working on a web application that currently uses vuejs for part of its interface. The back-end is NOT in Node, so there is currently no package.json file or any tool from the typical npm stack in this repository.
We already have a bunch of non-npm dependencies that need to be installed in order to use the repository, so my coworkers aren't too open about the idea of adding another layer of complexity. I can't blame them for that, it's the reason why I use npm scripts and not even gulp in my other projects. I'm tired of spending hours learning and configuring build tools that never end up doing what I want anyway.
But since the vue-cli tool no longer includes the build command, I'm a bit stuck. Is there really no more CLI app to build vue files at all? And if so, what would be the smart way to use vue without webpack? Template strings are not maintainable at all, and <script type="text/x-template"> don't work when you want to use multiple components from multiple files in the same page.
I realize your question says 'without webpack' but you may be interested in backpack - a CLI app i came across for building Vue.js without requiring you to write any configuration code. It is basically webpack preconfigured as a minimalistic build system for Node.js. It provides two commands, dev for live reload enabled development and build for building you project.

Importing an Angular2 application into Phoenix-framework

I am currently working on two related projects. One is a Phoenix based website and API, while the other is an Angular2 application that among other things uses the API provided by Phoenix. I now want the Angular2 application to be used by the Phoenix project. The problem is that I don't know what the best approach is. I am very new to Angular2 and NPM, and know very little of how it actually works outside of basic usage. These are the ways I can think of solving my problem:
Put the Angular2 project into the Phoenix project, making it one project. I have no idea how to do this, but I will probably get there through trial and error as both use Node.js so it should be doable.
Publish the Angular2 project to NPM, and then import it to the Phoenix project. How much work would be needed on the Phoenix side? Would it be the same as just running the index.html in the Angular2 project? Would I need some kind of Angular2 "shell" around it?
Run the Angular2 application as it's own thing, and just link to it through the Phoenix website.
Importing it as a node module sounds like the best approach, but can it be done for full applications, or is it intended for support libraries only?
I am unsure if this is the "right" way to do it but this is what I did in the end:
I compiled my entire Angular2 project into app.js, vendor.js, and common.js, I then moved it all to web/assets/. After that I simply created a new html and referenced the files in question.
The biggest challenged was finding something to compile it all into these 3 files. I ended up using a stripped down version of: https://github.com/AngularClass/angular2-webpack-starter
I think you would want to leverage brunch.io, which ships with phoenix to handle your front end dependencies. There are skeletons which are essentially templates that create different front end configs but I don't see one that provides angular2. In this case I would say use bower to install the js packages you want ie:
bower install -S angular2
With this you can use brunch as a processing pipeline and it will handle minification, linting etc. and you will still be working within the "recommended" approach to managing front end assets in Phoenix.

How a worklight(with ionic) project interacts with a gulpfile, package.json node.js bowerc

I need to develop a mobile application using worklight. While i was going through few sample source code, I observed a gulpfile where they defined few Task/Watch in it. There was also a package.json where they have defined devDependencies property.
I like to know how a hybrid app project (when developed using Worklight or any other tool/framework) use the gulpfile, package.json, node.js, bowerrc. How is the controls passed across all these components when implemented for a hybrid app developmen and What will be the first point of execution in this sequence of execution workflow. As I believe wlEnvInit() inside main.js is the starting point of execution for a worklight project.
I tried google but could'nt find any explanation on the same.
The Gulp file you see is part of a default Ionic project. It handles compiling Sass files and running the bower install command to install dependancies. If you are using Sass in your project, then this would be useful to you, but it does not directly relate to MobileFirst.
As you know, when you update your common code, you need to do a build/deploy to get the code deployed to your mobile platforms. So if using Sass, then you need to remember that while the Gulp file may compile the CSS, you still need to "mfp bd" to deploy it to MF.
Does this answer your question?

Resources