lollipop25

App:

- HTML: Vanilla

- CSS: Bootstrap 4 (SCSS) + node-sass

- JS: Any framework (ES6) + Rollup + Babel

Deployment:

- Repo: GitLab

- Host: GitLab Pages

- CI: GitLab CI

Because electrical engineering and math. It's like a spectrum:

Math [Uhm...math] <-> Computer Science [algorithms] <-> Computer Engineering [robotics] <-> Electrical Engineering [electronics]

It's even fun to think about if you involve communications. It becomes a three-way.

(Between CS and CE) -> Communications Engineering [radios] -> Network Engineering [protocols, wifi] -> IT/DBA/Web [closer to web]

First off, use a native app, Gmail or another email client. It's lighter since you aren't loading the UI resources like you would in a web app. It can also be set to store messages locally so that the app won't have to query the server for a message you already loaded sometime in the past. You can always disable live syncing and do manual checking to save bandwidth.

If native apps aren't an option, use Chrome or Opera for Android. They both have bandwidth-saving features. Your pages are crunched by Chrome/Opera servers so that they come in smaller to your mobile device. Should you want to continue using Firefox, Opera offers Opera Max. It's the same data-saving feature on the Opera browser, except packaged as a separate app and does compression on all device traffic where applicable.

Further, I don't think the bandwidth savings are that great if you disable JS. Resources like JS and CSS are cached by the browser. Assuming you don't always clear the cache and let it work the way it should, they only impact is the initial loading of pages where it has to load all resources. Further accesses are retrieved from cache when possible.

Again, use a native app or just use the app the way it's supposed to be used and save yourself the headache. Disabling JS is like trying to drive a car but insisting on having the engine removed.

From the looks of it, you're essentially doing tracking. Won't be long before your solution also gets blocked by an ad blocker.

A system that gathers data about the current weather, date, time, weight, height etc. to...

...suggest you your breakfast, lunch and dinner.

"you probably need a pizza today"

Promises alone, good for me. Promises + generators, they just created a monster. I'll probably be sticking to just promises for a while.

JavaScript is becoming terrible these days with all these foreign concepts being pulled in. It's not like the language doesn't work without them. It even gets better, ES7 has the async keyword that's totally different from generators, but is geared to do the same thing. So you now have 4 ways to deal with async stuff: vanilla callbacks, promises, generators and async functions.

---

On a side note, the people who lead JS included `const` in the spec. Now people are using `const` to denote value holders that won't and should not change values, happy ever after right? Wrong. The same people that are leading JS are making fun of people using `const`, saying that you're probably brain-dead to need `const` to keep you safe.

That's the kind of people "leading" JS.

> This means we never know where a function is being called from.

Not really. Chrome dev tools has an "async" option which allows the stack trace to follow through async calls. You will see the async caller instead of the async execution mechanism in the stack. Further, you can black-box frameworks so you only see your code.

> The danger I see with promises is they can be used incorrectly.

The real danger of promises is the different implementations that existed beforehand. For instance, jQuery promises weren't standards-compliant. Their implementation of `then` (which came from `pipe`) wasn't the same as the native one. Getting used to one, you'll easily write wrong code for the other.

> generators will provide more fine-grained control.

Depends. It's a foreign concept in JS, making it harder to follow as opposed to promises which are nothing more than stateful objects. Also, one's mental model will change with generators. One has to look out for that tiny `*` to know the code is "generator friendly".

This depends on the browser. Dev tools are "smart". It knows where you should put a breakpoint (i.e: putting it on a blank line, it puts it on the next executable line instead). It also knows when you adjusted your script (i.e.: removing a line above, it moves up the breakpoint).

"slipping" can happen if:

- The dev tools can't determine where to move the breakpoint (i.e.: if you significantly changed the file). Just re-assign the breakpoint.

- It can also happen when you use a badly-constructed source map. Disable source maps and work with raw code, and contact the tool-maker about this.

- Sometimes, the dev tools will just go crazy. Just close and reopen.

- debugger. You have no choice.

> Should I focus on one language and become really good at it or work in multiple languages and stay mediocre?

Both.

Master one, but learn enough to be able get around with the others. Also, learn the language, not just the tools or the new and shiny things. Tools and frameworks come and go, but the language itself will always progress.

> I feel like I am not doing much designing and not really learning a lot.

Work-related code, especially the monolithic, enterprise-y variants, isn't the best place to try something new. Try contributing to open-source projects. They're always in need of additional hands and move relatively fast enough that new stuff comes out regularly.

Good try kid. But you ain't goin' nowhere with this FUD.

- Life's too short to deal with cross-browser incompatibilities.

- jQuery too heavy for you, there's Zepto.

- Not at all times you are in control of your stack, especially when you just inherited the project.

- If you happen to work on a Drupal project, good luck with ditching jQuery. It's built in.

- Clients will always ask for "cross-browser support up to IE8" without knowing it's a dead browser.

- What matters to clients is that it works. They don't give a beaver's construction project what you used to build it.

I'd wouldn't say "Why you shouldn't use jQuery", but more of "when to and when not to use jQuery/vanilla/CSS3".