skysight-inc/HackerNews huggingface dataset:
It's not just simple appendChild calls. I actually worked on an app which updated a large table – displaying file metadata, checksums calculated in web workers, etc. for a delivery – and found React to be around 40+ times slower than using the DOM[1] or even simply using innerHTML, getting worse as the number of records increased.

The main trap you're falling prey to is the magical thinking which is sadly prevalent about the virtual DOM and batching. Basic application of Amdahl's law tells us that
the only way the React approach can be faster is if the overhead of the virtual DOM and framework code is balanced out by being able to do less work. That's true if you're comparing to, say, a primitive JavaScript framework which performs many unnecessary updates (e.g. re-rendering the entire table every time something changes) or if the React abstractions allow you to make game-changing optimizations which would be too hard for you to make in regular code.

Since you mentioned batching, here's a simple example: it's extremely hard to find a case where a single update will be faster because the combined time to execute a JS framework and make an update is always going to be greater than simply making the update directly. If, however, you're making multiple updates it's easy to hit pathologically bad performance due to layout thrashing[2] when the code performing an update reads something from the DOM which was invalidated by an earlier update, requiring the browser to repeatedly recalculate the layout.

That can be avoided in pure JavaScript by carefully structuring the application to avoid that write-read-write cycle or by using a minimalist library like Wilson Page's fastdom[3]. This is quite efficient but can be harder to manage in a large application and that's where React can help by making that kind of structure easier to code. If you are looking for a benchmark where React will perform well, that's the area I'd focus on and do by looking at both the total amount of code and the degree to which performance optimizations interfere with clean separation, testability, etc.

EDIT: just to be clear, I'm not saying that it's wrong to use React but that the reasons you do so are the same as why we're not writing desktop apps entirely in assembly: it takes less time to build richer, more maintainable apps. The majority of web apps are not going to be limited by how quickly any framework can update the DOM.

1. I partially reduced that to a smaller testcase in
https://gist.github.com/acdha/092c6d79f9ebb888496c which could use more work. For simple testing that was using JSX inline but the actual real application used a separate JSX file compiled following normal React practice.

2. See e.g. http://wilsonpage.co.uk/preventing-layout-thrashing/

3. https://github.com/wilsonpage/fastdom
Accessibility is a point I didn't think about at all. Thanks for reminding me, it's really something that is all too often forgotten. JavaFX supports ARIA and all standard controls have accessibility built-in. But I have no expertise to actually comment on the quality of accessibility features in JavaFX.
Yeah, but this is significantly worse than performance comparisons that have already been done. See here for example:

http://elm-lang.org/blog/blazing-fast-html

