Each topic that was brought up in the Slack channel has a heading with a answers between them.
So this is a question of trade-offs. Sometimes you need to have some JS inline with your HTML due to your web framework. Eg. You have some JS that sends Google Analytics/Mixpanel events and needs to have a user's email address which must be given to your JavaScript.
<body>
...
<script type="text/javascript">var USERMAIL=<%= user.email %></script>
<script src="mixpanel.js"></script>
</body>
...In some cases, you need to have a JS script for your page to load properly - like you want to have a random greeting shown to the user for loading up your app. It may make more sense for performance to make sure this is available to the browser while it downloads other things.
For things like reusable UI components, the stuff that comes with Bootstrap (carousel, accordions, panels, etc.), you should keep those in a separate file and invoke them in your other scripts or as the case may be just having elements (like a ul or div with the CSS classes and data attributes to call the right stuff).
The way to figure out what you should is to profile your page(s) with developer tools, use tools like page speed and experiment with different techniques.
My suggestion is to start with JS in a separate file while you build, refactoring as you go, launch it and then look at the page load speeds and other data you can get to determine what to do next - 9 times out of 10 you aren't going to need to do anything.
Go over some common JS features that are applied to mobile/web design (today's form example was good; also carousels, interactive buttons, etc.)
JavaScript is a language that has access to browser features so JavaScript is limited in what it can interact with based on the browser. In modern browsers, you can work with the user's webcam, the microphone, the speakers - almost all of the user's hardware can be invoked by JavaScript. The UI components mentioned here are just combinations of HTML, CSS and JavaScript - HTML provides a scaffolding by giving the browser concrete elements that can have geometry. You can manipulate that with CSS and add behavior to it with JavaScript. There really aren't any limits to what you can do aside from the time it would take to make really complex things like a 3d Rubix cube game or something that makes a lot of decisions. Let's look at an example:
https://jsfiddle.net/gkm1q73b/
This anchor tag is just a link to another resource, here it is a just a hash mark (which we could use to help a user navigate to around this page, this is how you make a 'Back to top' link). We can use this link, along with some styling, to trigger any action.
User Interfaces depend on the user taking (or not taking) some action that we plan for them. We can say things like, "If the user hasn't moved the mouse in 2 minutes, show a modal that connects them to our live chat service."
Maybe a high level overview of why designers should know some JS (some answers are obvious but it would be good to hear a developer's perspective on this).
When you think about a user's experience, you want them to have clear paths to complete actions. It might be signing up for your newsletter or showing them how to get in touch with you, maybe you want to make it really simple to shop online or organize projects, but HTML and CSS will only give you so much control over how user actions can be interpreted. With JavaScript, you can take over and drive the user by implementing behaviors as a result of an event like using the keyboard, moving the mouse to a certain portion of the screen, pinching their phone's screen, really anything!
See the JS fiddle above.
Routes, or in a more general terminology, URL configurations, are not something that JavaScript knows about. The way to have specific javascript for a particular page is to include that script in a script tag. With Single Page Applications (SPAs) you'll want to have a routes-like mechanism for sending and retriving data from a server or service like an API. E.g.
var router = {
posts: {
get: function () {
// make an AJAX call to GET /posts
},
post: function () {
// send form data to a a server to create a post
}
},
users: {},
};Hyper Text Transfer Protocol (HTTP) is a text based protocol that has a few main features: (Hyper text just means text with links)
Verb Path
| |||
GET / HTTP/1.1 <- What document we want, and the HTTP version we are using.
Host: www.google.com <- The name of the server(s) that have that document
Accept: image/gif, image/jpeg, */* <- Additional Headers
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
(this line is usually intentionally blank)
The first is that is makes use of VERBS (get, post, put, patch, delete, head, options, trace) to indicate to the server the action we intend to take.
Get = give me the resource Post = Make a new instance of a resource (create a blog post, create a tweet) Put = Update an instance of a resource (edit your facebook post, change the amount of a transaction) Delete = Remove this from the internet, please!
Head = send me back the same as a get, but DON'T INCLUDE THE BODY OF THE RESPONSE! Options = tell me what other verbs I can use at this link!
Secondly, we have a Uniform Resource Identifier (or Location) i.e. URI/URL that tells the machine exactly where it can grab what I'm asking for in my request.
Cool URLs don't change!
- Tim Berners-Lee (creator of the Internet)
In most programming languages, someone has already written some code that understands HTTP and can translate it into a native (Ruby, Python, Go, C++, JavaScript) object, structure or data type. Responses look very similar but they will usually have some kind of file in the body (like HTML, JSON, CSV, PDF).
I'd love to learn a bit more about object oriented programming in js (constructors, prototypes, methods, etc)
In JavaScript, we have a lot of options for creating objects.
From object literals:
var Person = {
name: 'Leela',
greet: function () {
return 'Hello ' + this.name;
}
};
Person.greet();But this doesn't lend itself too well to making multiple copies of a person so we might make an object...
From functions that define a kind of constructor/initializer:
function Person(name) {
this.name = name;
}
Person.prototype.greet = function () {
return 'Hello ' + this.name;
};