Overview of JS Environments for Newcomers

By Dave Ceddia Comment

Development vs Production

Picture this: you’re new to Angular, and maybe modern web development too. You’ve got some workable code and now you want to put it up on a server. What next?

You’ve written your fair share of plain old JavaScript and jQuery… and those were simpler days.

Back then you’d just FTP your code up to the production server and refresh the page. No fancy “build” step with concatenation, minification, uglification, transpilation, and whatever else they dream up tomorrow.

You might even be developing on Windows and trying to get your code up to a Linux shared host – and being unfamilar with Linux just adds another layer of complexity.

If this sounds familiar, you’re not alone!

One of my readers wrote in with a problem like this the other day:

“I am completely at sea with how I go from a Windows development environment to uploading workable code to a shared host in this new world.”

Most blogs and even videos and paid courses assume some base level of knowledge (which they don’t spell out as a prerequisite). Not understanding what you’re missing is very frustrating. Where do you even learn this stuff?

So let’s rewind here, and go over some of the basics.

Let’s call your 2 environments “development” and “production” (dev is Windows, prod is the Linux shared hosting server).


Generally speaking, on your development system you’ll need Node and NPM and your IDE of choice. This allows you to write code and test it out locally. Usually you’ll have a server running locally too, often provided by your build system. npm start or npm run are common ways to get that started.

"Why do I need a server at all?"
In the good old days, you could just write your index.html file, drag it into your browser, and it would all work great. Nowadays, where you're likely to be pulling down some external libraries from a CDN, you can run into errors with the Same Origin Policy a.k.a. CORS if you're not loading files from a real server. Running the server is an extra step, but will save you some headaches down the road.

Deploying to Production (aka Uploading)

Then (assuming your app is pretty simple) the production system need only have a web server installed – Apache and NGINX are common ones on Linux. They’ll be serving files out of /var/www or something similar.

Once you’re ready to deploy, it is as simple as uploading files via FTP or SCP! But… which files do you upload?

In your project directory you probably have a build system in place - Gulp, Grunt, Webpack, Browserify, or one of a few others. You’re probably already running the build tool to watch for changes and run a web server locally for development.

Your build system likely has a “production” build mode – maybe the command is grunt build or grunt deploy or just gulp – it’ll depend on your setup. This command will concatenate your source files, probably minify them, probably bundle up 3rd party libraries into one big JS file, etc.

The production build will create files and put them in a dist folder (or maybe build or target or something). They might be called app.js and vendor.js or similar. These, along with any HTML and CSS files, make up your app.

Upload all those files to your webserver’s root directory, and you should be good to go! (assuming you put them all in the correct paths relative to each other – check index.html for where it expects the files to be)

What else do you want to know?

Hopefully this helped explain a few things that usually go unmentioned – but I know I left out some details. I made some big, simplifying assumtions here, too – assuming you have a build, assuming you don’t have a backend server to integrate with, etc. If you have more questions just reply below.

For a step-by-step approach to learning React,
check out my book — grab 2 free sample chapters.

As far as I am concerned, even the intro which is free is worth the price.
— Isaac
comments powered by Disqus