TodoMVC is way more realistic because items are actually edited, you are not just infinitely adding DOM elements. (Why would you even do that, instead of just showing the number of elements that can fit on the screen, then just reusing those?).
You are possibly right, although I suspect the kernel change issue is less of a problem than the second. Getting middleboxes to pass UDP unmolested....
i facing the same problem :(
Your money is still in euros though, so if the whole currency gets devalued it does not matter which country holds it.

Sure, but then we aren't talking about the Greeks, but about all the Europeans.

And escaping the devaluation of the Euro by jumping to BTC seems like a foolish move: http://www.cryptocoincharts.info/pair/btc/eur/kraken/1-year

There are capital controls preventing transfers to Greece, that would prevent yiu from transferring from Germany to Portugal, so your solution would not work.

As far as I know, the controls limit the amount from Greece, not to Greece. Of course, withdrawing can still be a pain, but so is exchanging BTC for Euros.

In my case, I'd just take a short trip to Spain and withdraw there, or if Spain is also under control, transfer some money to any of my friends abroad and ask them to send it to me in cash.

And if they can take it from one bank they can take it from another.

Who is "they"? The Greek government can't simply take from a German bank, even if the account holder is Greek.
Billions of people who aren't white were using and invented emoji before white people even got to them.
Hmm. Java went through this with AWT and Swing. You can have "identical on all platforms, nonnative, missing some native features and look&feel" OR "native features, look and feel, but different across platforms". Embedded browsers are closest to the former.

It sounds like solution (for spotify at least) is better methods for each platform of creating a GUI around web services. Microsoft have sort-of had a go at this.
I have never thought of emoji as having any particular skin colour, until this recent trend to make skin colour selectable.

Emoticons and emoji have traditionally been displayed as yellow cirlces with large faces. White emojis have been the exception, not the rule. I have never had a problem with being represented by a character with Jaundice (a medical condition turning your skin yellow).
Sadly, the main governing equations of weather (eg Navier–Stokes equation for fluid dynamics) are still very much non-linear. Non-linear does not mean unpredictable, it just means that it is very hard to solve (currently no analytical solution for the Navier–Stokes equation) and that, well, the system is not linear. (And it applies to gas, btw.)

For weather, other important effects are phase change of water at given pressure/temperatures (which can store large amounts of energy), radiative transport (again, non-linear equation, not solved) and heat transfer (non-linear equation, solved (easy)).

For forecasts, you also cannot measure the full state of the system at any point in time. This makes it a very hard problem - otherwise weather forecasts would have been perfect ages ago. With the advent of cluster computing and measurement satellites, it is now possible to improve the forecasts vastly, but it's still hard.
The only problem is that we don't know if these transactions happen between different parties or it's just a guy holding 22% of BTC in circulation mixing his portfolio ;-)
> Fun fact: KDE 4.x depends on ruby in most distros. Do you know why? Dolphin ships with a ruby script to update some folders (don't remember what it does). Nobody runs it. That's it.

Why did they allow an additional dependency on Ruby in? It seems like perl or python would be the more logical choice, given they'd already be on the system (heck.. maybe bash?)
Tesla is warrantying the battery for 8 years, so the earliest you would pay for a battery replacement would be the 9th year- but they might very well last much longer.
Microsoft didn't care for years, but as more users switched they eventually started caring.
<Icon is="Icon" />

<span is="span" />

<CodeSmell is="Stinky" />

Besides, you kinda lose all the advantages of using javascript to style, which is complex computations and co.
Furthermore, certain types of ELISA have been in use in clinics and hospitals for many years ... but they have always required venous sticks and a lot more blood. ELISA has also historically been expensive due to the amount of antibody required--the microfluidics approach is much cheaper in this regard.
> But doesn't static linking JUST link in the used features of the linked libs?

No, not if it works like it does in C and C++.

Lisp used to do that, back when Symbolics still existed; it was called tree-shaking, as in "shake the call graph tree to see what falls out". The main function calls functions FOO, BAR, BAZ, which call FROTZ and QUUX, which call... and remove everything not in that tree.

Of course, this gets to be equivalent to solving the Halting Problem the moment the EVAL function is called, so if the tree-shaker found any mention of EVAL anywhere in the code (probably after it had removed the provably dead code) it punted and linked in the whole Lisp runtime. It was the only viable solution, really, especially given how creative Lispers can get...
Regardless as to what this project is trying to achieve, I appreciate that the site is using all inline styles and is surely using this project to have made it easier!
I agree in general, but the 'vim in combination with a few small plugins may lead to your whole computer locking up' is extremely misleading.

It's the editor which has frozen, not the whole computer. And the plugin in question is a fairly complex autocompletion / analysis plugin for python. There's a bug listed in that thread, to do with it scanning all the files millions of times, but the big problem actually isn't bloat, in this instance, it's the non-async nature of vim. neovim should, I hope, solve the 'totally unresponsive' problem, and hopefully someone fixes the rope/vim interaction re-scanning all the files bug.

But it's not bloat, per se.

If your whole computer is locking up due to this, then that's a scheduling issue, and you could try switching scheduler, or lowering the 'nice' priority of that program.

Not that we should have to care about such things - that's pretty terrible.
When the predicted phenomena are myriad, and the predictions are consistent and keep getting more precise, throughout an ensemble of models. The models are based on explanations of phenomena that are known because they are observed and understood physically.

Constrasting that with a horoscope, where there are no underlying physical (or even spiritual) models and no chance of falsifiability.

There is no explanation that is barely even close to explaining the enormous cluster of observed global phenomena.

For the record, the probability of the current climate being explained by mere chance is ridiculously low, to the point where it is practically irrelevant. I won't provide links here; everyone should be competent in googling that up.
Startup Sues a Domain Name Owner to Grab a 16-Year-Old URL
If your experience is that designers do all the CSS and no JS, then feel free to continue using that approach. Some of us either have good designers who adhere to Atomic Design and know some JS, and some of us have to translate mock-ups into HTML/CSS.
I like both
A minimalist CLI-only Linux installation was still possible in around in 2 megs of RAM in 1994.

A minimalist XWindow installation was possible with a 40 megabyte hard drive and 4 megs of RAM over a 386 CPU. (That's similar specs to what 68K-based Sun workstations had perhaps a decade before that.)
I think the formatting concepts are fine but I don't agree with using the imperative. Commit messages should read as if you were explaining what the commit does. "Because git does it" isn't a good reason to do something.
This is one of the biggest sources of bloat. In the node and ruby ecosystems especially, dependencies proliferate exponentially, where an application pulls in 12 libraries, each of which pull in 12 of their own, which each pull...

Downloading the depedencies for Ghost, the node blogging platform with the explicit goal of simplicity and minimalism, takes me minutes.

Compare this with the status quo when writing programs in C, where you might link to 4 libraries total, one of which pulls in 2 others as dependencies.

I've come to suspect that the super convenient package managers that all the "modern" languages have are at fault for this.
Go is especially awesome for writing microservices.

500px.com have a lot of these, "Breaking the Monolith" presentation:
http://www.infoq.com/presentations/500px-services
If only.

> shows a selfie [taken from somewhere]

The software only sends a hash of the "map" of the face to Mastercard for comparison (or so an earlier Dutch article on security.nl put it). They can never show you the original image again.
Ok, so everyone has pointed out how insecure this would obviously be, and all the simple ways in which you could fool it.

But, I'm left wondering, did the guys at mastercard never even think this through at all? This is people's money after all. It needs to be safe. Did they not even consider that, as soon as this is rolled out, people were going to see money disappear?

I can't believe they didn't think of that. Which makes me wonder, why am I even reading about this at all?
It's not laziness or stupidity (well, it might be sometimes, but certainly not always).

It's using your time to do something else, such as improving security, or adding a new feature. Some people seem to be talking as if it automatically takes the same amount of time to create efficient code as inefficient code, and the idiot developer has simply forgotten to add the -run_faster option on the compiler.

I'm involved in a project at the moment where a team of developers and engineers have spent much of the last month trying to get response times in some very specific circumstances in an application down to an acceptable level. That's not because they are either stupid or lazy. It's because these things are hard - there's an awful lot of moving parts, and an awful lot of things that can go wrong in each of them.

When they get it down to an acceptable level, they'll ship it to the users. It won't be blazingly fast, but it'll be good enough. They could definitely spend longer tuning it further and getting it going even faster. But every day they do that will be a day longer until the features that the users want are actually available to them.
People who complain about bloat are usually complaining about features they don't use. Of course watch what happens when people start doing metrics and optimizing their UI for "common uses" - turns out you're optimizing for non-existent users (see: the Ribbon).
I don't think Atom wants to be a basic text editor in the first place. It's shipped as a basic editor but the killer feature is that you can easily hack together extensions to suit your needs. It's a tradeoff: you pay for the html+js engine, but get a lot of potential developers.
That being said, having worked with Atom on a larger project I can't confirm it's slow.
I'd like more information about how small law partnerships are formed and managed internally. That seems like the best organisational strategy for talented developers to emulate.

Any well produced X-Y-Z-llp site should be able to generate as much business opportunity as these freelancer operations, but with the added mutual benefit of being able to create lasting business relationships.
Is there any movement among the consumers to boycott licensed taxis as a form of protest?
If anything, the site has gotten markedly worse from a reliability standpoint in recent months.
As simple matter of showing how the local software works: The comment was gray when I found it and upvoted it, so I don't think replies undo downvotes.

The UI of this place is terrible on mobile. Fingers aren't styluses, and nobody (out to three decimal places...) uses a stylus to interact with a mobile phone.
Yeah, but if you chunk the items (groups of 10, lets say) in components, you can return false from shouldComponentUpdate in all but the last component, and therefore be fast.
I haven't seen many people mentioning this problem before. I've seen it come up in discussions on the current AMD GPU lines. Hard to say who is to blame, but it's rarely obvious just how many problems there are before buying a card. I got a cheap R7 260x which seems to have trouble with waking up from low power states. Some people even made custom BIOS's to fight the problem.

I don't know how more modern stuff like accelerated transforms, canvas, WebGL or DirectWrite play into that equation. Browsing seems to pull out GPU's from the lowest power modes constantly, which might cause these problems on a wide variety of GPUs.
Are you sure there's inefficiency? Do you have specific points in the code or behavior which are obviously inefficient, or does it just feel "too big"?
From personal experience I'll just use ES6.

It's not about the HTML-like JSX part using ES6 or using native classes to extend React.component(with limitations), but simpler object literals, fat arrows and { foo: foo } becoming { foo } make React code look much better. I can endure the ending semicolons, parens and brackets.

Now you don't really gain too much by opting for CS over ES6 for React. And with React's adoption of Babel I think ES6 is going to become the primary way of writing React apps.
Pessimist. Again, look at cities where the free market provides transportation. No need to speculate.
It wasn't just react, I was definitely doing unneeded state changes, and I got it to the point now where there is no noticeable delay.

One big issue was that I wanted dependent fields to update as-you-type, which also meant validating as-you-type. I added a timer to delay that so that this wasn't all running on every single key-stroke, but wouldn't update until you stopped typing.

Reducing the number of dependent values in the DOM tree at a single time helped a lot too, and there were logical categories to split them into. My validation code was not particularly optimized either, since it was originally designed for batch-processing.

I really don't get huge concerns people have with performance. I find chrome's profiling tools to be very primitive to what I'm used to, but they were more than adequate for me to steadily improve performance.

There's probably still some improvements to be had, but right now there's no issues with responsiveness on mobile, so I stopped looking.
>In other cases like where elements in the middle of a table are updated, you would get into a mess writing vanilla code, either complexity or performance wise, because you'd have to traverse the DOM to get to where you need to do updates and do each update individually.

If you have a table and want to edit information this is trivial to do in a React like way without React. Edit button stores reference to the row, edit values, update data store, render out new row element, remove element, insert new element. Yes, React will generally be less code and the argument becomes whether this is more complex, which it is, but I'd say neither the complexity or performance truly suffer. I bet the performance will be faster as you removed diffing entirely and React will have to perform your logic anyway.
As someone who hung around a few usenet discussion groups well into the 21st century, the problem was less "spam" and more "trolls and kooks". It only takes a very small number of people to completely disrupt a group, and no, "plonking" was not a solution that worked. A new usenet would need some sort of moderation system.
I vastly prefer HTML with searchable text, easy copy-pasting capability, easy indexability, etc. to PDF with its outdated printed-page metaphor.

On the other hand, it's Knuth and TAOCP, so I can't really complain much.
They did about the telephone, though:

>"The Americans have need of the telephone, but we do not. We have plenty of messenger boys." -- Sir William Preece, chief engineer of the British Post Office, 1876.

Radio, planes and xrays:

>"Radio has no future. Heavier-than-air flying machines are impossible. X-rays will prove to be a hoax." -- William Thomson, Lord Kelvin, British scientist, 1899.

The grand canyon:
>"Ours has been the first, and doubtless to be the last, to visit this profitless locality." -- Lt. Joseph Ives, after visiting the Grand Canyon in 1861.

Oil drilling:
>"Drill for oil? You mean drill into the ground to try and find oil? You're crazy." -- Workers whom Edwin L. Drake tried to enlist to his project to drill for oil in 1859.

Nuclear energy:
>"There is not the slightest indication that nuclear energy will ever be obtainable. It would mean that the atom would have to be shattered at will." -- Albert Einstein, 1932.

The Germ theory:
>"Louis Pasteur's theory of germs is ridiculous fiction." -- Pierre Pachet, Professor of Physiology at Toulouse, 1872.

Brain surgery:
>The abdomen, the chest, and the brain will forever be shut from the intrusion of the wise and humane surgeon." -- Sir John Eric Ericksen, British surgeon, appointed Surgeon-Extraordinary to Queen Victoria 1873.

All taken from: http://www.rinkworks.com/said/predictions.shtml
The ribbon gets knocked a lot; but the median word processor user has zero experience. The ribbon gives them a fighting chance to find what they need. At the expense of 'expert users' with their idiomatic expectations.
>because that's how anonymous human behave

You mean pseudonymous humans? Reddit has a karma system, people can see your comment history and so on.
The way CSS in React should be is not to be.
If you're okay with not having "authenticated pulls" (i.e., the request from the CF edge to your server being unencrypted), Cloudflare gives you SSL for free. Their SSL config gets an A+ on SSLLabs tester, too.

Far from a solution to the SSL problem, but an interesting and free option for a lot of sites that otherwise would not bother with SSL.
how do you define content creation

lol, and how content creation become business model
Looks like Apple Music is an Ember.js app
If android can support multiple browsers, why can't Apple?
I have been doing web apps and websites for a long time, and when I first saw this, it looked so wrong but felt so right.

Inline styles were impossible to maintain. Even if these (reactCSS) are rendered inline, it's easy to maintain, easy to follow, easy to change.

Javascript used to refer to making things move around and handling click/hover events (javascript was the DOM language). Now it's the entire application.

what am I trying to say...? it seems wrong, but try it out and see if your concerns don't just go away.
What is your practical issue with it? I know it feels wrong at first, and by default performance may not be as good, but it makes sense to colocate the trio: one component into one file.

If you already use a methodology like BEM or SUIT, this is just a natural extension of that.
Great article. It was 1997 I believe and my dad and I sent each other a message over AOL instant messenger for the first time. It felt like magic to communicate that way. The phone was few feet away but this seemed futuristic and awe inspiring.
There are people who write entire sentences in emoji. It is a written language that is understood by speakers of all spoken languages. This just makes the language more expressive.
I've never seen any builder that outputs js to that[1]. Does anyone know what he's using?

[1][ https://raw.githubusercontent.com/casesandberg/reactcss/gh-p... ]
Fabled CD-playing SNES-Play Station prototype found in a box
that doesn't help. The phones don't connect to localhost they connect to a PC
Credit card companies already have the perfect "security" measure: retroactive limited liability for stolen cards. Nobody loses money because someone steals their credit card.

As such, everything the card companies do in the name of "security" is not to prevent people from losing money—they don't need to solve that problem. They just need to solve the perception people have that credit cards are insecure. In other words, all credit card security (yes, even chip-and-pin) is security theatre. Whether it works or not, it's not there to work; it's there to feel good.
The Firefox/native version of the page works much better than the jQuery version. Both are a little bit janky with touchpad scrolling, but the native version allows you to scroll to the next page before waiting for the animation to finish. With a mousewheel, the native version is far better and acts as you expect; the jQuery version just feels like a terrible hack and doesn't let you scroll where you want, when you want.