The broken promise of Web Components - <AUTHOR> https://dmitriid.com/blog/2017/03/the-broken-promise-of-web-components/ <comment><USER2> The assertions about the DOM are long on hyperbole but rely on e.g. benchmarks from a decade ago and broad hyperbole like:

"This was cumbersome. This was limiting. You could not prototype easily and quickly. You could not easily escape the limitations of UI libraries. etc. etc. etc."

It would have been far more interesting to look at whether the broadest claims were even true, or why people ran into problems using various libraries. Every time I've done a test, React is significantly slower than using standard JavaScript + DOM but that's the wrong question to ask when you really care about whether it's a) fast enough and b) helping you write code faster, reducing maintenance or sharing costs, etc.

All I got from this is that using React makes life easier than calling the DOM APIs directly every time, which is technically true but doesn't say anything about e.g. how WebComponents compare when using abstraction following the best practices of software developers since something like the 1950s.

The "easy-peasy" example is:

        ['Hello', 'world'].map((text) => {
            return
{text}

        })

The alternative given is:

        ['Hello', 'world'].forEach(text => {
        	const p = document.createElement('p')
        	const span = document.createElement('span')
        	span.textContent(text)
        	p.appendChild(span)

        	MyComponent.appendChild(p)
        })

Since the first example requires 140KB of React code plus a ton of setup code to get to that it's either careless or dishonest to compare the two without acknowledging the possibility of using a helper function or two to simplify the second one, as JavaScript developers have been doing routinely for multiple decades.

Again, not a slam on React, just this kind of unhelpful advocacy. It'd be a lot more interesting to compare real examples with multiple libraries and talk about how the different choices impact debugging, performance, isolation, etc.

<comment><USER3> Yes, it's like with JavaScript itself, it had some issues in the past, all the big issues were resolved but the stigma is still there.

I can't see any fundamental reason why generating the DOM with React would be faster than generating the DOM with Web Components - They're doing the same thing; it's a matter of time before they even out (if they haven't already).

I think that Web Components would end up faster ultimately due to native browser support (more room to optimise).

<comment><USER4> > Yes, it's like with JavaScript itself, it had some issues in the past, all > the big issues were resolved but the stigma is still there.

Honest question, because I use Javascript just infrequently enough to have to look this up every time (and it's possible the reported solutions are old), is there a good concise universal way (or two, at most) to determine the type of the variable I may have? It seems it's always a tossup between typeof, instanceof, == null and == undefined, and to my eyes that's _way too many_.

<comment><USER5> A somewhat more succinct option could be to coerce to Object and then use instanceof: 'Object(x) instanceof String'. Or you could use Object.getPrototypeOf, which coerces to Object automatically these days. But null and undefined are special: calling Object on them returns {}, and calling Object.getPrototypeOf on them throws.

If the type you're testing for is not one of the builtin literal types, you can just use instanceof.

<comment><USER4> "Object(foo) instanceof Class" does seem to be the most definitive, but unfortunately seems to require specific testing against a literal that must exist or it throws, and doesn't work for null/undefined. That at least brings the things I need to know to check the type of something down to three, two of which are singular special cases (if somewhat common ones), so that's _better_ and possibly _adequate_ , if not what I would consider _good_. Then again, I'm not sure I'm capable of thinking it could achieve good while there exists both an undefined and null in the language. It still boggles my mind that it has both.

<comment><USER5> To clarify, by "literal that must exist or it throws" you mean that you don't know whether the class you're testing for exists? Testing against an invalid class would be an error in most languages…

I guess an alternative is foo.constructor and foo.constructor.name, which will give you a string if you want that.

<comment><USER4> Since many different js libraries may be loaded from many different sources, I could envision a situation where some utility functions may want to support different inputs depending on what's passed in, and what's passed in might depend on what's loaded, and what's loaded can change at runtime.

That's why many dynamic languages allow access to the type through a string representation.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> > you can substitute your favorite library: Inferno, Preact, Vue, snabbdom, > virtual-dom (or non-js libraries and frameworks like Elm, Om, etc.). > Similarly, replace Polymer with Vaadin, or X-Tag, or…

It's gotten to the point where if you list JS frameworks, you can slip in 2-3 that don't exist and I don't think anybody would notice.

<comment><USER7> I only recognized... I guess 3 of these. A bunch of them could be total nonsense and I have no idea.

<comment><AUTHOR> Some of them I knew or I thought I knew. They came up when I was "researching" for the article :)

</comment></comment></comment><comment><USER8> This article is trash. In retrospect it was a huge waste to coin the term "web component", by doing so the expectation is that web components eliminate all need for 3rd party JS libraries, which as the article points out, they don't. Instead "web components" is a set of low-level libraries that provide bits and pieces of stuff needed to make components.

The article makes the usual criticism that web components doesn't have a databinding spec. It's true, it's a short coming. But the lack of a databinding spec doesn't make Shadow DOM any less useful. The two are unrelated.

The author really likes JSX, but didn't bother to google "jsx web components"; if he had he might have come across this: [https://skatejs.gitbooks.io/skatejs/content/](https://skatejs.gitbooks.io/skatejs/content/)

There are some real things to criticize about web components. Shadow DOM makes it hard to theme your app. Custom elements has some warts in regards to the way that some events are composed. But the article doesnt make these criticisms.

<comment><USER9> Yep, the criticisms are just bad. "Attributes are strings", seriously? Uh, DOM elements in the browser have these things called JavaScript attributes…

> Shadow DOM makes it hard to theme your app.

Polymer uses CSS custom properties for this and it's not even hard, it's pretty cool, it's like you're making a CSS API for theming <your-element>.

<comment><USER10> > Uh, DOM elements in the browser have these things called JavaScript > attributes…

Could you please link to a reference? I've never heard of JavaScript attributes and I can't find any reference on MDN.

<comment><USER11> I think that person is talking about the HTMLElement interface is essentially a JS object and how you can set properties on it. e.g.

      element.foo = 123;

vs

      element.setAttribute('foo', '123');

<comment><USER9> Exactly. I accidentally wrote "attributes" instead of "properties" :D

</comment></comment></comment></comment></comment><comment><USER12> My team is using web components, polymer 1, 2, React, Vue and Riot in 3 strategic projects.

I have a bigger rant about web components, and polymer and interesting enough, I believe - none except one - of the article owner's comments matter much.

Here's another rant and what currently sucks at web components (for us)

