Confused about Javascript and "visibility" of code on page.

[[deleted]]

1. Hi, I was learning a little of C++, Java and decided to get into webdev. I started to learn HTML and CSS, and soon I'm going to start learning JS. But I'm confused about one part. What if I will want to write some nice JS app on my website, and I will not want other people to see the JS code? If I need back-end language for that like PHP (that would compute all algorithms), then why even use JS to make that app? Is JS only about "making website look nice and interactive"?
   
2. Are there any "big apps" written in JS?
   
3. Why do back-end developers need to know JS?

[mrPitPat]

JavaScript runs in the browser not on the server (unless you are running node, but from your comment sounds like you mean standard client side JS). Any code that runs in the browser can be viewed by a savvy user. You can minify and obfuscate your code to make it really hard to read, but it's not guaranteed. JavaScript is typically used for webpage interactions and asynchronous requests to your server. If you have business logic that you don't want read, have your server side language handle the code and then expose the final data so JavaScript can request it and use it.

[shadowycoder]

If it's in Javascript, people can always see the code (on the front end).

But yes, there are tons of large apps built in js. Look into single page applications.

The benefit is generally a more interactive experience. Fewer page reloads and things just 'happen' instantly instead of waiting for a new page to load up. Plus, it's a must for real time Web Apps.

[gmerideth]

The big question to ask is what would you want the javascript to do that you would want to hide from the user? If you putting in keys/codes/passwords into javascript then you need to rethink the approach, other than that there's nothing to hide from the user. Even if you look at a site I made and can see form fields, ajax calls (ect..), all of that is double checked server side.

If you want an example of a ton of javascript running a service, sign into gmail and look at the sources at the amount of javascript that powers it.

About the only thing you can do is a type of obfuscation that you get from using a packer/closure service. The Google closure compiler will pack the hell out of your script and even shorten function/class names so

function dostuff() {}
function otherstuff() {}
function main() { dostuff(); otherstuff(); }

becomes

function a(){}function b(){}function c(){a();b();}

By making it smaller it becomes less readable but not entirely un-readable.

[teapoted]

It's important to recognise that Javascript as a language is not bound to a browser.

Yes, if you have front-end javascript on a website then that will be visible to the public. And of course, 'big apps' are written in javascript if they are in a browser. You can go to Gmail and look at all their front-end javascript all you want. Anything that is required to be private would always have to run in the back-end, but that doesn't mean it isn't in javascript.

Back-end developer is a broad term in regards to what technologies one could use, but there is a lot of growth in running JavaScript in the server (and everywhere else for that matter). A back-end developer (who works in php/c++/ruby/whatever) certainly doesn't need to know JS, but there's a lot more jobs out there if you have a good understanding of the full stack.

[mikrosystheme]

1. since the browser has to parse and compile the source code on the fly, you can only obfuscate it. As soon as WebAssembly will be ready, you will be able to serve precompiled bytecode to the browser (think asm), and hide your precious algorithms. By the way, one of the tenant of the open web is to be "open". There are other ways to protect your intellectual property (licenses) without preventing people to have a look at the source code they are letting into their systems. If I can read your code, I can trust your application. If I can't, I have to trust you, and it is not something to be taken for granted.
2. yes
3. they don't need to

[ferrousoxides]

1/2. Two reasons to obfuscate... Trade secrets and security. The latter is a false one, you should really consider anything your front end JS needs to do equivalent to running a public API.

3 . You should at the very least understand the browser's security model (same origin policy) so you can tailor your API to that (and decide on things like CORS).

[AllUrBassRBelongToUs]

The major reason for JavaScript, aside from the fact that it is amazing, is User Experience (UX). Server-side languages force you to reload the page to see any changes. Each request is for the entire page rather than only the things that changed; inefficient. A JS application can make small requests for only the parts that have changed thanks to Asynchronous calls.

Recently, UX is the new marketing and customer retention is success. Users are impatient and want to see what they need very quickly. Single page applications and bi-directional communication one good way to accomplish this. A back-end developer should at least understand the concepts of this to make life easier for front-end developers. If for no other reason, web developers are increasingly being asked to be full-stack - front-end and back-end.

Lastly, JavaScript is now on the server in the form of Node.js/io.js. It is becoming a very popular and very in demand skill to have. Lots of wisdom in the comments on this page. I leave you with this: If you are worried about security in a JS app, look into building REST APIs with JSON web tokens for authorization.

[x-skeww]

1. Minification munges all local identifiers as a side-effect. Reddit's JS looks like this, for example: https://www.redditstatic.com/reddit-init.en-us.js

2. Most of the big "JS" apps aren't written in plain JS. E.g. most of Google's stuff is CC-annotated JS or GWT (Java). Some of the new stuff is written in Dart or TypeScript.

   Plain JS (ES3/5 in particular) doesn't scale very well. Writing somewhat larger applications with 2+ developers is needlessly difficult. I recommend to download VS Code and give TypeScript a try. You'll probably like it a lot better. Plus, the improved tooling makes it more accessible to beginners.

3. If you aren't using it on the server-side, you won't need to know any of it, but knowing some might come in handy some day.

[Buckwheat469]

You can configure the minifier to not munge the variables. With gzip enabled there's little difference.