The best way to annoy me is to expect that I can explain instantly how to solve that software problem they are having. Even if I don't have that program in front of me. Or haven't used the program before. Or ever heard of it / know what it does.

They're not - this syntax is easy to read and ought to be familiar to any language user.

Make sure your catch handlers (promises or try...catch) have a log statement. Pass the whole error object as a parameter to your log function - this will make sure you get the stack trace (don't convert it to a string). Ensure you are printing enough context at the start of a (potentially error prone) flow so you can trace the error back to the event that started it. Also consider printing that contextual information with the log statement. Use console.error (or your logging framework equivalent) so it's separate and obvious.

There are servers, but you don't manage them. You provide your code, and the runtime environment packages it, deploys it into containers and runs them when they are invoked. All of this is managed by your service provider (ie you don't have to manage servers or containers). In fact, there's a small delay (around 5s) when the lambda is 'cold' on AWS while the container is spun up. The container will remain running for a while to service subsequent requests (but you only pay for the time your application is servicing requests). It is terminated when idle for a while.

Although this is starting to verge on to off-topic, I think we can agree, that yes, JavaScript as much as the IL of Java and .NET are all interpreted languages. Its just that IMHO you get value from using a well-designed IL, which can deliver other benefits to the developer. Things such as reducing the need to recompile on each architecture they target, creating opportunities for targeting optimisations to multiple architectures, and still being much quicker to translate to machine code than the high level languages they originated from. I work primarily in JavaScript (an interpreted language with a huge install base and massive mindshare among developers) but I get value out of compilation steps, such as: allowing me to write code in one dialect of JavaScript but target disparate interpreter engines use more heavily typed languages like Reason, TypeScript or Flow to add type safety to my code JSX -> JS translation, which lets me write in a mini-DSL more easily for things like reactive front-end programming in React or similar frameworks The end result might be more JavaScript which needs to be interpreted, but I've gained plenty in the process.

It doesn't sound like your web site fits the bill for using service workers. Barring a genuine need for push notifications, you should probably focus on the well-trodden methods of static web site optimisation and performance. The huge effort to build a client-side proxy for caching resources (and maintaining it as the site is updated) is hardly worth the very little gain. The standard techniques like minifying and consolidating resources, reducing the number of unncessary scripts on the page, async scripts, resource sizes, performance validation on mobile, etc are going to deliver much better usability. They aren't interesting or cool, but will give a lot more value to your users and customer.

The intermediate bytecode in Java and .NET is further compiled and optimised by their respective runtime engines (which allows them to achieve near-native speeds once the runtime is "warmed up"). V8 uses similar techniques - it just has more steps to go through because it needs to turn the source code into some kind of intermediate representation, when compiled Java is already sort of there.

npm and vanilla JS are still relevant. Bower and gulp are used far less these days for new projects, but many jobs are still going to require them. Frameworks are useful to learn - they help to consolidate best practices and still provide a significant leg up so that you can get work done quickly. They provide ready abstractions that even more experienced developers appreciate as helpful. Anyone can write poorly performing or unmaintainable code with or without frameworks, so it's more about learning how the framework operates and researching best practices rather than avoiding them altogether. React (more of a library) and Angular are dominant and likely to stick around for a while. Learning one or both of these is going to keep your skills relevant and let you code efficiently, regardless of your opinion of them individually. Both will help you write SPAs that can be maintained for more than a couple of pages or forms. Vue.js is a fast up and comer. Understanding how to use a bundler like Webpack or Parcel is vital to the modern web. They streamline the process packaging your JS, CSS and other web artifacts by providing a plugin architecture for transpilation, removing dead code, minifying it and preparing it for web distribution. Any non-trivial application will benefit from it in the long run. With webpack, you can just include an npm module and it will be linked into your application from it's main entry point far easier than bower. You can avoid dealing with bundlers directly by using templates or tightly maintained generators for react (create-react-app) or angular, but at some point you will need to understand how they work and how their plugin architectures operate. Webpack has an excellent manual these days and is well maintained compared to gulp, so it's worth taking a look and attempting to build up a config yourself (if only to learn). Be careful when referring to older tutorials, as it's architecture has changed significantly between v1 and v2/3 and many early issues around 3rd party plugins have long been addressed. SaSS is still not a bad CSS transpiler - there are other options (particularly for working with React) but there is nothing wrong with raw CSS. There is no silver bullet, and it all comes down to structuring your CSS correctly, using conventions, and being prepared to refactor it proactively as new requirements or technical debt emerges. Bundlers like Webpack can make it easier to link and minify CSS into your application and provide auto-reloading during development. Babel is a nice to have, especially when targeting older browser but using the latest ES6 or ES7 syntax. It plugs into webpack very easily. You may also consider Typescript or Flow or Reason if you want to improve the safety and reliability of your code, and pick up more errors at development time. Typescript has the best overall support at the moment. Eslint is the de-facto linter without these frameworks (and is recommended if you choose to write raw JS) and can still be excellent (albeit difficult to configure). Always start with a less restrictive configuration (such as eslint:recommended) and add rules as you go - there are defaults from airbnb and google, but you often spend too much time trying to match their strictly enforced code style instead of writing readable code. You won't need more than a half a dozen extra rules beyond this.

The typical way for tracking a user across sessions in a browser is through a cookie, which is automatically sent by the browser on subsequent requests. However, there is nothing stopping a non-browser client from emulating this process by storing issued cookies themselves and re-sending them on subsequent API requests (cookies are just HTTP headers, after all). You may be better off approaching this problem from another perspective, and requiring registration with an email address, or authentication with a third-party SSO provider like GMail or Facebook. This means that you still have authentication, but it's harder to "abuse" whatever service you're planning provide given the inherent difficulty in obtaining a new set of unique credentials.

QBasic - I remember working out how to comment out code in the Snake example game to turn off the borders (even though I didn't understand the array manipulation that was going on at the time).