esailija

Read the linked post. Css variables are nothing like macros like sass's `$foo` and css might support macros with sass's `$foo` syntax in future.

Tooltips that flicker as you move mouse on the page feel really cheap. If you look at native tooltips, there is delay that waits for your mouse to "settle" to show the tooltip so that it doesn't flicker.

> Pedantically correct syntax parsing (list, script and expressions), to the extent possible in Javascript.

What does that mean? If it's possible to write x86 that runs linux in JavaScript, why is it not possible to write a parser?

Also all the stated reasons for using native are actually wrong and just as possible in web app, or will be by end of 2016.

I didn't know React was born by taking another library and removing all the polish and most features from it and then publishing it with almost the same name.

> Where the data resides is not a distinction between web apps and native apps.

Huh? The data is only accessible to native app after you have installed the app on a device. If you only ever use your own one desktop, then it's probably hard for you to see this. Can you even try to imagine that you cannot just install arbitrary native app on let's say, your friend's device to access your data? But you can easily "install" a web app, since technically it's just a website like this one.

> What do you mean with this?

http://nolanlawson.com/2015/06/30/safari-is-the-new-ie/

> However, one advantage that native apps have when it comes to accessing cloud data, is that you can still access and update that data even when you have no connection to the internet.

https://developers.google.com/web/updates/2015/12/background...

> True, but web apps will always be removed from the underlying OS's "metal" by at least one degree, no?

