I'm a beginner in ReactJS also for NodeJS. I would love to know why we have to install NodeJS run ReactJS application as ReactJS is client-side scripting.
The other answer is incorrect.
You don't NEED Node.js, in fact you could create a project without running a single npm command. Just follow this guide.
The main reason, as pointed out in the article, is:
Easy package management. This means you can upgrade the package easily later on
JSX is the templating language that makes it way easier to write components: <h1>Hello Word</h1> reads so much better than React.createElement('h1', null, 'Hello World')
Managing module imports, as opposed to having global variables around everywhere, it's great to have encapsulation and import modules as needed.
Build step and workflow. For a modern project, you will need tools to minify your code, cache busting, transpiling (writing pure javascript for old browser is a pain and you really shouldn't do it manually), the list goes on and on.
Because almost all the JavaScript libraries/frameworks are using the Node Package Manager (NPM), that makes much more convenient to manage JavaScript dependencies in general, both client-side and server-side.
Edit: It's not really technically necessary, but using a package manager is the best practice for managing dependencies and sub-dependencies.
Of course, you don't have to. When you are in the development step, you can install it for package management. Only webpack is needed to bundle, compile, transpile the code.
Related
I use webpack to bundle all files for production on the web. Since no code runs on node during production, thus no package being required in production, should all dependencies be development only?
I don't want an answer based on opinions or best practices or intended usage, I simply want what makes sense.
It seems the only answer you will get to this question will be "based on opinions or best practices or intended usage". For those who were not looking for such answers, the answer is:
If there is no backend service in the same project where you are making the frontend app via a bundler, then put everything in devDependecies; otherwise only put the packages you will require in some node.js related code in dependencies.
For my understanding, node.js is a javascript-engine which is running javascript-code without using a browser(window-global). You can use javascript on a server. But I saw now a lot of tutorials(react, angular, vue etc.). In every tutorial, I have to install something with npm. I can follow there are several dev-tools which I can use on my local machine to minimize my javscript-files or compile sass to css. But in the end, when I put my files on a webserver, I just have normal javascript-files, css-files etc. No node.js code in it, right?
My question is: React, angular, vue.js etc. are written in just normal javascript without node.js right? The reason why I use npm ist just to install every dependencies with one command, right?
A question more: Is there an any recommended order to learn all these frontend-development stuff? There are so much words I have to google it: angular.js, react, vue.js, vanilla.js, typescript, backbone.js, bower, grunt, webpack, yarn etc... I dont know where I start, so I look into few tutorials, but everytime I go through these tutorials, there is a new word(technology) I have to research.
I think you're getting your terminology a little muddled.
Node.js is a JavaScript runtime, built on Google Chrome’s V8 JavaScript engine. However, that is not to say that Node programs are executed in a browser. They aren’t. Rather, the creator of Node (Ryan Dahl) took the V8 engine and enhanced it with various features (such as a file system API and an HTTP library) to create a program we can use to execute JavaScript on our computers.
Node comes bundled with a package manager called npm which you can use to install packages (such as React and Angular) from the npm registry. These packages are indeed written in normal JavaScript (or a language that compiles to JavaScript, such as TypeScript).
The reason why I use npm is just to install every dependencies with one command, right?
Kinda. You can certainly use npm to install dependencies. However, it does a lot more that that. For example you can use npm scripts to carry out various build tasks, or you can create a package yourself and use npm to publish it to the registry.
A question more: Is there an any recommended order to learn all these frontend-development stuff?
As with everything, it depends. What are you trying to build? It's relatively pointless to learn about Node, npm, React and Angular if you are attempting to build a simple static website. If I were you, I'd define a clear goal and set about learning the technologies you'll need to reach that goal. Saying that, if you are doing anything with front-end development, learning about npm will be a good use of your time.
Here's an article by way of further reading that explains things a little more: https://www.sitepoint.com/an-introduction-to-node-js/
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.
When developing front-end code for the browser, I often use the es2017 preset when transpiling down to a distribution bundle, which allows me all the conveniences of the included transformers. For conventional modules, I usually stick to whatever the required node engine I've specified for that particular module supports.
I would like to start developing these "conventional" modules using babel transformers as well, but I can foresee drawbacks to this, including:
It might inhibit the debugging workflow (more specifically when working with an IDE)
The performance of the module might suffer
What's the current state on this matter - would you say it makes sense to use babel in conventional modules given the aforementioned and other trade-offs? What are the pros/cons for your preferred workflow?
Bonus question: What are some reputable modules and/or module authors out there that are already using this technique? I've seen Facebook do it for their react ecosystem but I guess that makes sense since those are mostly modules for the browser.
It is converted back to vanilla JS (babel does that part).
What you get is that you can utilize Classes which I found useful.
Hopefully with time, browsers will support ES6 and we will not need babel.
The only drawback is that when debugging, you have to produce a source map, but that is temporary, see above.
To answer your second question: I'm using React in one of the websites, and most of the modules I needed (from npm) are using ES6.
I believe that the trade-offs or drawbacks that you mention both do not apply to developing nodejs code using babel as ES7 transpiler. Personally, I find using ES7 features with node tremendously productive.
There is source map support for debugging. I use karma for testing and it comes with excellent source map support (I use IntelliJ but I believe most IDEs will do). You can checkout this REST-API repository on github. It's a nice stack for building nodejs data backend. It uses karma for testing - even comes with code coverage support. It also integrates with pm2 for scaling and availability.
Regarding performance: I think transpiled code has been shown to run faster in many scenarios than the code a developer would write when not having advanced language features available. I will post some links later.
I'm putting together a module I'd like to release, but am a bit stuck on how best to go about packaging it up. In addition to server side javascript, the module will need things like an admin screen, and client side javascript files. That is, it needs to serve out a fixed set of static html/css/js files. (I may have the node-static module as a dependency)
I'm curious what is the best way to handle this. I'd like to make this simple to install and integrate into apps, without forcing the user to dig through a long README. Basically they should be able to NPM the module, then add a line or two of code in the relevant place, and have it "just work". I don't want them to have to download other stuff, tell the module where to find the static files, etc.
Also, I'd like to make sure it can be included in both simple apps (i.e. one step from the standard "hello world") as well as complex apps using frameworks etc like Express, without undue hassle.
Is this possible, or is this beyond the scope of what the module system is designed to handle?
Once your package in installed with npm install mypackage -g you can use __dirname inside your executable to find the directory it's running in.
Likely /usr/local/lib/node_modules/mypackage/bin/mypackage
With your assets in /usr/local/lib/node_modules/mypackage/assets
so __dirname + '../assets' + myasset should correctly find your asset