At least here (Finland) that kind of agreements are only legal for board level positions and even then for half a year. Some conversations around the subject seems to indicate that might also be similar case in the other side of Atlantic
Blackest black and whitest white used together will trigger my dyslexia and makes reading almost impossible. Even though I have very mild case of dyslexia! But like you said, slight tint makes wonders. Even in my case.
Chernobyl is still in use though. At least the reactors which weren't damaged. But only thing that could be done would be putting the radioactive material from one hole to another.
Could not sign-in/create account to the blog comment thingy, so asking here:
Is there performance numbers available per browser in Android somewhere and to which browser the mentioned numbers apply?
Traditionally the vendor shipped browsers in Android are abysmal, out of date, probably insecure and not standards compliant. So what I am really interested about is stock Google Chrome or Firefox performance. And if these numbers are from either one of those, it would be nice to know.
Firefox on Android is much slower in every JS test I've ever seen. We only test against Chrome on Android. The 5x perf improvement is across the board but slower devices benefit much more. You may not notice a 200ms improvement on say an iPhone 6, but you will sure notice a 1000ms improvement, or more, on older and slower android devices.
What does that have to do with HTML5 apps? In the browser, when HD-DPI support was added every page started using HD-DPI font rendering, HD-DPI CSS, HD-DPI SVG, only image were still lo-res
Conversely I still have native apps that are low-res only because updating them to HD-DPI meant shipping a new app.
Indeed. Except that, to get it, you-developer actually had to ship an updated browser with your "app" -- basically the same as any native app, except that instead of being "just turn on this setting in a plist and recompile", it means refreshing your little in-house fork of a massive browser project that barely anyone understands. Clearly Valve cannot be arsed to do that, so Steam keeps looking like shit more than 3 years after these screens appeared.
The universal toolkit is not so universal if every app ships its own custom version.
I don't use Firefox anymore because it's so much slower than Chrome, especially when using firebug. Speed IS important. Whenever I see Mozilla release new versions like every day, with new features that I will never use, I wish they would just drop everything and focus on improving performance.
There are many of us are Mozilla who focus primarily on performance improvement. The fact is, though, that performance improvements usually are not splashy enough individually to be added to release notes. "Improved performance measure X by 15% in circumstance Y!" is not going to thrill anybody, even if it is important. Please don't take the release notes as representative of where our engineering effort is spent.
I switched back to firefox about 6 months ago now. I'm using nightly, and the built in developer tools are good enough that I don't worry about using firebug anymore. I find the speed pretty good, faster than chrome for some things, slower for others. One area it does shine is implementation of es6 features, and syncing with my mobile firefox browsers.
I hear a lot of firefox hate, and while it certainly used to be true that it wasn't very good, it's no longer true.
When is the last time you used it? Or, what sites do you visit? The current speed of Firefox is quite good. Maybe Chrome could surprise me and be faster. I don't see how, right off.
I've generally found the opposite to be true; Chrome/Chromium have lately been slow as heck and buggy for me on the majority of the computers I've used, whereas Firefox has been less so (but still slow as heck and buggy).
Really, every browser is slow as heck and buggy, so to each his own ;)
In NUMA front Linux is, as far as I know, leaps and bounds ahead of FreeBSD, Solaris and Windows. All four platforms offer ways to tune process and memory allocations by hand, but Linux is only platform that puts lot of work to make automatic NUMA scheduling actually work. It is actually pretty difficult problem. Something to read if you are interested:
Size really is issue when dealing with mobile devices. Even from disk cache each KB increases startuptime by about 1ms (and jquery 2 is ~32kb minified, for < 2.0 lot more). Over cellular connection you can nicely multiply each KB by 100ms. This is even worse when you minify and concat your JS library dependencies, as most likely your cache headers expire way too fast for them. If you have bothered to set them at all.
Also, last time I checked jquery uses "querySelectorAll" for that fancy $("selector") syntax, which is slow as hell with every possible browser compared to "getElementBy*". This might not be issue with desktop machines, but you will probably lose most of your mobile users because of that. Jquery does also exposes very dangearous things from the API. For example: most of the time use of css modifying from JS just implies that your UI logic is fundamentally flawed (also, incredibly slow as poking CSS from JS will force full relayout which will make your mobile users throw their devices to wall or leave your site).
Jquery lets people cut corners which will give short term benefits, true. But in long term you are just killing your user experience. And like others said, people mostly use like 1% of the API, which has as easy native browser support.
The speed difference between querySelectorAll and getElementsBy* is entirely because of the difference between live nodelists and static nodelists. getElementsBy* returns a nodelist that reflects changes in the DOM in real time - this means that it's just returning a pointer. querySelectorAll copies the full result set into an array-like object at method-call time.
The flip side of this is that iterating over a querySelectorAll nodelist is significantly faster than iterating over a getElementsBy* nodelist. You really don't want to call .length on a getElementsBy* nodelist, because it's O(N) and has to traverse the full nodelist. .length on a querySelectorAll nodelist is just a field lookup. That means that when you combine the original call with one iteration, you're usually about breaking even with querySelectorAll.
Also, setting CSS properties doesn't for a full relayout; it just sets a dirty bit and the property. Setting CSS properties and then querying the DOM causes a full relayout. Unfortunately JQuery often does the latter in .css, which makes it slow as molasses. You can do direct .style manipulations all you want with very little performance penalty though.
> Also, last time I checked jquery uses "querySelectorAll" for that fancy $("selector") syntax, which is slow as hell with every possible browser compared to "getElementBy*".
Not true, and has never been true; maybe you confused jQuery with Zepto? "#id" uses getElementById, ".class" uses getElementsByClassName, more complex selectors go through querySelectorAll, and custom selectors through Sizzle.
> And like others said, people mostly use like 1% of the API, which has as easy native browser support.
Hard to argue with that statistic since it's made up!
> Also, last time I checked jquery uses "querySelectorAll" for that fancy $("selector") syntax, which is slow as hell with every possible browser compared to "getElementBy".
I seriously doubt you ever "checked". You would know that jQuery's selector engine (Sizzle) is optimized and uses getElementBy* when it can. You would also know that every browser has bugs in querySelectorAll, and jQuery's selector engine detects the bugs and routes around the browser bugs.
How complicated your query have to be to run into these QSA bugs? Don't forget that you are paying a very high performance cost for compatibility. I mean, how many people are still on Chrome 21 and Firefox 3.5?
jQuery might use querySelectorAll for its selector, but also looks for basic patterns and optimizes them by using things like getElementBy* eg. $("#test") will use getElementById behind the scenes, not querySelectorAll.
Except getting macbook to boot anything else than OSX or Windows requires bunch of stuff that I can only describe as 'hacks'. At least it was like so couple years ago (http://mjg59.dreamwidth.org/12037.html) and I haven't heard that things would be different today.
What.. version 1.8 and now there is Date support? Shouldn't this kind of stuff be aournd at version 0.01 when we are talking about data stores? You know, the only non-easily swappable piece of our tech stack?
It's really comments like this that make me scared to death of posting a project to HN these days (so I don't). Seems to be so common now.
It's getting quite common for me to just skip reading the user comments after reading the article. This was never the case before; the comments were -almost always- better than the article.
As a sidenote, I cannot even recall when I actually read the user comments on Slashdot. On the occasion where something pops up in the RSS feed; read TFA and move on to happier things that actually make me feel good. :)
I guess I'm not saying anything new. I really wish I had a solution other than asking -you- to please imagine sitting at the receiving end: You get excited to see your project on HN, you click through to comments, and the first thing that was said was ... that.
PS. You can call me a chicken for being "afraid" of these things.
Sometimes people get angry and irritated at stuff. That's ok. The tone is uncalled for, but irritated/angry comments often have legitimate gripes. Rethink should have had dates earlier, we just couldn't get it done.
I agree that people should try and be more kind with their tone, but I wanted to try and encourage you not to be afraid of criticism. People have good memory for good work and no memory for bad work. So if you post an atrocious project here, the absolute worst thing that might happen is that some people will write some negative comments and forget about you ten minutes later. It seems like a worst-case scenario most people can live with :)
It should have been, but date support is way, way trickier than it appears. Check this out if you want to learn more -- https://gist.github.com/coffeemug/6168031. It's bad that dates didn't get in earlier, but it would have been worse if we rushed a bad implementation. Sometimes one needs to pick the least of two evils.
