nawitus

A major problem with this analysis is not taking into account the number of battles fought. The article even states this:

"Alexander the Great, despite winning all 9 of his battles, accumulated fewer WAR largely because of his shorter and less prolific career."

The Bugatti Veyron shouldn't qualify as a Concorde moment, because there is a successor called the Bugatti Chiron.

"AI wouldn't have any of those so I'm personally confident that it'll have a much higher level of safety."

AI and perfect AI are different things.

Even if we have better tooling to make updating dependencies easy, there's still the fact that there's a lot of applications in production that are not maintained. If there are no maintainers there will be no updates..

"This just seems completely irrational. Do lenders imagine they're more likely to recover their money this way?"

In theory this punishment can increase the total number of loans paid, even if the individuals who default and lose their jobs won't be able to pay their loans back. Why? Perhaps the fear of the punishment incentives loaners to not default.

"I don't think torque is constant."

The torque is constant for the first 40% of the RPM, something like this:

http://image.motorcyclistonline.com/f/30634938/122_0910_03_z... http://www.global-greenhouse-warming.com/images/TeslaTorqueg...

The horse power increases gradually as RPM increases.

This seems to have a rather strong focus on speed.

Does the car have an emergency button to stop the driving?

Does it support automatic documentation generation for the API (kinda like what swagger + express.js does)? That's the biggest missing feature in Express.js for me.

Passport can be quite easily used with any framework, but of course an existing library can make it even easier. Though to be honest Passport.js is trivial enough that I don't see a need for it usually..

You can easily install types from @types these days: https://www.npmjs.com/~types

I believe the latest version of Visual Studio Code can automatically install the type dependencies from the IDE (e.g. a quick fix if the type definitions are missing).

So you love that people give feedback? Just because the application is now popular doesn't make that feedback invalid.

"Hmm... How about "let's reduce the need for and dependency on multiple frameworks"? When will that ever be a goal?"

That's not a realistic goal, because there's no common agreement on the framework API. If there were, every framework would have the same API already.

"Surprise, Polymer's API provides a possibility to define that."

Your point being?

"Oh. Right. 6, not 8. I wonder if I ever complained about the number of methods required? Nope, what I complained about is the amount of tedious boilerplate you need to write to implement the most basic and common of things."

You're not intellectually honest, so I will stop this discussion.

"What is the point of WebComponents, exactly?"

My point differs from the opinion of someone else (not sure who you quoted).

" As I'm already using a framework (there are dozens of them out there), what is the selling point of WCs exactly?"

To provide interop between frameworks, so that we don't need to write the same components 10 times for each framework. We can just implmenet it once, and use a native API to use it from any framework.

"Oh, right. "Use Polymer", how can I ever forget."

There are and will be other frameworks which support the Web Components API.

"maybe your goal isn't to "sell" WebComponents, but to sell Polymer."

The goal of Web Components are to sell a interop layer that is supported by many (or even all) frameworks. It's not supposed to be a framework that has the best developing experience.

The Polymer API is better than the Web Components API. The Polymer API is more high level than the Web Components API. This is not by mistake, it's by design. The higher level the Web Components API is, the more difficult it is to use by a large number of wildly different frameworks.

"We complain because WebComponents API is horrendously bad, and that was a deliberate design choice."

I don't think it matters much to be honest, because developers should use frameworks, just like they are using frameworks at the moment.

"Here's code to create one single property with one single synced attribute. One. single. property/attribute pair. One."

You need a "synced attribute" only for some frameworks, not all. Also, your example is misleading, because the two last methods are only needed to be defined once, so if you want 2 synced properties, the total number of methods is 6, not 8.

"Bad developer experience."

Use a framework.

"If WebComponents had better APIs, there would be no need for Polymer, would there."

The risk is too high to use the Polymer API for the Web Componenets API. In addition, the more complex the API is, the more likely it is for the browsers not to implement the API. It's better to have a simple native API and provide different frameworks for a good user experience.

"Because in your mind WebComponents === Polymer."

Or maybe he thinks that frameworks should be used, as intended.

"Polymer's API _is_ the Web Components API, with some helpers added for reacting to property changes, augmenting templating and a few others."

For that reason I think they're different APIs, even though Polymer's API can be considered a superset of the Web Components API.

"Specifically, they’d like you to use Polymer. The problem is that the Web Component API is really unpleasant to use directly, especially compared to React. That’s really holding Polymer back in the framework marketplace. Other WC-based frameworks like Svelte, Skate, and Stencil abstract away from WCs, treating them as a compilation target."

That argument feels like a non-sequitur. Polymer's API is different from the Web Component API, so even if the Web Component API would be unpleasant to use directly, that is not a criticism of a different API (in this case the Polymer API). Polymer's API is "similar" to the native Web Component API though, but it's designed to be easier to use than the native API.

Page refresh takes a longer time than client-side validation.

Needing a page refresh for input validation degrades experience.

"Then you would have to maintain two code pathways in two different languages in two different locations if you need to update the validation rules."

Not necessarily. You can use the same exact code, in the same location written in the same language.

The comment said "no Javascript", no "no SPA".

I think that's worse because it's more difficult to understand.

>Behavior customizability should come from tweaking the auto generated json config, and adding some HTML and JavaScript to higher order components.

Show me a single component on any platform which can be customized via properties to "do everything".

> Because of course people won't squander their basic income (maybe on Bitcoin?) and if they do, so much for a social safety net.

Why don't people do it on existing benefits?

You can use a polyfill.

> CSS especially is a nightmare. It's near impossible in complex projects to work out if your change is going to change other things adversely.

This is solved with shadow DOM.

> In Javascript it seems normal to (at least in angular) push to global scope, and so it can be really unclear where values come from, or how they get set.

Well, nobody forces you to do it in JavaScript. I think newer frameworks (and culture around them) discourages this.

> Testing any of this stuff is also pretty nightmarish. Knowing the web I'm almost certainly behind the curve and there is new hotness out to solve this, but I've never much luck with automated browser testing. Things like Protractor tests are incredibly onerous to write, and inevitably end up as flakey slow messes that fail builds due to flake more often than they find issues.

I agree that testing the whole application is tricky, but testing components is easy enough these days.

>It's a stupid idea to run a country with a fixed amount of currency - as the economy expands, more currency is needed - either that - or all prices of everything need to adjust because the 'stupid currency' is fixed.

All prices are already being adjusted all the time - what is the problem?

Also true for Finland.

Even if the planes were inexpensive, maintenance and flight costs are high.

How else would you say it?

Did YouTube switch to Polymer yet? I think only the new design (https://www.youtube.com/new) uses it, and it's not yet switched on by default?