JavaScript is more complicated because it's more simple.
Yes. Or as I've heard someone once describe it in a moment of zen: JavaScript doesn't have a few screws loose. Its screws are firmly fixed, but everything else in the language is loose.
JavaScript is more complicated because it's more simple.
Yes. Or as I've heard someone once describe it in a moment of zen: JavaScript doesn't have a few screws loose. Its screws are firmly fixed, but everything else in the language is loose.
Me: "But but... we already sent the previews to the client... and he approved.... AGGGGGHHHH!"
Think a few images is bad? On the whole you could probably still have those renegotiated and replaced fairly easily.
I (or rather the project manager assigned to this project. Heheh....) had the pleasure of dealing with this particular problem with an entire batch of font families that the customer had not only signed off on, but had promoted to being part of their brand identity. Yeah ... that was not nice.
Which means, as your code snippet shows, the text can be lifted directly by a bot
The source-order of the letters is not the on-screen order, which is assembled by shifting coordinates using transformation matrices. The on-screen order is what you actually have to enter; not the source order. So a bot cannot lift the text directly. It atleast has to discern how the characters were shuffled.
(Ofcourse, with humanly readable translate()
transformations like this, that's still easy to the point of being trivial, so this is still a complete failure.)
Realtek is known for absolute shit software, their drivers are generally worse than any other manufacturer.
Remember when Microsoft re-engineered audio drivers to run outside of kernel space, so that 'bad drivers' would stop taking down systems?
In hindsight... that was probably to mitigate the Realtek problem...
Have any of the mobile developers using the hamburger menu concept done usability testing on it?What were the results?
Surprisingly; yes, there are mobile developers that have done some actual real user testing regarding 'the hamburger icon'.
Afaik the results were split about fifty-fifty between users that managed to locate the hamburger and managed to understand that it hid a menu of sorts with actionable items and users that didn't.
Add the text 'menu' or similar to the hamburger icon and it raises success by about 10% to a better 60%. Add a clearly demarkation around the icon, mimicing a button, and the hint of the item being tappable/clickable raises success to about that same 60%. Do both and get somewhere between 60% and 70% success rate.
And now for the kicker: LEAVE OUT THE HAMBURGER ICON and keep only the text and button markings and your success rate will remain between 60% and 70%.
In other words; the contribution of the hamburger icon itself is zero and we can probably safely assume that the 50% of users that managed success in the icon-only case, only managed success due to prior exposure to this broken piece of user interface to the point where they underwent the virtual equivalent of having it beaten into them with a stick.
You have a working scrollbar, it's right there at the bottom right of the topic:
The substitute you are offering to fill this gap is nothing more than a bastard lovechild of basic previous/next paging and a progress bar. It is nothing close to what a scrollbar represents.
Scrollbars operate on a stable locality of reference and have a grip that you can grab and move up or down a fixed amount to move up or down a corresponding amount of viewport 'pages', in a ratio that you have mentally mapped to the area of the scrollbar.
Your poor excuse of a substitute neither offers the ability for direct interaction with the scroll bar nor offers any grounds to establish the cognitive relation between the progress bar part of this bastard child and the position in the scrolled page. I'd go sofar as to say that it actively interferes with user cognition: it operates on a horizontal axis, perpendicular to the actual scrolling axis, obscuring the fact that there is any relation there to begin with.
The paging portion of this substitute doesn't even offer normal paging. Click the up or down arrows -- Up & down arrows on a horizontal bar, another cognitive mismatch. -- and you move all the way back to the first item or all the way forward to the last.
This makes that it basically fails on all fronts.
Sam comes out with a nice summary of Discourse's perf problems.
which states that:
This specific example is just an illustration of the endemic issue. In React and some other frameworks you just render and don't carry around the luggage of "binding", instead you just rerender when needed. This approach means that you don't need bookeeping, the bookeeping is the feature that is killing android perf.
Oh right. Because diffing the live DOM tree against a newly cooked string and performing piecemeal updates isn't slow at all, right? Well sunshine; guess what...
No; the real problem is inefficient bookkeeping and creating multiple bindings that all update class name lists and all touch the DOM on their individual time. Change that to perform class name bindings completely in JS space and coalesce all of it using batched event handling. Then you have one single string that gets assigned directly to a node's className
property once.
I think devs are realising that building everything clientside isn't the way to go.
Building everything clientside isn't the problem.
Trusting on people that have poor insight into algorithms performance and excruciatingly poor insight into what makes JavaScript and the DOM tick to build everything clientside; that is the problem. And that's par for the course when you take a bunch of people that have been treating JavaScript as a 'toy' for 10+ years while they happily shat out the most grotesque pieces of code possible, of which the mal-performance would all be masked away behind the immense amount of horse-power available on the server.
Frameworks help: they simplify and provide application guidance, but most can still be easily subverted into doing the wrong thing if you do not have the first clue about what you are doing or the environment you are doing it in. Infact; it may very well make the situation worse. {{ Insert witty reference to C++ and loaded footguns here. }}
Ofcourse you can cite education or evangelism as the solution, but that is a battle you will LOSE when you are by far outgunned by idiots that will all too happily provide further fuel to the fire by giving 'helpful advice' or offering their 'profound knowledge' to others.
Effectively SPAs and JS are stuck in the uncanny 1999 PHP valley. It's going to hurt immensely to get it to move out of that sinkhole.
This guy tries to use his street cred to make her sound less terrible. His claim to fame is, basically, knowing jQuery and CSS. Big fucking deal, guy.
Not a big surprise.
The few times Coyier writes something original and current for his CSS Tricks site, it usually ends up in sub-optimal hacks riddled with undisclosed/undiscovered caveats. The rest of the content are (optionally outdated) rehashes and summaries, or 'guest' posts.
I place that between quotation marks, because most are actually 'copied-with-permission' posts masking as content written originally for CSS Tricks. A lot of that material is also donated by people that seem to have equally questionable knowledge and are simply parroting others or reinventing square wheels.
All signs point to the guy being a firm part of the 'copied-from-SO' generation himself, and in this comment he even freely admits so, while he continues to see himself as some kind of 'rockstar' or 'cowboy' (i.e. roughing it out). A lot of the vitriol that is rightfully being spewed back in Lara's face is maybe hitting a liiii---tle bit too close to home.
I then applied the cluebat and reminded those morons that the law allows me to send them a cease and desist letter (enforced by a monetary penalty), that any fees for a lawyer would come out of their pockets and that I actually am not obliged to remind them to stop that shit. I actually could have sent a C&D immediately after the first ad
Quite surprising how much a little legal pressure can suddenly make the impossible, possible. No?
In practice, you have to have half an hour 'off the clock', but the EU doesn't know or care whether you're actually getting a break in that time. If you need to work through your lunch break you'll be expected by your employer to work through your lunch break, but you can't count it towards your required hours, and if you're paid by the hour or get paid for overtime it'll be unpaid.
If your employer expects you to work through your lunch break, then they are - with very high probability - involved in illegal shenanigans.
Even if there is no explicit law that states an employer is required to give an employee a half hour break, as an employee you are usually still legally required to take a break. In that event your employer cannot force you to continue working, because they cannot force an employee to perform an illegal act on their behalf.
Usually though, there are additional provisions in law that make it legally required for an employer to force an employee to have a timely break.
He actually talks about that in the article!
So he did. Didn't read far enough in to it. (Too wall-of-text-y for my tastes.)
Here's a more interesting thought experiment: what would a real-life ad-blocker look like?
"Want to do some work, right? Fuck you. I've got this real big bunch of updates. I'll reboot a couple of times as well."
Windows 7 can still be configured to download and install updates on demand. What you're describing is either Windows 10, or Windows 7 man-handled by retarded system administrators that don't know how to configure updates to deploy after-hours.
You mean I can use C# in Firefox on Linux, and write ASP.NET MVC in JavaScript?
No on the former, but technically the latter is kind of possible ...
Wait, does that mean if I get Node on Chakra, I can use async/await with Promises?
They recently accepted patches that would allow Node to run on MS's JS engine Chakra, so maybe things will change?
Not only that; but the Chakra build apparantly has better performance than the V8 build and implements a boatload more ES6+7 features than the V8 builds, mostly because the V8 build that Node uses is shit-old.
That's three concepts I don't want to encounter before breakfast!
You're OK with them after dinner then?
WtfCorp corporate could use an oldtimer enema.As well as a management enema.
That'd be a lot of enema.
Would there be any functional bowel left afterwards?