1\. Still no adequate browser support coverage (OP's point) \- Google polymer team keeps the mood up, is excited and does great things but we're still waiting

\-- for Firefox to support it, (which declined to implement html imports). I kind of think Mozilla is sabotaging the efforts for some political reason after reading their comments.

\-- for Safari 10.2 to support it natively

\-- for Edge to care.

Unless all the browsers support the v1 spec, we end up being just another JS framework and the Polyfill webcomponent-lite.js itself becomes a framework in competition with vue, react, riot, and others.

2\. Web components (especially) polymer ones are not a good citizen inside an HTML page next to others.

\-- Due to component scoping (which is ok), style scoping in the main document css (custom style) (which is weird) and DOM and shadow dom, you end up feeling hopeless at some point.

\-- I just want to use the paper-toggle and I end up downloading 100s of files.

3\. The opposite of "it just works" ( as someone wrote somewhere, kind of, like you invented the opposite of it just works.)

\- Polymer, and the paper, iron and other libraries are cool, but they somehow fail silently and often. It's hard to figure out what went wrong.

4\. Polymer team is trying to replicate the cool other JS tech and tools, and it just lags behind. (ES6 in polymer 2.0, the still beta app router, bower, gulp and OMG.js ....)

5\. The iron, and then paper, and other elements are too heavily interdependent and no other leaner library or collection appears in sight.

\- A lot of nested imports

\- and the hopeless the wait for HTTP/2 and the future web of 2020s.

I will write later what can be done.

<comment><AUTHOR> One of the main problems I have is that, well, if buy into Polymer, that's what you buy into: yet another vendor lock in. Otherwise you wouldn't even be able to write a simple Todo List: [https://github.com/PolymerLabs/todo- list/blob/master/app/ind...](https://github.com/PolymerLabs/todo- list/blob/master/app/index.html) (all the {{}}'s etc.)

And then... They are really not different from React/Angular/<add your own> :)

<comment><USER13> It's completely different. With Web Components you can start migrating away by using components just not written in Polymer.

How is that anything like React or Angular that really don't let you interop with other libraries out of the box?

<comment><USER14> Could you clarify what you mean by "don't let you interop"? React gives you a DOM node so you can render anything into it, including an Angular component, a jQuery plugin, or a web component. How is that not interop?

</comment></comment></comment></comment><comment><USER15> Web Components are damned awkward because they extend the damned awkwardness of the DOM rather than address it.

DOMNodes are these hot data structures when they're linked into the DOM tree. Writing (and even sometimes _reading_ ) from DOMNodes can cause whole page reflows or paints to occur, sometimes synchronously. The advice to "touch the DOM as little as possible" stems from the fact that the DOM has so many performance pitfalls.

The DOM is so damned awkward that it's faster to maintain a virtual DOM tree, diff changes to it on the next tick with those of the previous, and then only modify the real DOM tree with those changes like React does. Couple that to the fact that React's DOM update strategy is tuned for speed and they can hide/handle most weird DOM object creation/insertion rules, and overall you wind up with a less awkward system.

If I compose my page entirely out of Web Components, the chief benefit I see is good looking markup representative of what's on the page.

If I were to have designed a component system from DOM, I would have added a lightweight iframe-like tag that could be instantiated from a script/css/markup template package. Performance-wise, I thought that having a nested element's box be laid out and painted independently from the parent page could mitigate some of the global ripple effects of touching the DOM. Of course, this lite iframe's box itself would need to live in the parent page and its dimensions would have to factor into the page flow, and that could have global effects. I suspect there could be clever JavaScript or event system additions that would help limit the reflow and paint damage there.

<comment><USER8> > The DOM is so damned awkward that it's faster to maintain a virtual DOM > tree, diff changes to it on the next tick with those of the previous, and > then only modify the real DOM tree with those changes like React does.

Sorry, but it's not. I don't know what it is that you think React does, but it makes those same awkward DOM API calls. React is an abstraction layer and abstraction has a price. Having React call .appendChild is not faster than you calling .appendChild yourself.

<comment><USER10> The strength of using a virtual DOM as an abstraction isn't that you get around making DOM API calls, but that you can easily batch and sequence them to eke out the best performance. To use your .appendChild example: if you iteratively call .appendChild the browser has to reflow every time that happens, whereas if you know you have a bunch of elements to add you can use another strategy (like document fragments) to do that manipulation all at once.

Yeah, you can do this all on your own, but you get it with React for free. Abstraction does not necessarily have a price.

<comment><USER8> I wasn't judging virtual DOM has wholly good or wholly bad, just pointing out the often incorrect belief that some how React does a magical thing that you are unable to do yourself. Batching, etc. is no different. The advantage in the abstraction is that it makes it a bit easier to maintain, not that its faster.

</comment></comment></comment></comment><comment><USER16> I mean who cares, really. 90% of developers will spend time building reusable components that will be used exactly once, and and some people will open source some stuff that wedges in every suggestion and pull so it is 5 times the complexity any one person ever needs and then we will talk about the failed promise of web components.

<comment><USER10> I don't think the thesis of the article is that it hinders reusability, though — it's that anything built on the DOM presents significant limitations compared to what we can do with JavaScript.

The example of passing dynamic styles to a web component is a good one: since attributes have to be strings, you have to handle serialization somewhere rather than have it Just Work, like it does with most modern JavaScript frameworks.

<comment><AUTHOR> It's also the main problem React faces when trying to incorporate/integrate with Web Components. React Components can be arbitrarily complex and accept arbitrarily complex properties.

Web Components work ok as "leaf" nodes: then it's just a component with string props/attributes.

The inverse is nigh impossible: Web Components can only deal with strings, so you would end up with yet another incompatible wrapper à la Polymer if you want to do anything remotely complex.

<comment><USER13> > React Components can be arbitrarily complex and accept arbitrarily complex > properties.

Web Components can be arbitrarily complex and accept arbitrarily complex properties or children.

Did you even try Web Components before spewing falsehoods?

<comment><USER10> The W3C editor's draft for custom elements clearly states that attributes are sequences of DOMString: [https://w3c.github.io/webcomponents/spec/custom/#concept- cus...](https://w3c.github.io/webcomponents/spec/custom/#concept-custom- element-definition-observed-attributes)

<comment><USER13> So? Properties are objects and children are nodes.

<comment><AUTHOR> So, basically, "we push everything to JS and we have the curse of the empty body tag where everything is rendered with JS" turned into "we push everything to JS and we have the curse of the empty body tag where everything is rendered with JS ... but with WebComponents! So it's cool now!"

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> Couple years ago I gave some thought about how to handle reusable JS in a sane fashion. Actually, a lot of thought. The end result was something that superficially sounds like Web Components, but it quite different underneath. I guess a good name for it would be "Web Behaviors".

It's not a framework or a library, but rather a set of rules and practices of how to do things. It will sounds somewhat weird, but I'll list them anyway. Maybe someone will find it useful:

\- Overall mental model: libraries don't implement components, but rather change the behavior of certain elements on the page.

\- No library keeps state in JavaScript variables. DOM is your model.

\- All configuration is also done through DOM with liberal use of CSS selectors to reference things.

\- No library has any direct dependencies on any other.

\- Things that need to react to changes should (if at all possible) use timers. If that's not possible, they should register global event handlers, rather than attach them to individual components.

While this might horrify some people, it actually forced me to come up with rather nice, abstract behaviors that capture many common features I had to commonly implement. Also, this plays well with the notion of progressive enhancement. I recommend everyone to try it on some new web-based project of low to moderate complexity. Ir really does simplify a lot things.

<comment><USER18> Do you have some code samples you could link? On the face of it, this is the exact opposite of what React, Vue, Angular, Ember, Backbone, etc. do.

<comment><USER17> A demo of sorts:

[http://quickenloans.github.io/Behaviors.js/](http://quickenloans.github.io/Behaviors.js/)

The code will look extremely non-idiomatic to most frontend engineers. Treat it as a thought experiment (which it is). The important thing isn't the particular implementation, but the ideas I outlined above. There are other, often simpler, ways to implement the same concepts.

One property of these libraries that might not be immediately obvious is that they "automatically" adapt to changes on the page. So you can add an element with a behavior via AJAX or dev tools and it will actually work. This is why using timers and global events is a part of that list.

Another thing is that none of these libraries have an API or modify the global JS namespace. This is part of the thought experiment not directly related to the main concepts. It drives some of the complexity.

Edit: Fixed the link.

<comment><USER18> Link does not work, care to double check it?

<comment><USER17> Fixed it.

</comment></comment></comment></comment></comment><comment><USER19> For anyone interested, I wrote up a response: [https://robdodson.me/regarding- the-broken-promise-of-web-com...](https://robdodson.me/regarding-the-broken- promise-of-web-components/)

Kinda used it as an attempt to address some bigger questions around Web Components I've seen come up a bunch. Curious what you all think.

<comment><AUTHOR> I've updated the article to include a link to you response

</comment></comment><comment> c-smile Just in case, architecture of components in Sciter. Could be interesting for some.

Assignment and composition - by CSS, and only by CSS, Sciter's specific _prototype_ property:

       .myComponent {
         prototype: MyComponent url(components/my.tis);
         color: red;
         ...
       }

where MyComponent is the name of script class in components/my.tis script file. That MyComponent looks like as

       class MyComponent : Element
       {
         function attached() {
           // called when DOM element gets this class
           // a.k.a. DOM constructor

           // content initialization, if needed:
           this.$content( <button.prev/>
                          <button.next/> );
         }
         function detached() {
           // called when DOM element looses this class
           // a.k.a. DOM destructor
         }

         function method() {
            // some public method
         }
         property prop(v) {
            // some public property
            get { ... }
            set { ... }
         }

         event mousedown (evt) {
            // default mousedown event handler
         }
         event mouseup (evt) {
            // default mouseup event handler
         }

         event click $(button.next) {
            // click on its button.next
         }
         event click $(button.prev) {
            // click on its button.prev
         }

         // etc
       }

To use such component:

1\. include CSS where the binding is defined (prototype above) 2\. In markup to define matching element:

Nothing too complicated and pretty effective. Could be done even 18 years ago: [http://www.w3.org/TR/1999/WD- becss-19990804#behavior](http://www.w3.org/TR/1999/WD-becss-19990804#behavior)

<comment><AUTHOR> Yeah. Sciter's ideas would be awesome :(

</comment></comment><comment><USER20> This entire article is invalidated by the fact that React's DSL (or the TSX variant, to be precise) can be used to implement Web Components!

Take a look: [https://github.com/wisercoder/uibuilder](https://github.com/wisercoder/uibuilder)

</comment><comment><USER21> I think your native web components example is wrong, or more probably outdated.

Here's an example with the latest wc spec: [https://developer.mozilla.org/en- US/docs/Web/HTML/Element/sl...](https://developer.mozilla.org/en- US/docs/Web/HTML/Element/slot)

But as far as I understand from the spec, sadly, you would still need a separate DSL that would leverage iterations, conditionals and other templating operations on top of web components.

<comment><AUTHOR> Yeah, I got it from Polymer's docs. If I don't forget, I'll update the article

</comment></comment><comment><USER22> The author of this article really gets web components wrong. You don't use JS for everything. Web components have a built in DSL.

The below from the article is ridiculous and HORRIBLY INNACURATE:

      ['Hello', 'world'].forEach(('text') => {
    	const p = document.createElement('p')
    	const span = document.createElement('span')
    	span.textContent(text)
    	p.appendChild(span)

      MyComponent.appendChild(p)
      })`

In RiotJs you would build a web component this way:

      <text-breaker-upper>

         {out_text}

      </text-breaker-upper>

Then you declare it ON THE PAGE.

      <text-breaker-upper
          input_str="Hello World">
      <text-breaker-upper>

Web components much more intuitive, reusable, better separation of concerns, less bloat, and more elegant than React..no bastardization mixing of JSX, CSS, and JS, and how the web (and any sane technology) was meant to be.

The sooner this JS front end framework B.S. wasteland nightmare is behind us, the gournd salted on where it stood, and we laugh at JS like we laugh at COBOL.... the better in my opinion.

<comment><USER23> Looks like Riot.js is just another frontend library that has a templating pseudo-language like so many others. Maybe they use the words "web component" on their site or something? Looks like they parse their templates out of the DOM and then do what any frontend framework does. Strange that you get so emotional about whether your templating language is shoehorned into some DOM nodes that get thrown away and replaced once the framework reads them. This is not the web components that the article is talking about and it is not interoperable.

<comment><USER22> This and Polymer are the precursor to built in browser web components that the author claims React is superior to.

</comment></comment></comment><comment><USER24> When done correctly web components aren't just about extensibility. They are also about encapsulation, debugging, testing, *ing, and then reusability.

<comment><AUTHOR> All of these are much better solved by literally everything else :)

<comment><USER24> Literally everything else is not a useful example.

<comment><AUTHOR> I wonder if there's a JavaScript framework called "literally else"... :)

</comment></comment></comment></comment><comment><USER3> React has a bigger community, more hype, more tooling around it, better native mobile support and better support for automated testing.

But if I had to pick my favourite, I'd have to go with Polymer because:

\- It's simpler (fewer dependencies).

\- Declaring styling and layout is cleaner (it's easier to visualise a component's appearance and to modify it during debugging because layout and styling are kept separate from a component's behavior logic). When it comes to debugging, styling/layout issues almost always happen independently from behaviour issues so it makes sense to keep them separate in the source.

\- It works better with browsers' native development tools.

\- No need for a compile step (and associated complexity that comes with it as your app grows).

It's not fair to pretend that React bypasses the DOM entirely. Ultimately, when the user clicks on a button, they are interacting with a DOM element, so the event still has to pass through the DOM layer. The DOM is still the API whether you like it or not.

</comment><comment><USER10> I think we're approaching a point at which browsers will need to make some sort of break with the current DOM in order to provide the types of rich experiences engineers and users want. There's simply too much baggage with the current implementation, and this article highlights a lot of it: attribute values limited to strings, a global namespace for CSS, etc.

This is happening at other levels of the web with the HTTP/1 —> HTTPS/2 transition. We're patching over shortcomings in the DOM right now with JavaScript, but it's easy to see the appeal of a native solution to some of these issues that doesn't require a facade over the actual thing that people interact with.

<comment><USER25> It saddens me that the software industry has been flailing around for at least 15 years trying to resolve the tension between having zero-install + standardized framework and having a rich UI toolkit that can do "real" apps without making developers crazy. The answer seems to be this weird cycle of layering reinvention atop reinvention because nobody can just blow up the whole stack and rethink it with any market success.

Using the DOM + scripting pattern with a DOM more suited to "rich app" development has been tried multiple times as plugins (FLEX and Silverlight come to mind). But the gravitational pull of zero-install + standards crushed them. We also have in progress what is essentially a reinvention of the JVM idea (WebAssembly) but without the UI layer to go with it. That may be successful in its narrow niche, or it may try to overreach into the UI layer and fail like all the others…too soon to tell.

<comment><USER26> What would be the language to use? JavaScript won early, so it's been the de- facto choice every since to the point where browsers probably don't even run other scripting languages with the script tag. The first major hurdle in changing all of this would be getting everyone to agree on what to use. Different languages are suited for different jobs. HTML is perfectly fine for static UI, which is what most sites need it to do. What would a better language or set of tools for the web even look like?

</comment></comment></comment><comment><USER27> This whole tangled mess of JavaScript, HTML, CSS and custom expression languages screams Lisp.

<comment><USER28> Yup, I'm reading this and thinking "oh my, Clojurescript is SOOOOO much nicer" than jsx and dom js api and whatever becomes "trendy" tomorrow.

</comment></comment><comment><USER29> Web Components have turned into a dead end for me. Instead, I like what Facebook has done in that they have proven the declarative approach can translate to native and even VR in a very intuitive and approachable way. As far as I'm concerned this is the future for awhile as I've been having a breezy easy time doing native with React and have never experienced a simpler way to develop anything. I have also programmed in Vue but for some reason still prefer React. Possibly because it seems there is more community support, usage and toolage and of course it supports more types of devices, aside from being baised.

</comment><comment><USER30> Important context (Twitter thread) for this article, by the same author a few days before publishing it: [https://twitter.com/dmitriid/status/841172534586429441](https://twitter.com/dmitriid/status/841172534586429441)

</comment><comment><USER31> I don't think Web Components are a "framework replacement", they are an addition.

Stuff like Bootstrap needs them to enrich their "top down" approach with CSS and HTML so you don't have to mess around with either their source OR CSS classes and "their" HTML structure everywhere to get the components right. You add their CSS & (Web Component) JS at the top and use their custom components as the "leafs" of your sites. I wrote about it here: [https://dev.to/kayis/web-components-for-your-custom- elements](https://dev.to/kayis/web-components-for-your-custom-elements)

The other frameworks like React, Angular, Cycle or Ember will then become the Data-flow layer of the app.

<comment><USER32> >The other frameworks like React, Angular, Cycle or Ember will then become the Data-flow layer of the app.

None of these frameworks like dom being changed from underneath them, you will run into all sort of weirdness.

<comment><USER31> I think this depends on the complexity of the components you implement as web- components.

I mean, in React, the whole app is basically a component. It wouldn't make any sense to replicate this with Web Components.

But yes, I read a few times that the React devs don't consider React a "data flow framework", so they decide when to re-render and stuff. Cycle is more in line with this thinking.

</comment></comment></comment><comment><USER33> > In 2017 React fulfills all the promises of Web Components

Not really - React needs a large run time, and it's really not a good fit for an existing app where you need a true component you can pop in and use within a Java or Rails app.

<comment><AUTHOR> You can use slimmer runtimes: Inferno, React, snabbdom, virtual-dom...

Web Components also need a runtime as soon as you need anything sufficiently complex. Such a simple example as a ToDo List cannot run without Polymer's weird data-binding implementation: [https://github.com/PolymerLabs/todo- list](https://github.com/PolymerLabs/todo-list)

</comment></comment><comment><USER13> This article is just awful.

There seem to be two main criticisms here:

1\. Web Components don't provide a DSL for creating DOM trees. This is true, because Web Components don't provide a DSL for creating DOM trees! That's and entirely separate concern that can be addressed by a library[1] or by a future, more-ergonomic tree construction API in the DOM.

2\. The author doesn't like Polymer's templates. Which is, nearly as unrelated to Web Components as the first complaint, because it's also the same as the first complaint. Polymer's template system allows you to create DOM trees, and automatically wire together properties and events. That's it. You can do this without using custom elements at all.

You can also use any number of ways to construct trees: JSX, DSLs, HTML templates and cloning, string templates, etc. It's no different from any other framework including React.

And then he repeats Sebastian Markbåge's, creator of React, tired complaint that Web Components can only consume string data. This is FUD, pure and simple. Web Components are Elements, and Elements are Objects with properties. Every Web Components framework relies on this for data-binding or setting "props".

And... that's it. That's basically the extent of the critique.

The author could have actually tried to compare React and Web Components and he would have seen that:

1\. The component models are very similar, there are analogs for most lifecycle events.

2\. Web Components don't prescribe state management or dataflow, and there are indeed functional, unidirectional, immutable (by convention), Web Components libraries and patterns out there.

3\. Shadow DOM fixes nearly everything that css-modules address in a native and performant way.

Web Components aren't a be-all-end-all standard. They are a few fixes to the platform that should have been there from the beginning, namely that you should be able to extend the HTML vocabulary (Custom Elements), you should be able to encapsulate some DOM and styling (Shadow DOM, which most browsers already had for their own UIs), and that you should be able to ship and parse _potential_ DOM (<template>). That's it. Everything else is either a library responsibility and/or TDB. Web Components are a foundation to make it easier to create frameworks, libraries, and an base-level interop story that answers some, but not all, critical, simple questions:

How do I write a widget? : Extend HTMLElement How do I keep other scripts and styles from interfering with my widget's internals? : Put the internals in a ShadowRoot. How do I scope my own styles? : Put them in a ShadowRoot How do I instantiate my widget: Use a tag in markup, call createElement(), or call it's constructor.

Anyone coming to the web platform as a new developer now doesn't have to sift though 100 frameworks and contradictory tutorials for such simple questions, the platform provides answers, as it should have from the beginning.

[1]: See Hyperscript as a React-like example [https://github.com/hyperhype/hyperscript](https://github.com/hyperhype/hyperscript)

<comment><USER23> What does Hyperscript have to do with web components?

<comment><USER13> Exactly.

The complaint in the article is that Web Components don't _also_ add a nice API fro creating DOM trees.

This is true, but not relevant. The ideas of a component model and tree creation DSL are orthogonal.

Hyperscript (the JS library) is a nice API for creating DOM trees, that's similar to React's createElement(). You can use it with or without Web Components.

</comment></comment></comment><comment><USER34> [Typo flagged and fixed]

<comment><AUTHOR> Done! Thank you!

</comment></comment><comment><USER35> It starts to sound like browsers should support JSX natively...

<comment><USER36> Template strings look like a better way to do JSX, imo: why can't html`<p>Hello world</p>` be made to return the DOM element for the p tag?

<comment><AUTHOR> JSX appeared before template strings where even an idea (I think :) ).

The thing though, JSX doesn't return DOM elements. It's a very thin DSL on top of React.createElement calls. Since it's Javascript all the way down, you get a number of benefits:

\- you are not constrained by limitations such as "attributes can only be strings" or "children can only be DOM Elements". It's all Javascript expressions

\- React knows the return value. It can do efficient diff'ing against its internal DOM representations and only update the actual DOM as needed (same goes for other virtual dom implementations such as snabbdom, virtual-dom etc.)</comment></comment></comment>


Richard Stallman explains iBads and Cell Phones - <AUTHOR> http://www.youtube.com/watch?v=WGkNiRFwmOg

<comment><USER2> So now he calls Linux the GNU Operating system? Not even GNU/Linux anymore?

Sorry Stallman, even though you have done fantastic things for software and intellectual freedom, you are totally wrong on this one.</comment>


DNA computer 'answers questions'  - <AUTHOR> http://news.bbc.co.uk/2/hi/technology/8184033.stm

<comment><USER2> Fails to mention (to me) the most interesting aspect of this kind of work: the complexity and scale of these machines is such that although we may not develop more efficient algorithms for intractable problems in the traditional sense, they may become tractable when computed with DNA.

</comment><comment><USER3> Is this DNA Prolog?</comment>


Salary Social Club Survey - <AUTHOR> https://calebthompson.io/salary-survey <comment><AUTHOR> How does your salary compare to others? Is that job offer fair? Does a candidate have reasonable pay expectations? Take this survey and let's find out together!

After you've taken the survey, I'd really appreciate if you could share with your networks so that we get even more diversity in our responses.</comment>


Ask HN: How important database performance is to you? - <AUTHOR> Are you happy with your database performance? How much would you care if database did everything it does now 10-100x times faster? <comment><USER2> I'd be thrilled if I could flip a switch and make our DB 10x faster. It's currently our performance bottleneck.

However, migrating an existing production DB (especially to an unproven technology) is no small matter.

And even just adjusting configuration for performance purposes can be risky. I'd prefer to do it under the auspices of a consultant DB admin with at least 10 years of experience administering and tuning this particular DBMS.

So in short, DB performance is enormously important, but it comes in third to reliability and stability.

Once your solution has been in broad production use for at least 5 years, I would absolutely consider it for a new project, though!</comment>


Perch: CCTV your home with old smartphones - <AUTHOR> https://getperch.com/ <comment><USER2> wow, did you read the privacy statement....

For content that is covered by intellectual property rights, like videos ("IP Content"), you specifically give us the following permission, subject to the limitations set forth in our Privacy Policy: you grant us a non-exclusive, perpetual, irrevocable, transferable, sub-licensable, royalty- free, worldwide license to use any IP Content that you post on or in connection with Perch.

So anything you record using their service will be theirs!

<comment><USER3> This is standard boilerplate for all content-hosting services. It gives them permission to handle the video in the product. And also to use it however else they want.

YouTube, for example: [https://www.youtube.com/static?template=terms](https://www.youtube.com/static?template=terms) """ By submitting Content to YouTube, you hereby grant YouTube a worldwide, non-exclusive, royalty-free, sublicenseable and transferable license to use, reproduce, distribute, prepare derivative works of, display, and perform the Content in connection with the Service and YouTube's (and its successors' and affiliates') business, including without limitation for promoting and redistributing part or all of the Service (and derivative works thereof) in any media formats and through any media channels. """

<comment><USER4> YouTube is a different situation because content you put there is usually intended to be broadcast anyway; security camera recordings are not.

</comment></comment></comment><comment><USER5> Oh, another cloud IoT thingie.

Seriously, this is ridiculous. Privacy aside, once again, this data should not be streamed all around the world just like that, not to mention being saved on third party servers.

We need to have a serious conversation about IoT and the cloud. We need a brain-dead simple protocol for setting up direct connections between devices in the same network and turning some of them into servers. Something that will not require technical expertise to set up if properly coded on devices. And after that, we should start expecting startups to use it. _Dependence_ on third-party cloud services should _not_ be an acceptable business model.

</comment><comment><USER6> What I find a bit of a shame is how dependent on the cloud it is. I live in a country where the internet isn't reliable, fast or secure so any cloud services are a barely worth the hassle or simply no-go if the government blocks them. I know that small US startups won't spend resources making their service work in "backward" markets like mine. I'm hoping to find a local set of applications that can just store video on a computer hidden in a closet with internet notifications being optional rather than essential.

The basic idea sounds great - nearly everyone has an old smartphone, maybe with a bad battery that can still work fine powered by USB.

<comment><USER7> [https://www.ispyconnect.com/](https://www.ispyconnect.com/)

I've used this with cheap ($100-150) IP cameras and I believe there are mobile applications that can make a smartphone act as an IP camera as well, although I'd imagine they may not always be ideal since they're not meant to be running/recording like that all the time.

Still, I've done exactly what you describe before getting a NAS with surveillance/IPCam monitoring software. Run iSpy on an old computer in a closet, set it up so the recordings go in your Drive/Dropbox/etc. folder and set the max archive size depending on your available storage or how much you want to eat up. That way your stuff if stored locally and you can still access recent recordings elsewhere via your online storage. You can skip the online storage part if you want, or I believe there is a "pro" service with iSpy that gives online options but I never used them.

On its own, it's a great bit of software and once you tweak the settings a bit (recording quality/format, motion detection sensitivity, etc) it's pretty flexible and you should be able to get it working reasonably well on even older hardware. I've run it on old Core2Duo laptops as well as my more modern desktop. Encoding lots of streams can get demanding on the old gear but for a cam or two it's not too bad.

</comment></comment><comment><USER4> So the traffic goes from the smartphone to Perch's servers, then from their servers to your client? Even setting the privacy implications aside, that seems a terribly roundabout way of doing it, as I'm pretty sure any Android- capable device is more than powerful enough to act as a standalone network camera itself.

</comment><comment><USER8> Oh, what a fantastic idea. Just take an old smartphone that the manufacturer stopped shipping security updates for ages ago (if they ever did it at all), and get it to record what goes on inside your home. What could possibly go wrong?

You might want to look at [http://androidvulnerabilities.org/](http://androidvulnerabilities.org/) to see the sorry state of security on Android phones. The older they get, of course, the worse it is.

<comment><USER4> All I see are tons of local privilege escalation, which is concerning if you like to download and run random not-very-trustworthy apps, but it's actually not of much significance if all you're using the phone for is as a network camera. IMHO these are the _good_ exploits, since they let you get root and have full control over the device so you can repurpose it more easily for other things... like network cameras.

Remote exploits that require no user action are the only thing to worry about here, and Stagefright is AFAIK the only one I've heard about so far (simple solution: take the SIM card out - what do you need it for in this application anyway?)

</comment></comment><comment><USER9> I use IP Webcam[0] which can do motion detection and capture. I've recently been experimenting with combining it with FolderSync[1] to sync to my OwnCloud instance. For real time monitoring I can of course connect directly to IP Webcam's web interface and watch the feed, toggle the flash, etc. It'd be nice if someone made a unified solution to do this that doesn't include uploading all of your data to someone else.

[0] [https://play.google.com/store/apps/details?id=com.pas.webcam...](https://play.google.com/store/apps/details?id=com.pas.webcam&hl=en)

[1] [https://play.google.com/store/apps/details?id=dk.tacit.andro...](https://play.google.com/store/apps/details?id=dk.tacit.android.foldersync.lite)

</comment><comment><USER10> Perch is a division of Samsung Research America, Inc. ("SRA"). The Personal Information collected by Perch may be shared within SRA or with entities that are controlled by, under common control with, or control SRA. This Privacy Policy is further subject to the terms and conditions of the then-current Samsung Privacy Policy, which you can access . In the event of any express conflict between the terms and conditions of this Privacy Policy and the terms and conditions of the then-current Samsung Privacy Policy, the terms and conditions of the then-current Samsung Privacy Policy shall govern solely with respect to that conflict.

I just really don't trust Samsung - especially when their privacy policy overrides whatever privacy policy Perch has.

</comment><comment><USER11> When I saw the headline, I assumed it was the latest incarnation of Vancouver startup Perch -- [https://perch.co/](https://perch.co/). Same name, same idea.

The "Perch is a division of Samsung Research America" line in their privacy policy makes me think they were acquired by Samsung and their product ported from iOS to Android.

Anyone have any more information? I can't find any announcements of an acquisition or acqui-hire at all.

Perch had been pretty quiet for the last few months, so a fire sale to Samsung wouldn't surprise me.

</comment><comment><USER12> > Closed-circuit television (CCTV), is the use of video cameras to transmit a > signal to a specific place, on a limited set of monitors.

_sigh_

</comment><comment><USER13> You can do this with a few lines of code in Firefox OS. For example, I did a SMS gateway server lately: [https://github.com/SunboX/fxos-HTTP-SMS- Gateway](https://github.com/SunboX/fxos-HTTP-SMS-Gateway) A WiFi enabled camera wouldn't be much different.

</comment><comment><USER14> Who has multiple spare smart phones just lying around? And with working Internet access? Surely it's cheaper (and more private and secure) to just use cheap IP cameras?

<comment><USER6> Anyone who's upgraded their phone or replaced it because the battery stopped holding charge. Internet access would be free via wifi which most people have in their homes.

So I'd doubt that an IP camera is cheaper. If anything, a phone sounds like an ideal low cost IP camera just due to the enormously bigger size of the market and the piles of unused ones lying around.

</comment></comment><comment><USER3> When scrolling down the page _didn 't scroll down the page_, I gave up and closed the window.

</comment><comment><USER15> >See What's Happening At Home

Nothing. There. Didn't need your service.</comment>


America May Have Too Many College Graduates - <AUTHOR> http://www.theatlantic.com/business/archive/2012/08/america-may-have-too-many-college-graduates/261454/

<comment><USER2> It would certainly be naive in the extreme to suppose that the whole national economy would improve if every person of working age spent the time, effort, and money to add one degree to his or her resume. At the individual level of analysis, in some occupations, a typical degree for that occupation seems to be all upside for the degree-holder. A commonly made statement in books about industrial psychology is that an engineer has higher earnings over the course of a lifetime, adjusted for the cost of obtaining a degree, at ALL levels of IQ. In other words, if you like technical occupations, do whatever it takes to be classified as an engineer rather than as a technician, and in many workplaces that means get a college degree.

But at the societal level of analysis, it is much less clear that increasing the societal percentage of college graduates is really beneficial. The example of different national development strategies during the 1960s and 1970s helps clarify what might be involved. Some newly independent former colonies, especially in Africa, pursued strategies of promoting higher education with publicly subsidized college for elite students, so that the most capable learners would no longer have to study abroad to gain degrees. Other countries with a similar degree of wealth (the year my wife was born, Taiwan was poorer than Zambia) pursued a strategy of broad access to well delivered primary, and then secondary, education, with higher education paid for in larger part by family resources of families willing to pursue higher education. The broad- based national education policy of making the masses better educated promoted much more economic growth (and political democratization and liberalization) than the focus-on-elites policy of directly increasing the number of college graduates.

There is formal research on how much students learn during college attendance,

[http://www.todroberts.com/USF/PerfectStorm_UndergradEducatio...](http://www.todroberts.com/USF/PerfectStorm_UndergradEducation.pdf)

[http://www.insidehighered.com/news/2011/01/18/study_finds_la...](http://www.insidehighered.com/news/2011/01/18/study_finds_large_numbers_of_college_students_don_t_learn_much)

and the unsurprising finding of that research is that some students learn quite a bit during their college years, but some hardly learn anything at all. College-as-such, without regard to what major the student pursues, and what the academic atmosphere of the college is, doesn't necessarily lead to intellectual growth for the enrolled students.

P.S. Noting an early downvote to this comment, I'm wondering what people who disagree with these observations of the real world have to say to provide evidence for their disagreement. I learned during my high school education, and continued to learn during my college education, to ask for citations of facts as I form my opinions about public policy.</comment>


Househacker Guide: Hacks & Little-Known Facts on Buying and Owning a House - <AUTHOR> https://leanpub.com/homeownerhacks

<comment><USER2> Is this targeted to the US, UK or general housing market?

</comment><comment><USER3> Anyone actually buy this?

</comment><comment><USER4> Spam!</comment>


The fastest way to learn a new language - <AUTHOR> https://www.adamtank.com/new-blog/2020/3/2/the-fastest-way-to-learn-a-new-language-act-like-a-child <comment><AUTHOR> The commonly held view that children learn new languages faster than adults due to neuroplasticity is B.S.

Interesting take - argument is not about technology, neurons or (necessarily) learning method, but about dealing with embarrassment.

</comment><comment><USER2> I had an Uncle take an assignment in Brazil. The entire family took Portuegese lessons except for the youngest boy who wasn't of school age.

He ended up being the only one to become fluent. He hung out with the maids watching soap operas and that's how he learned the language almost by osmosis. He had no accent and knew all the slang.</comment>


Diocletian - <AUTHOR> https://en.wikipedia.org/wiki/Diocletian <comment><USER2> "Many Christians and other believers despair even of the possibility of protecting their children from being indoctrinated into the beliefs of the governing elite, the new ruling class (or what perhaps might better be described as the old, but re-paganized, ruling class). They believe we have entered a new Diocletianic age."

Robert George in May/June [https://www.touchstonemag.com/archives/article.php?id=33-03-...](https://www.touchstonemag.com/archives/article.php?id=33-03-024-f)</comment>


Show HN: Mimicking the Bloomberg menu widget without JavaScript - <AUTHOR> https://dosyago-coder-0.github.io/mimic-bloomberg-menu-no-js <comment><AUTHOR> Context: I like the Bloomberg site and their drop-down menu is cool. Purely as a challenge, I set out to mimick the styles and behaviour of that menu without using JavaScript and trying to keep the HTML/CSS as minimal as possible. Their menu widget does not work if you switch of JS (but this was not a motivation for me to make this).

Tested on IE 11, Edge 12, latest Chrome stable and Firefox dev on Windows 10.

Source: [https://github.com/dosyago-coder-0/mimic-bloomberg-menu- no-j...](https://github.com/dosyago-coder-0/mimic-bloomberg-menu-no-js)

Maybe this post should be a Medium post titled "How I mimicked the Bloomberg menu widget without JavaScript." I might write one if many people want that.

<comment><USER2> Firstly, job well done. Secondly, what is the motivation of going pure CSS aside from the challenge of it?

I once prefered Pure CSS stuff until I learned Javascript myself. Now I've come to loathe that approach on complex menus and widgets.

Mainly I dislike using them because I have to refactor them to use Javascript so they can be stateful (reacting to an active category or something indicated by the url or querystrings, etc.

Again, good job though if it's just for the lulz.

<comment><USER3> It seems to me, many web developers today don't even realize, that creating features without js and enriching the experience from that baseline, not only enhances performance and accessibility, but in the end is often not more work and might even lead to cleaner, leaner code. I guess in the end it just comes down to which tools one learned first and based on that which approach one takes to solve the problem at hand.

I can only encourage everyone that thinks js is the catch-all solution to dive a bit deeper into html&css and try out alternate solutions. It's worth it for the knowledge gain in itself but offers many other benefits.

<comment><USER4> css is often the slowest part of a webapp. complex css like this is not necessarily better accessibility-wise than javascipt

<comment><USER5> Do you have some proof to back this? CSS matching is incredibly fast.

</comment></comment></comment></comment></comment><comment><USER6> Pretty cool indeed!

Found a bug with Chrome 67.0.3396.87 on Mac OS 10.11.6: When you hover over a menu item (e.g. "Markets"), the sub-menu updates based on the sub-items for the "Markets" item. However, when moving the cursor right (towards the sub- menu), the sub-menu state reverts back to the last activated menu item. Only clicking a menu item makes the respective sub-menu "stick". This is not the case for the actual bloomberg menu.

Don't know whether this is a limitation of the html+css approach?

<comment><USER7> I think this is just how it's implemented. It works this way in Firefox on Windows as well.

</comment></comment><comment><USER8> Well done! Moving the mouse to a child resets the position though. You may need some JS to do some fancy stuff like here: [http://bjk5.com/post/44698559168/breaking-down-amazons- mega-...](http://bjk5.com/post/44698559168/breaking-down-amazons-mega- dropdown)

Or to keep it JS free there might be a way to structure the HTML similar to: <Nav1><ChildNav1.../></Nav1>. Hover a :hover pseudo on <Nav1> will also fire when hovering over <ChildNav1 />.

<comment><USER9> Even the triangular cursor path thing could probably be done with just CSS, a short-lived extra element in the childnav that starts transforming away on hover, making the next nav item accessible if the intent turns out not to be to move to the submenu.

<comment><USER10> The tricky thing is getting the triangle's node to be the position of the cursor; you need it to start at the left of the menu item, then animate rightwards only while the cursor is hovering over it, stopping when it's not—so that it will naturally come to rest. This is possible to express with animations (animation-play-state is key), except for the fact that :hover calculations are not done constantly in most browsers, but only when the user does something to trigger it, such as moving the cursor. And so basically the whole scheme falls apart: it will work just barely OK, but if you move your mouse just a _bit_ too slowly, it'll effectively stop working.

It's still an interesting thought. If you're interested and my explanation isn't clear enough, I'll put a simple proof-of-concept-and-why-it's-sadly-not- really-enough together.

(OK, since then I've come up with an _insane_ approach that relies upon this behaviour, and it _might_ just work, though I'm concerned about how reliable it'll be across browsers. If it does work, it will definitely be blog-post worthy.)

</comment></comment></comment><comment><USER11> It's 2018 and we still have to jump through hoops to get browsers to do things perfected on desktops by the mid 1990's. (Without bugs and browser incompatibilities.)

The Web royally screwed UI development and standards to Hell's basement, and nobody seems to want to fix it because the current mess is job security for low-level DOM diddlers.

<comment><USER12> I doubt many 90s desktop apps were designed around the expectation that the Turing Complete programming logic behind them could be explicitly disabled by the user.

And exactly what 90s desktop app had a menu that looked quite like that? Platform's then supported cascading popup menus with titles and icons rendered in native GUI chrome, ala the Windows 95 Start Menu. Any more flexibility required a lot of "low-level (whatever) diddling".

"Browser" incompatibilities are not much of a thing when you are developing for a platform provided by just a single vendor. But go ahead and try to port a Win95 app to OS7, you'll soon be longing to deal with the minor incompatibilities between different browsers (and yes, it's 2018, you don't need jQuery shims to reliably add two numbers together anymore).

CSS has long supported cascading popup menus without the need for any Javascript and browsers have long supported that CSS in a standards compliant way. Yes, if you really want some Win95 style menus you'll have an easier time in Visual Basic, but for most everything else it will be nearly impossible.

The webstack is not ideal by any means, but to suggest that it is somehow worse than win32 programming or easier to create responsive good looking apps in classic VB requires some mighty fine rose-colored-glasses.

<comment><USER11> I'm not proposing we go back to desktop apps as done in Windows et al. I'm proposing an open-source network-friendly GUI standard be created, or at least experimented with to test the power and limits of.

I suggest it be coordinate-vector based, and any layout and "flow" decisions be done on the server. Yes, if you resize your screen it would be slower than client-side re-flowing, but would simplify the client-side greatly, making it mostly a dumb vector plotter. Fat clients led to fat problems. Shift more to the server so you are using and testing with one render engine instead of the 50+ that browser brand/version combos result in. 1 < 50.

</comment></comment></comment><comment><USER13> That's pretty cool I was just about to make a write up of how to make a css dropdown mega menu, which is sort of semi-related in principle. I didn't find any good examples on codepen so I ended up writing my own.

I made a crude mockup here in PUG / SASS to cover just the essential "hello world" concept.

[https://codepen.io/Kagerjay/pen/ZRogMy](https://codepen.io/Kagerjay/pen/ZRogMy)

A revised version

[https://codepen.io/Kagerjay/pen/Paaoee?editors=1100](https://codepen.io/Kagerjay/pen/Paaoee?editors=1100)

and then an actual template for an ecommerce site I'm building

[https://codepen.io/Kagerjay/pen/8d591195c12c9421b4db58734396...](https://codepen.io/Kagerjay/pen/8d591195c12c9421b4db58734396e51b)

I try to avoid JS if CSS can do the same job, because then I have the oppurtunity to change it much easier later.

the above examples uses no css frameworks or javascript libraries

</comment><comment><USER14> Remember with hidden checkbox elements CSS can be used for multiple states!

</comment><comment><USER15> Awful usability. I expect that when hovering over a section and moving my cursor to the right I would stay within that section, but it always just reverts to home or whatever other section I've clicked.

If hovering over a section doesn't enable access to that section, then don't show the expanded version. Wait for a click event to show it at all.

<comment><USER16> There's a good article about Amazon implementing this feature for their mega menu. Blew me away when I first read it, it's very obvious and simple in hindsight.

[http://bjk5.com/post/44698559168/breaking-down-amazons- mega-...](http://bjk5.com/post/44698559168/breaking-down-amazons-mega- dropdown)

<comment><USER15> Yes, there are some great tips. I still think this style menu is just bad, though. Although certain tweaks can improve the UX, it's still an frustratingly unusable interface for people with certain motor disabilities and even just older users whose mouse/trackpad skills are not great.

<comment><USER17> At this point, the department menu is an alternative to search. It doesn't need to be universally accessible or forgiving to poor motor control, because in terms of footprint it is tiny. I have used it before and it was just fine for me, and if some proportion of their customers have a similar experience, then it seems well worthwhile.

<comment><USER18> I completely disagree with this sentiment. Everything in a UI that you _can do with a mouse_ should be tolerant of disabilities that people who use a mouse might be going throug (tremors etc). A user shouldn't have to try to do something and become frustrated in order to discover that it is "not for people with poor motor skills". We should do better. What you describe as "well worthwhile" still strikes me as woefully incomplete and annoying. Every user could potentially have poor motor skills at some point due to temporary causes.

It's not the end of the world of course. I just wouldn't think of "I have used it before and it was just fine for me" as a good reason to not strive for a more universal approach to interface design.

<comment><USER17> > _Everything in a UI that you can do with a mouse should be tolerant of > disabilities that people who use a mouse might be going throug (tremors > etc)._

Why? Should we give up on first person shooter games? Set minimum mouse target sizes for RTS games? The point of the department menu is to convert dexterity into information rapidly. If you lack dexterity, that's no strike on your character, but it somewhat defeats the purpose of a dexterity-limited input. There is an alternative to the department menu in the left side of the search bar, which has a simple list.

<comment><USER15> We're talking about websites. You're talking about games.

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> I really, really do not get this obsession with Javascriptless interactivity.

I mean, seriously. Its 2018. JS engines are REALLY fast. And by the way, lets not be deluded into thinking that the Chrome is a lightweight nothing without JS execution. There are already GPU-aided reflow/repaint operations, your whole UI context lives on a different thread, tons of services are pulled back for audio/video capabilities, not to mention addons, HTML engine, etc.

So just learn proper JS, do not overdo it, and write efficient scripts. Its doable.

<comment><USER20> Just because a JS engine is really fast doesn't mean you should do everything in JS, esp if CSS is the right tool for the job (not to say that this particular demo is a good example of using the right tool for the job).

<comment><USER19> Sure, right tool for the right job, etc. Animations are _almost always_ better when they can be hinted to the GPU (will-change), can be transitioned with translate2d changes, and do not cause reflow by being used on absolute/fixed positioned elements. For example.

My point is that not using JS will not make browsing experience into something "pure". It will remain an incredibly compplex stuff in itself, which JS is only a part of. And when it comes to firing off XHR's, setting some data or providing interactivity (with real states, etc), then JS is a good tool for the job.

</comment></comment></comment><comment><USER21> I, on the other hand, would like to point out the lack of accessibility of this approach, it's unusable with a keyboard. Let's not forget about assistive technologies.

<comment><USER11> On many sites, such menus are meant as shortcuts to content that is otherwise reach-able by other means, such as typical web-site category links. However, automated accessibility grading systems won't necessarily "understand" this fact and score it poorly.

</comment></comment><comment><USER22> Makes back button unusable.

EDIT: ok, I see what they are trying to do, using # URLs whereas the "real" url would be an actual link that directs you to another page so the back button would work fine. But why make them weird fake links? Why not just make them actual links? It would make sense and wouldn't make the menu jump around randomly.

<comment><USER23> I experienced a broken back button after clicking a few different menu items.

</comment></comment><comment><USER24> I looked at the source, looks neat except one thing: shouldn't there be double quotes around all href targets?

The ones that have a single quote (e.g. What's Inside All the iPhones) get marked in red in firefox's view source due to this

<comment><USER25> Quotes aren't actually necessary unless the attribute contains HTML special characters (" ' ` = < >)

</comment></comment><comment><USER26> I don't mean to be overcritical of someone learning to code—this is much more a criticism of people upvoting links without clicking them—why is this on the HN frontpage? It doesn't work. At all.

Try clicking on the "Markets > Read: Economics" link.

<comment><USER27> Works for me.

[https://vgy.me/DOVAXW.gif](https://vgy.me/DOVAXW.gif)

<comment><USER26> Yeah, there's been a lot of new commits since I commented.

Looks like one of the commenters here—franciscop—fixed that particular issue just after my comment.

</comment></comment></comment><comment><USER28> I am sorry if this is kind of out of topic. I remember weeks ago I've visited their website with new design. Seems like now bloomberg went back to the old design of their website. Any clue?

<comment><USER29> They may have been testing a design with a small portion of their traffic. Perhaps you were bucketed into the variant group.

</comment></comment><comment><USER30> I like the menu on Stripe.com.

Make a pure CSS version of that and you're king :)

<comment><USER31> Should be possible, but I don't get what's to like so much in unnecessary animations sucking your battery and making the whole experience awful on underpowered hardware.

I have Intel GPU with hidpi screen - Stripe's menu drops frames and spins up the fans.

<comment><USER32> Sadly `auto` values can't be animated. It can only be done with a bunch of hard-coded sizes and positions. Remove an item anywhere and you'll have to manually adjust.

<comment><USER33> > Sadly `auto` values can't be animated.

Sure, height:auto can't be animated - but max-height:800px, for example, can be used to similar effect.

<comment><USER32> No easing though. You can't avoid the "snapping" at the end

</comment></comment></comment></comment></comment><comment><USER34> I love what you've done here!

One recommendation (if it hasn't already been mentioned)... easy dismissal of the drop-down. Once I have opened the menu, if I choose not to click on any of the navigation, I cannot simply click outside the  element to dismiss it and return to my content. I'm forced to either engage with the Menu button again, or make a navigation selection.

Tested on Chrome Version 67.0.3396.87 and Firefox 60.0.2

</comment><comment><USER35> Bloomberg and Amazon do there right thing when moving from menu to submenu. I have to thread carefully here so that I don't jump to another one, which is bad. I believe Amazon computes it based on velocity and direction of the cursor.

</comment><comment><USER36> I think the bloomberg marquee is one of the most CPU heavy things ever on a big news site. I let them know years ago, they acknowledged it and never fixed it.

</comment><comment><USER37> Yours is actually much smoother for me, but that might be due to some intended animation delays or something.

<comment><USER38> There's actually a very good reason to implement a delay in switching submenus.

Recent versions of Apple's human interface guidelines don't make any mention of it, because those decisions are baked into the toolkit and not under control of application designers, but the earlier editions of Apple's guidelines went into some detail about why and how pop-up submenus were delayed.

1995 edition of Macintosh Human Interface Guidelines:

[http://interface.free.fr/Archives/Apple_HIGuidelines.pdf](http://interface.free.fr/Archives/Apple_HIGuidelines.pdf)

>pp. 79: Hierarchical menus are menus that include a menu item from which a submenu descends. You can offer additional menu item choices without taking up more space in the menu bar by including a submenu in a main menu. When the user drags the pointer through a menu and rests it on a hierarchical menu item, a submenu appears after a brief delay. To indicate that a submenu exists, use a triangle facing right, as shown in Figure 4-36.

The original 1987 version of the Apple Human Interface Guidelines can be checked out from the Internet Archive, and should be required reading for serious user interface designers, the same way that serious art students should contemplate the Mona Lisa, and serious music students should listen to Mozart. Even though it's quite dated, it's a piece of classic historic literature that explicitly explains the important details of the design and the rationale behind the it, in a way that modern UI guidelines just gloss over because so much is taken for granted and not under the control of the intended audience (macOS app designers using off-the-shelf menus -vs- people rolling their own menus in HTML, who do need to know about those issues):

Apple Human Interface Guidelines (1987): [https://archive.org/details/applehumaninterf00appl](https://archive.org/details/applehumaninterf00appl)

>pp. 87: The delay values enable submenus to function smoothly, without jarring distractions to the user. The _submenu delay_ is the length of time before a submenu appears as the user drags the pointer through a hierarical menu item. It prevents flashing caused by rapid appearance-disappearance of submenus. The _drag delay_ allows the user to drag diagonally from the submenu title into the submenu, briefly crossing parent of the main menu, without the submenu disappearing (which would ordinarily happen when the pointer was dragged into another menu item). This is illustrated in Figure 3-42.

pp. 87: Hierarchical Menus: [https://i.imgur.com/RrEDo3m.png](https://i.imgur.com/RrEDo3m.png)

pp. 88: Figure 3-42: Dragging diagonally to a submenu item: [https://i.imgur.com/a0gNWHh.png](https://i.imgur.com/a0gNWHh.png)

Others have written about this issue in the context of the web:

Why is there a menu show delay, anyway? [https://blogs.msdn.microsoft.com/oldnewthing/20080619-00/?p=...](https://blogs.msdn.microsoft.com/oldnewthing/20080619-00/?p=21903)

>I run into this problem all the time on the Web. Web site designers forget to incorporate a menu show delay, resulting in frustration when trying to navigate around them. For example, let's look at the navigation bar on the home page of The Discovery Channel. Hover over TV Shows, and the menu appears. Suppose you want to go to Koppel on Discovery, but instead of moving the mouse straight downward, the way you hold your arm on the desk moves the mouse in an arc that happens to swing to the right before it arcs downward. You touch TV Schedules and your navigation is screwed up. You have to start over and make sure to move the mouse exactly straight down.

You can even solve the problem with CSS and without JavaScript, by using ":hover":

Dropdown Menus with More Forgiving Mouse Movement Paths: [https://css- tricks.com/dropdown-menus-with-more-forgiving-mo...](https://css- tricks.com/dropdown-menus-with-more-forgiving-mouse-movement-paths/)

>This is a fairly old UX concept that I haven't heard talked about in a while, but is still relevant in the case of multi-level dropdown menus. A fine- grained pointer like a mouse sometimes has to travel through pretty narrow corridors to accurately get where it needs to in a dropdown menu. It's easy to screw up (have the mouse pointer leave the path) and be penalized by having it close up on you. Perhaps we can make that less frustrating.

<comment><USER39> It should be extremely subtle that users can skim through the categories also. I think they call this debouncing in the JavaScript world.

</comment></comment></comment><comment><USER40> Nice job. To add to the test db, works on Firefox 60.0.2 (64bit) on Ubuntu 18.04 too.

</comment><comment><USER41> I had never noticed that "Where to invest $10,000" before.

</comment><comment><USER42> Off topic but that is a gnarly commit history

<comment><USER43> let he who is without sin cast the first stone...

</comment></comment><comment><USER44> Judging by some of these popular comments, I never want to show HN anything that I build in my _free time_ , ever.

<comment><USER45> People who appreciate the submission upvote, critics comment. There may be more of the former, but unfortunately the latter are more impactful</comment></comment>


New board games from Gen Con 2016 - <AUTHOR> http://arstechnica.com/gaming/2016/08/the-hottest-new-board-games-from-gen-con-2016/ <comment><USER2> How did I miss that "Pandemic: Reign of Cthulhu" was released?

If you've never played it, the standard "Pandemic" is an engaging, clever puzzle of a cooperative game with random elements.

<comment><USER3> I only played the vanilla version of Pandemic, but I found it extremely vulnerable to "quarterbacking" (a board game term for a cooperative game where the optimal strategy is to let the best player tell everyone else what to do). Do any of the expansions alleviate this?

Also, if anyone is curious how this can be mitigated, Hanabi is an excellent example.

<comment><USER4> You could see it as teaching the others, brining the collective knowledge up faster and eventually you can play together on harder difficulties.

I've been introduced to some games where the "quarterbacking" was happening, but eventually people start chiming in with ".. or we could do this because X, Y and Z".

Could you explain the Hanabi thing though?

<comment><USER5> [https://en.wikipedia.org/wiki/Hanabi_(card_game)](https://en.wikipedia.org/wiki/Hanabi_\(card_game\))

Overall, it's fairly straightforward. Each player gets 4 or 5 cards (dependant on player numbers), but they _do not look at their own cards_ \- only the other players can see them.

Cards are numbered 1 - 5, and in five suites (Blue, Green, Red, Yellow, White).

On each players turn, that player can do one of the following:

* Tell another player which cards in their hand are a given colour

* Tell another player which cards in their hand are a given number

* Play a card

* Discard a card

If you play or discard, you draw a new card immediately (but still don't get to look at it).

Telling a player something requires a clue. Discarding a card grants a clue.

Making a play that isn't valid (e.g. playing the white 3 when the top card of the white stack is anything except a two) costs a life.

Lives are shared, and the game is over when they're gone. The game ends when the deck is empty (roughly), or if you manage to play all five "5" cards.

This mitigates quarterbacking because the player is missing some information - they can suggest the best play based on what they can see, but it's possible that, based on what's in their hand, there is a better play to be made, which the rest of the team has to decide on.

Given enough time playing the game with the same group, a skilled quarterback could probably figure out what's in their hand based on how the group reacts and thus end up dominating anyway, but I doubt that's an issue in 99% of cases.</comment></comment></comment></comment>


FB won't censor Trump's posts, but it will censor an account repeating them - <AUTHOR> https://www.vice.com/en_us/article/ep4zvz/facebook-censored-an-account-copying-trumps-words-for-inciting-violence <comment><USER2> I think given the firestorm that would erupt from the right side of the aisle if Trump's posts were deleted - there probably is a slightly specialised handling for his account (and other high profile accounts) vs the general populous for whom standard escalation processes kick in when a post is reported/flagged.

I'm not saying this is right or wrong.

<comment><USER3> The safe spaces being carved out for the right are deliciously ironic. It's a shame they don't get it.

<comment><USER4> > The safe spaces being carved out for the right are deliciously ironic. It's > a shame they don't get it.

If a repost is being deleted, how is that a safe space?</comment></comment></comment>


Ikea sells 500 Euro standing desk in Netherlands, not North America - <AUTHOR> http://www.ikea.com/nl/nl/catalog/products/90088946/ <comment><USER2> Here's something equivalent for even less money. I have one, and it works great. I actually used a tabletop from Ikea for the desk surface:

[http://www.amazon.com/gp/product/B005NJUQVG/ref=wms_ohs_prod...](http://www.amazon.com/gp/product/B005NJUQVG/ref=wms_ohs_product?ie=UTF8&psc=1)

<comment><AUTHOR> Standdesk.io has a motorized desk for the same amount too -- I'm interested in an electric desk.

Still, if Ikea sold standing desks, I wonder if they'd get mainstream quicker.

</comment></comment><comment><USER3> A couple of years ago IKEA NA sold a motorized sit/stand desk. No idea why they stopped carrying it, but I would assume slow sales was the reason.

<comment><AUTHOR> I didn't know that, it's too bad :)

</comment></comment><comment><USER4> Not sure of the point of the post, but here's the base I bought for 500 _dollars_ and I threw on a beautiful piece of birch finished marine plywood I scored on craigslist for $50. [http://www.thehumansolution.com/uplift-900-electric-sit- stan...](http://www.thehumansolution.com/uplift-900-electric-sit-stand-desk- base-silver.html)

<comment><AUTHOR> The points were a few:

\- Why doesn't Ikea make this available in more places where shipping heavy standing desks is not reasonable (ie., Canada from the US)

\- As bulky as the Ikea standing desk looks, I could see it being used in a lot of offices in North America just because it was easily accessible

For me, I discovered the uplift shortly after posting too -- it looks like a great deal and great table. Glad to hear you are liking it too. I'm presently speccing one out!

<comment><USER4> I'm real pleased with mine. The only advice I'd say is to place the uppydowny switch as far out of the way as you can deal with. The case is a bit flimsy where it screws to the table, and I worry I'll break it off if I knock it with my knee a few more times.

</comment></comment></comment><comment><USER5> On August 1, 2014, the "GALANT" series will be replaced by a new series called "BEKANT". Maybe this is what is going on?

Here is the short info (in swedish): [http://www.ikea.com/se/sv/catalog/categories/departments/wor...](http://www.ikea.com/se/sv/catalog/categories/departments/workspaces/desks_and_tables/)

</comment><comment><USER6> I used a cardboard box to create a standing desk. I then changed jobs & needed something portable. After not finding anything My father & I decided to build our own. We are launching on kickstarter soon, if you are interested you can find out more here [http://zestdesk.com/](http://zestdesk.com/)

</comment><comment><USER7> Doesn't include the top apparently.

You can search my post history to see how I made a sit/stand desk for less than $200.

Does anyone know how well the legs stay parallel and if this is a problem with the motion components?

</comment><comment><USER8> Typical americans, welcome to the rest of the world. Try living outside of NA for a month or so and see just how many things aren't available to you, or the insane prices you have to pay.

<comment><USER9> What kinds of things are we missing? And do you mean insane high prices or insane low prices? For most things I was under the impression the U.S. was cheaper.

<comment><USER8> Outside the US people have to pay up to 50% more for products from the US. See the recent case in Australia about the prices they pay for software and Apple products.

Then there's the "This website/service is not available in your country.", for example, see Netflix, Hulu, Pandora and so on.

</comment></comment></comment><comment><USER10> Unrelated question, is IKEA website broken on Chrome for anyone else? If I switch to Firefox it works ok. Chrome doesn't -- the image of the desk overlaps the text on the right.

<comment><USER11> Looks fine for me on OS X running Chrome 35.

</comment></comment><comment><USER12> its not exactly comparable, but: [http://www.amazon.com/gp/product/B001MS7106/ref=oh_aui_detai...](http://www.amazon.com/gp/product/B001MS7106/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1)

</comment><comment><USER13> 500 euro is insane price for a desk.</comment>


Honey, we shrunk the food -- really, really fast - <AUTHOR> http://www.sciam.com/blog/60-second-science/post.cfm?id=honey-we-shrunk-the-foodreally-real-2009-01-15 <comment><USER2> Never underestimate the power of unintended consequences and faulty assumptions. Setting minimum size on fish caught, for example, is intended to protect the young and, hopefully, still virile individuals so that they can sustain the population.

Did you catch the faulty assumption? Small != Young (at least, not necessarily...)

<comment><USER3> They're pretty much all faulty assumptions since they're predicated on the notion that an animal outside of the food chain can do something to avoid affecting it. From farming wildlife to completely eliminating countless species on a daily basis... what the hell do people expect? Everything to magically work out?

We are a part of the global ecosystem only insofar as we are physically in it; we don't interact with the biological community the way any other creature does. Of course we're going to fuck it over. Hopefully I'll be dead before we've completely eliminated it.

</comment></comment><comment><USER4> As usual, we won't care until it's too late.

That will be the history of our human civilization, too obsessed about today, never being truly serious about our future generations.

<comment><USER5> All those years of trying to "be here now" seem to have back fired then?

<comment><USER6> Right, because hippies totally invented consumerism.

</comment></comment></comment><comment><USER7> See also this Newsweek article, "It's Survival of the Weak and Scrawny", which is about hunting elk and other large game.

<http://www.newsweek.com/id/177709>

</comment><comment><USER8> Quite alarming.

"Unlike, say, wolves or lions, which target the smallest, weakest members of a group", that too because we are equipped with artificial power. However I wonder why this phenomenon did not happen with herbivorous chain. I can't comment if rabbits and elephants would pick the smaller plants or the healthier ones. But it seems intuitive to pick the healthier ones here. May be that is why I am the evil human.

<comment><USER9> Edible plants for the most part _rely_ on being eaten to spread their seeds, so if animals did, it wouldn't matter. Humans gathering wild berries on the other hand eat them and then "spread" their seeds into some chemical filled RV toilet.

</comment></comment><comment><USER10> Reverse Evolution?

<comment><USER11> No, just Evolution.

<comment><USER12> _Generational change via selection_ is not the same thing as _evolution_.

<comment><USER13> Yes, that's exactly what it is.

edit: Evolution also includes genetic drift - random chance mutations not driven by selection. But the point is _evolution_ is not synonymous with _progress_.</comment></comment></comment></comment>


Calling all Inventors, Makers and Hackers... - <AUTHOR> http://RedBullUSA.com/Creation

<comment><AUTHOR> View the video about the competition here: <http://www.youtube.com/watch?v=QenCwxx7x90></comment>


Introduction to Map Projection - <AUTHOR> http://www.colorado.edu/geography/gcraft/notes/mapproj/mapproj.html

<comment><USER2> I came across this projection a couple of years ago and completely changed the way that I look at maps:

<http://flowingdata.com/2010/10/18/true-size-of-africa/>

</comment><comment><USER3> Obligatory XKCD reference

<http://xkcd.com/977/>

<comment><USER4> _> Dymaxion: ... "you type in Dvorak"_

Agh, I've been hit! Man down, man down!

</comment></comment><comment><USER5> A Guide to Coordinate Systems in Great Britain is a wonderful resource as well

[http://www.ordnancesurvey.co.uk/oswebsite/gps/docs/A_Guide_t...](http://www.ordnancesurvey.co.uk/oswebsite/gps/docs/A_Guide_to_Coordinate_Systems_in_Great_Britain.pdf)

<comment><USER6> That is the best-written article I've ever seen on this topic. Thank you for posting it!

</comment></comment><comment><USER7> Along these lines, I'd recommend the book Flattening the Earth by John P. Snyder.</comment>


I've Never Had a Goal - <AUTHOR> https://m.signalvnoise.com/ive-never-had-a-goal/ <comment><USER2> The author never says it explicitly, but did he substitute curiosity for ambition? Probably not, but it seems like something that could happen.

</comment><comment><USER3> It sounds like he did have goals but was okay he didn't reach them. Those are still goals.</comment>


Ask HN: How do you write Windows desktop software these days? - <AUTHOR>

I have an idea for app but instead of going the mobile route I've been thinking of making it for the good ol' Windows desktop.  The problem is, I'm a couple of years removed from desktop development and things look kind of cluttered to me right now.  You have .NET, WPF, and even win32 and MFC are still around (sort of).  Then you have all these third-part toolkits like Qt and bindings for other languages and runtimes like PySide and wxPython.<p>I guess the short version of my question is: For a commercial Windows desktop application, where do you turn to get it done? <comment><USER2> When committing long term to Windows Desktop development, why would one choose the learning curve of a framework outside the Microsoft toolchain? It seems to me that choosing a multiplatform tool chain for Windows development is somewhat likely to be premature optimization (most things be equal).

I'd add that unless there is a compelling set of legacy code, win32 and MFC are not really serious options to .NET.

On the other hand, forms is an option to WFC for a minimum viable product - but not once UX design rises in importance. Early on, I would say that WFC v. Forms is purely down to investment in the learning curve.

</comment><comment><USER3> If your application doesn't have special requirements (e.g. heavy computations, graphics, etc..) then using C# + WPF (or Winforms) is very efficient in the sense that you can get a lot done quickly. Visual Studio is a great IDE, MSDN documentation is not bad, and because a lot of people use those technologies then whenever you hit an issue it's pretty quick to find someone who had the same one and solved it (e.g. on StackOverflow).

</comment><comment><USER4> If you are planning on deploying to the Microsoft stack then use the Microsoft toolset - .NET, Visual Studio, c#.

Winforms is pretty easy to pick up and the workflow between visual designer and hooking up to events is good. Double click on a button in the visual winforms designer and it puts you in the method in the code....something I wish Interface Builder would do :).

I've no experience with WFC, but as others have pointed out, it seems to be the way to go for good looking apps.

</comment><comment><USER5> You know, a lot of people give .NET a lot of scuff for being a bloated language (insert 15 other insults here) but it really CAN work well for applications in a professional environment. But then again it is always about what computer language you know the best.

That being said I also think Delphi is another great alternative! I personally have never used it but I have seen a lot of applications that I admire admit to using it for development.

</comment><comment><USER6> I'm a Microsoft developer. I'd suggest using the .NET framework with WPF or Winforms for the speed of development. Plus there are tons of examples and tutorials to help you along the way. Also hands down Visual Studio is one of the best IDE's available. (no flames please)

</comment><comment><USER7> For fast development I'd suggest Python and PySide or wxPython if there are some numerical parts that need to be fast use NumPy, SciPy and the PyPy interpreter instead of the regular Python interpreter.

</comment><comment><USER8> For a commercial application, you use .NET with either Winforms, or if you are looking for something more flexible & sophisticated, WPF.

</comment><comment><USER9> Qt , the best

<comment><USER10> ... not when you check the price of a commercial licence.

edit: found the email I was sent when asking Digia. 2995 EUR Windows Desktop only for a single developer, 4195 EUR for multiple o/s development; includes 12 months email support and maintenance upgrades.</comment></comment>


Linux I/O Scheduler Comparison On The Linux 3.4 Desktop - <AUTHOR> http://www.phoronix.com/scan.php?page=article&item=linux_iosched_2012

<comment><USER2> This may be a great article, but the effort of parsing through the number of ads and highlighted words on the page made me give up trying to read it after the first two paragraphs. Not to hijack this posting, but can this amount of advertising really work for a content site? It seems like it would drive away most readers.

<comment><USER3> Unfortunately, this seems to be a standard Phoronix article.

They picked an interesting topic and ran some benchmarks. In some cases the older CFQ scheduler is much slower than the NOP scheduler. In others, the Deadline scheduler pulls way ahead.

The analysis in the article is essentially the paragraph I wrote above. No discussion of why one scheduler may be performing so much better/worse in one case. In fact, there is only a single sentence description of each scheduler.

</comment></comment><comment><USER4> Where does BFQ fit into this? I've been using it as my I/O scheduler and I've noticed significant lag when I'm transferring large amounts of data between drives. Any thoughts on this? I've been thinking of switching back, but would love some thoughts on it's performance capabilities.</comment>