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.
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.
> 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.
> 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.
Startups usually have very small teams. Take advantage of tools that do stuff for you. Also, having other members of the team take part in testing is a means to get to know the team better and learn something new.
> What happens when a solely-responsible engineer quits a startup?
- The management will try its best to keep the person. Raises, counter-offers, benefits will be put on the table.
- The management will try its best to delay the leave until a replacement is found.
- A sudden increase of communication and praise from the management.
> How does the replacement process work?
It depends on the contract. Some companies can use the notice period as defense. Some can hold you for as long as 6 months, using that period to keep you as well as find and train your replacement. Some companies won't let you leave unless a replacement has been found and trained to a sufficient level. This goes as far as making you find the replacement instead of the management.
---
Normally, there wouldn't be a "solely-responsible engineer". If the startup was managed correctly, there will be at least one other person who knows what the other person is working on. That way, even if the weakest link falls off, the entire company doesn't suddenly tip over. Startup people have fancy names for these things. A team that knows a bit of what everyone else is working on is called a "cross-functional team". A developer that's part of that team is a "full-stack developer". It's just a fancy way of saying a developer in this team has more work to patch up management and HR issues like say, losing someone suddenly.
React has already been there for a while. It's probably winding down phase of its hype cycle. Everyone's getting accustomed without all the "wow, this is effin awesome. you should try it." going on.
> These libraries basically are JavaScript's "standard library"... they just happen to be optional.
Optional is great and I'm siding on building APIs on the user-land side if possible.
Unfortunately, having n different libraries basically doing the same thing is just annoying. This thing you call "competition" is just developers egos gone berserk. There's no point in building 2 things that do the same thing, unless it's definitely better (which is good) or unless the point it conveys is "I'm better than you" (which most devs are, really). I mean look at this guy who tries to overtake jQuery 10 years after jQuery started: https://github.com/drduan/minggeJS/blob/pr/95/README_en.md
That said, Lodash and Underscore should just merge. Zepto and jQuery should just merge. Immutable and Mori should just merge. Inferno and React should just merge.
> I don't understand why one guy pulling their repository off the npm servers affected others' projects.
That's because 1) npm isn't immutable. The owner of a package can delete the package on npm. 2) Developers (re)-download the entire dependency tree prior to build. A missing dependency down that tree will fail the download.
> Why did everyone else's code refer directly to that guy's repository, and not some centrally-maintained clone thereof?
The "repo" everyone's talking about is npm. npm is the centrally-maintained storage. What happened is that the guy pulled out his modules from npm.
> So if a project goes down, the package stays on the RH server and you can still get it anytime you want.
That's what everyone wishes for npm actually, for that package to live forever once released to npm. Sadly, again, npm isn't immutable.
But again, there's this suggestion of "bundling before release", making a dependent self-contained. That way, in the event a dependency is missing, the worst it could do is just paralyze the dependent's next build but not make the existing build unavailable.
Because the runtime is present? I mean, why should I install Java to build my JavaScript when Node is present? And wouldn't it be weird if pip served Ruby gems or Homebrew providing chocolatey packages?
- HTML: Vanilla
- CSS: Bootstrap 4 (SCSS) + node-sass
- JS: Any framework (ES6) + Rollup + Babel
Deployment:
- Repo: GitLab
- Host: GitLab Pages
- CI: GitLab CI