Not always now that Web Assembly will be implemented by browsers. (Not to be confused with "asm.js", see https://en.wikipedia.org/wiki/WebAssembly)

Ideally web app and its data is instantly accessible anywhere, not just on your desktop. They bypass any possible install restriction (or AppStore restriction, which is why Apple is deliberately keeping Safari in 2010).

The look & feel argument is total bullshit at least for me. Every native app I am using is completely different. The only consistent look & feel is with ms office apps like excel, word and powerpoint.

Performance is also a lot about how and who wrote the app rather than if the app is native. It's just harder and requires a lot of knowledge to make javascript app perform well, but it's not some impossibility.

And yes, standards are still creating too high level APIs and it takes forever to gain more and more access to the same things native apps have. But that will get better due to extensible web manifesto.

Lol I bet you use tons of javascript apps without knowing it.

I find whenever some code is "simple", it's just not really doing anything at all and whatever it's actually doing, it's doing it badly. E.g. it's not handling anything other than some basic cases and performs horribly.

Firefox and Chrome are application platforms, like your OS. It doesn't make sense to count them. They don't only run youtube, unlike VLC which is only a media player. Otherwise VLC counts as 20 GB (or whatever) for the OS as well.

So you downloaded 30 MB of client side code instead of 100kb. Don't see how that's a win. By "higher quality" you mean placebo (see foobar2000 faq) or some DSP filters?

The spec language "SHOULD" is not same as "MUST" at all.

> Also, a tiny bit of JS and no ajax can solve that easily.

No disagreement from me that JS solves these issues.

Is there a spec that the browser must stay where it is? Otherwise I would just use a form targeted to a hidden iframe. Still it's not usable here since you won't see your vote or comment or anything without reloading the entire page.

So you are saying one shouldn't use JS to implement voting and comments but instead voting and comments should interrupt the video and then one uses JavaScript to restore the playback position. You also imply youtube should have waited for 6 years or whatever for video playback to even be possible without client side programming.

> Maybe browsers could even agree on a standard to refresh only part of the pages by querying the server themselves.

Maybe browsers could also agree on implementing all needed applications in the browser. Then you just make <youtube> tag and you have implemented youtube.

That's hilariously clueless. Do you think youtube is just a <video> tag?

So I just told you about a few things that are physically impossible in static languages, therefore dynamic language cannot be a static language subset. For example, you first need to prove that it's possible to tell a static language that "for now, for this execution, I don't care about these 3150935031 trillion code paths being correct, just these 123 code paths, so just compile and do it". Without that you are just trolling.

Did you even read the article? You can define tasks in package.json and use `npm run ...` instead of defining them in gruntfile and using `grunt ...`

It is nothing like that. Npm/node is the task runner and you are not doing anything yourself that you wouldn't have to do with grunt/gulp anyway. They are the equivalent of making a function like `add(a, b) { return a + b; }` instead of just using the `+` operator that is already there, it is nothing like jQuery vs "raw javascript".

> The code is exactly the same except that you don't have type annotations with dynamically typed languages.

No they are not the same.

Here's some key differences:

- If at runtime an execution doesn't even reach the code, then it doesn't matter at all for that particular execution whether the types were "correct". With static typing you need to get it right for all possible executions before you can even compile, regardless of how unlikely or unimportant those executions are. In practice, having to get it all right for all executions before you can even run one is a massive productivity loss in a lot of scenarios.

- Not only might a "type" of something in a dynamic language not be expressible statically (at least in majority of static languages) in the first place, dynamic code is never dependent on any particular type. You might get an unintended "type" in and the code can still work. There is a dependency on infinite amount of unexpressible "types".

You are completely ignoring the point of dynamic typing and you are using it as if it were static typing without annotations, by your own admission. But that's your problem. Similarly I could also use statically typed language as if it were dynamic and then claim that static typing is exactly the same as dynamic except more verbose.

"I believe in most other countries, that aren't the United States, people pay their internet usage by bandwidth used." that's... false

Majors, especially majors that are coming often with no lts for older versions, should make minimal breaking changes.

I was referring to mental rotation ability, I clarified it in an edit.

I also don't have time to go into the studies you linked about general differences but similar studies have been debunked before. For example with 1.5 day old infants where the experimenters knew about the sex and their bias subtly corrupted the experiment and it did not reproduce when the bias was truly accounted for.

The myth is that the differences (in mental rotation ability) are innate or "biological", not that there is differences (in mental rotation ability) in the first place.

You mean evolutionary psychology, not biology. The former is basically a pseudoscience and the latter makes no such claims.

There's plenty of studies that debunk the mental rotation myth:

http://www.sciencedaily.com/releases/2010/09/100915080431.ht...

http://www.researchgate.net/profile/Angelica_Moe/publication...

There's also a study showing the field of neuroscience having a tendency to make unsupported and untested claims to confirm stereotypes http://link.springer.com/article/10.1007%2Fs12152-012-9169-1

I am referring to usage of generators without promises (or rather code that uses generators in a way that it wouldnt matter if promises or thunks were used). And even then I didn't say that you couldn't, even when using promises and generators together most people make their code unneceasarily sequential.

There is no benefit of io being async in itself until you have many users. The immediate and more accessible benefit is speeding up individual requests due to the ease at which you can perfom io in parallel. But if you just sprinkle await/yield everywhere (which everyone unfortunately does), you don't even get this benefit.

You need to configure or change your promise implementation if uncaught errors fail silently.

In any case, logging error gives you no information anyway. Just try running: `console.log(new Error("..."))`. So at the very least you should do `catch(function(e){console.log(e.stack);})`

(disclaimer: I am the author of bluebird)

Thank you.

I must say the most prominent feature of bluebird has always been "debuggability" (not perf). Long stack traces, unhandled rejection reporting and warnings for many of the mistakes you cover (coming in 3.0, some of them listed at http://imgur.com/a/t3xng) are just priceless, especially when working with people who are not promise ninjas.

It's just mountains of unnecessary extra code that is error prone because you have to manually wire it. When you chain a promise or promisify a callback instead of using a deferred or the promise constructor (both are just as evil here), the wiring is done implicitly and there is a lot less code.

Edit: What I mean by "wiring" is that you need to make sure that in all successful code paths `deferred.resolve` is called and that in all erroneous code paths (not always a single try catch either) `deferred.reject` is called.