Teal and Orange in Hollywood movies - <AUTHOR> http://theabyssgazes.blogspot.com/2010/03/teal-and-orange-hollywood-please-stop.html

<comment><USER2> To every generation there is a film technique which defines it. There was the smokey grey/green from the Matrix films. Michael Mann had his desaturated shallow-DOF look. David Fincher uses silver-retention on his film development to extend the dynamic range while underexposing his shots (thats why interiors in Seven were so "dark" yet exposed).

Part of the device of cinema is extending the mise-en-scene outward and upward to the representational devices (projection, development and treatment).

Part of the study of film is tracing how the use of technique defines generations of film makers. Often, technology serves as an impetus for a style (i.e., Robert Altman and the use of multi-track audio on Nashville precipitated very "talky" films from the 70's/80's), or the developments in computer motion controlled rigs.

Or lets not forget: lens flares.

Color grading (ie, the orange/blue compliments in this article) are also defined by outward influences like magazine photography, trends in CGI, etc.

Anyhow, in a few years a new dominate "look" will pervade cinema and we'll all have something new to complain about.

<comment><USER3> Both this comment and your comment further down below are really illuminating to a film luddite like me. It's always interesting to hear the nitty-gritty details of someone else's trade. It always amazes me how much detail goes into things that at the end of the day, the end user is none-the-wiser.

Thanks for the informative posts.

<comment><USER4> Interestingly you might find that once you are aware of such details it is hard to go back and "just watch a movie".

You start noticing color gradients, lighting techniques, camera angles, and many other technical details, and spend mental effort categorizing and critiquing them instead of being immersed in the experience, like, perhaps, you were before.

As computer geeks notice bogus computer terminals in the movies, and it is somewhat irritating and frustrating "no, dammit, that is not what a mainframe terminal looks like!" film geeks do the same with movies.

<comment><USER5> After working a bit on a film in college, I started noticing cuts, and it started to drive me insane. It's one of those things that's largely inconsequential. I, as an audience member, am aware when a cut is made. But now, after doing a bit of editing, I notice just how many cuts there are. Conversely, I now have eternal admiration for scenes comprised of as few cuts as possible (cf. "Children of Men").

<comment><USER4> <http://en.wikipedia.org/wiki/Russian_Ark> just took that to the extreme and made the whole movie in one long shot. It is interesting to watch just for that effect. The content is only interesting if you care or are familiar with Russian history.

<comment><USER2> <http://www.youtube.com/watch?v=0epB5Z6ijpk> The Player, opening scene. Self referential of the fact that it's all one cut.

A dissection of the Copacabana shot from Goodfellas - <http://www.youtube.com/watch?v=IBMKyNJvNV8>

And one of the most brutal long-takes I've ever seen: the Death of Little Bill, Boogie Nights (NSFW): <http://www.youtube.com/watch?v=znwh41szei4>

</comment></comment></comment></comment></comment></comment><comment><USER6> Am I the only one who doesn't mind the blue/orange gradient? I don't get why everyone is going mental about it (this article and many like it have popped up frequently over the last few years). The article itself isn't even worth reading, filled with hyperboles like "...a monstrosity that would eventually lead to one of the worst films ever...". Especially the history lesson at the end is superfluous.

Ironically enough, the first thought I had when I visited his blog was "oh god no not another white text on black background site!". But I'm not going to write an article about the trend of light text on dark background, which would actually be a more valid complaint because it objectively reduces readability, while the orange+blue palette is just taste.

<comment><USER7> > it objectively reduces readability

Would love to get some pointers for good reads on this. I've always felt the opposite.

<comment><USER8> Yeah, I use Readability in Inverse mode myself so I can get my reading in dark background and light text.

To be fair, that is not white on black, it's very-light-grey on dark grey. Personally I find white #FFFFFF on black #000000 hard to read too, but very few sites use such colors.

Light grey on black, which this blog uses, seems perfectly fine for me.

Might there be differences of opinion because of differences in monitors? I'm using Eizo S-PVA, so I might have it better than those with cheaper LCD monitors.

</comment></comment></comment><comment><USER9> I have barely noticed the color schemes. I do recognize different color in films from different ages--for example, I like the warm colors of 70's and 80's film--but generally I don't care much because it doesn't distract me from enjoying the film.

However, there's a huge issue that has practically stopped me from watching the recent films, or nearly anything made in the 2000's.

It's how cutting the film and camera tracking have changed. It used to be more about long takes and cinemaesque dolly shots that also give time to get immersed in the film. But there's a newer trend that started in the late 90's and developed fully a few years later: extremely short and rapidly changing cuts and excess hand-held filming with the camera shooting from within the scene, rapidly turning and changing positions. To me, it feels like watching a strobo light: I literally have no idea what's happening in the film. It just all flashes in front of my eyes.

The problem is that it's not just action-packed scifi films or anything: many films in all genres have become more fast-paced. You can barely find a romantic comedy or a drama without several scenes that enable this ADHD limbo. To make it worse, even European films have begun to adopt this style in the last decade.

I watched some old action films such as Rambo or Terminator recently and I must say that even they were more moderate in tempo than the last few, and not necessarily action, films I've seen in the cinema in the last five or so years. This is just terrible and I hope cinematography will recover soon or that these tricks will move on to the 3D videos.

Similarly to reading books, a good film gives you the essentials of the plot, characters, and the visual scene only and leaves the rest to your imagination. And giving space to this imagination is crucial to make a good film.

A good film must not give you everything because it can never be as good as if you had imagined it yourself. In opposition, these youtube flicks with 50M budget are only trying to make a first impression on you.

<comment><USER10> > Similarly to reading books, a good film gives you the essentials of the > plot, characters, and the visual scene only and leaves the rest to your > imagination.

Vonnegut would disagree that books need to be as spare as you imagine. As would Tolkien and William S. Burroughs. You have a rather narrow view of the art to leave out those authors.

<comment><USER9> I've only seen books where you absorb textual descriptions of what's happening by deciphering sentences and paragraphs written in some vague form of language which leaves using your imagination to be the only way to actually make it vivid and real. But, I probably don't know everything.

Films are a bit different because they inevitably offer some visual scene that is much more pre-set than a book can ever offer. But there comes the art of cinematography which, like any art, is about showing pointers to what can't be seen. This approach has become more rare yet it would be very useful especially in dramatizing these action and horror films that, these days,diverge from it most.

It's often much more effective to _not_ show what's happening than detailed takes of the action. A cliche is that the first time an alien or a fictional monster is shown on the screen, the film will falls flat because the unrealistic visual mock-up blatantly kills all chance for your imagination to do its job. Similarly a hectic fighting scene just gets lost in the action but the same could be filmed differently, showing something that all the fighting points to, instead of showing the fighting itself. With books, they say that a writer should describe what happens instead of writing his interpretation of it.

</comment></comment></comment><comment><USER11> <http://news.ycombinator.com/item?id=1193657>

</comment><comment><USER12> Using complementary colors to make your subjects "pop" is just standard color theory.

When coloring anything, you pretty much have to choose some variation of red/green, orange/blue, or violet/yellow. Anything else blurs into one of these three.

We'd all do better to criticize specific color choices, rather than stigmatizing one of the three possible general palettes. Otherwise it's like criticizing violins or oil paint for being overused.

</comment><comment><USER13> Wow, all you people with your fully functional color vision. Maybe I _won't_ get the retinal DNA hack if it causes this much pain.

</comment><comment><USER14> I think this was the first thing I ever submitted to HN. It got several hundred points and hit #1 for a time. It's amusing to see things resurface here.

EDIT: It was the 17th submission, 538 days ago, My god! <http://news.ycombinator.com/item?id=1193657>

</comment><comment><USER15> I first noticed this in the movie "Traffic." Great movie and cinematography in my opinion, but I noticed how the orange came out in the Mexican drug cartel scenes and a heavy blue in the DC ones.

<comment><USER2> That was an intentional narrative device from Soderbergh though.

From IMDB:

"To achieve a distinctive look for each different vignette in the story, Steven Soderbergh used three different film stocks (and post-production techniques), each with their own color treatment and grain for the print. The "Wakefield" story features a colder, bluer tone to match the sad, depressive emotion. The "Ayala" story is bright, shiny, and saturated in primary colors, especially red, to match the glitzy surface of Helena's life. The "Mexican" story appears grainy, rough, and hot to go with the rugged Mexican landscape and congested cities."

<comment><USER16> "Inception" took a similar approach, where each dream level had a unique tint.

</comment></comment></comment><comment><USER17> Tron certainly takes the prize here, but at least they had a plausible excuse for the palette choice :)

<comment><USER18> The blue/orange palette comes straight from the 1982 original. The author does not make a valid point with TRON, especially as he is concerned about color realism. As he says it's set inside a computer so it could look like anything. Any way I read his argument, it ends up contradicting itself on that one.

</comment></comment><comment><USER19> Blue/Orange contrast is used because red/green has too much of a Christmas vibe. Complementary colors look good. Its not like its a conspiracy.

<comment><USER20> Yellow and purple don't look particularly good. Besides, you can make any combinations of color look good.

<comment><USER21> Not a Lakers fan eh? NY's complementary sports colors of choice seem to be orange blue, pretty close to the palette the OP hates (Knicks, Mets).

</comment></comment></comment><comment><USER22> These correspond to the basic axis of light typically found in the real world (up until fluorescent, anyways):

Blue = natural light (5000-8000K)

Yellow/Orange = artificial/tungsten light (2400-4500K)

Anyone who's shot actual film will know that if you shoot daylight film in tungsten, it comes out yellow, and vice versa. For you young folks who only ever knew digital cameras, that's the "white balance" function automatically correcting for you.

It's only natural for this set of color contrasts to show up in film (try shooting something lit by a tungsten lightbulb in front of a north-facing window).

/professional photographer

<comment><USER23> I disagree. The effect of illumination temperature does take place, but in the article the stress is on color grading. It is that color grading that makes faces orange under both daylight (Transformers example) and tungsten light (iron man example).

</comment></comment><comment><USER24> Insightful article. Happy for the repost. Missed this the first time around.

</comment><comment><USER25> The first time colors really stood out to me in a movie (and I noticed it while watching) was One Hour Photo. The range was so wide and the colors really added to the story telling. Later (I think on the DVD special features) someone broke it down into it's constituent parts and I really understood an example of how someone designs with color. Very illuminating.

</comment><comment><USER26> When all you show is frames that happen to be teal and orange, of course you can make it look like all movies are just teal and orange. Also, the sky is blue and light-colored skin can easily look orangish, which explains most of the frames.

<comment><USER27> Ever since I saw the first of these articles a few years ago, I've occasionally paid attention to this effect (and a little before then). It's not when teal and orange occur that's distracting, it's when nothing else does. You sometimes see scenes with orange trees and teal shades, with no other hues.

The best example of this, to me, is the CSI franchise. LA was light blue, NY was straight up blue and Miami straight up yellow.

<comment><USER28> Yup. Never really been upset by the teal/orange thing in movies, but in CSI everything looks like they've let a first-year cinematography student go wild on it. And even so, I wouldn't say it looks ugly, it's just a cheezy effect.

</comment></comment></comment><comment><USER29> It is pretty common in any form of art or photography to use color balance to convey a mood.

The eye is pretty good at dealing with these things, does the author get frightened and angry when the setting sun makes things appear orange?

<comment><USER30> In the the article he says that both effects (nighty blue and sunset red) can't happen at the same time IRL...

</comment></comment><comment><USER31> The last bit about this 'disease' infecting artists through history was particularly odd. Can you imagine! We might end up with works like this:

<http://en.wikipedia.org/wiki/Cafe_Terrace_at_Night>

Van Gogh was a big fan of these colors and it shows in his work.

<comment><USER32> Van Gogh also admitted, in a letter to his brother Theo, to using deliberately exaggerated colors because he suspected the pigments he used were of such poor quality that they'd quickly fade to something more sensible.

Which turned out to not always be the case.

<comment><USER33> "Instead of trying to reproduce exactly what I see before me, I make more arbitrary use of color to express myself more forcefully." (Letter to Theo van Gogh, 11 August 1888), see [http://painting.about.com/od/artandartistquotes/a/Quotes_Van...](http://painting.about.com/od/artandartistquotes/a/Quotes_Van_Gogh.htm)

That link has several quotes on use of colour.

Van Gogh is notable in his symbolic use of colour.

</comment></comment></comment><comment><USER34> Post processing isn't exactly new. Not sure what the big deal is. I'm just wondering how long it'll be before we see entire feature length film processed using HDR?

<comment><USER35> Pretty much every film ever made on real film is in HDR. What would be "tone mapping" in a digital HDR image is just "developing" a film.

</comment></comment><comment><USER36> Ironic value of complaining about the ugliness of Hollywood movie color schemes while utilizing an absolutely putrid color scheme on the blog itself: priceless.

Physician, heal thyself.

<comment><USER37> Can we please stop this?

You are not making a valid argument, not in any way, shape or form. It's pure, irrelevant bullshit.

It's possible to be completely unable to color grade yet still notice trends and write that you think they are horrible.

But you are not even talking about the author's ability to color grade, you are talking about fucking web design which is a tenuously related field at best. It just makes no sense at all.

Critics do not have to be good at what they criticize in order to be good critics. Would Roger Ebert be a good director?

It's astonishing really, a complete non-sequitur.

<comment><USER38> The author is a colorist.

<comment><USER37> And? Was I suggesting the author isn't or what? Criticizing the author's web design skills just makes no sense whatsoever. It just doesn't. There is no connection.

I was also trying to make a larger point: Even if you think the author's work sucks you can't just dismiss everything that is said.

<comment><USER39> _Even if you think the author's work sucks you can't just dismiss everything that is said._

Yes. We can. Some ppl may not like it, but we certainly can.

<comment><USER16> The reason that "some ppl [sic] may not like it" is because it's logically unsound. Dismissing a point of view based on the party, rather than on the position, is the definition of a tu quoque fallacy. <http://en.wikipedia.org/wiki/Tu_quoque>

P.S. I agree the author's web design isn't exactly "web 2.0" but it clearly does not diminish the author's credibility to comment on film colorization. They are completely separate.

<comment><USER40> > Dismissing a point of view based on the party, rather than on the position, > is the definition of a tu quoque fallacy. > <http://en.wikipedia.org/wiki/Tu_quoque>

Except that the original poster's comment was not a tu quoque fallacy. Note from your source:

       This form of the argument is as follows:

           A makes criticism P.
           A is also guilty of P.
           Therefore, P is dismissed.

In this instance "P" is "Hollywood color choices". The original poster did not dismiss P (i.e., a dismissal of P would be that Hollywood color choices are perfectly fine). The original poster dismissed the blog authors reputation to assert an opinion regarding Hollywood color choices because the blog author, by virtue of having made awful color choices in his blog, had presented evidence of lack of knowledgeable sufficient to assert an educated opinion about P (Hollywood color choices). Whether Hollywood color choices (P) are bad or good remains an open question, P was not dismissed.

Note further in your own citation:

       Legitimate use

       The legitimate form of the argument is as follows:

           A makes criticism P.
           A is also guilty of P.
           Therefore, A is dismissed (from his/her role as a model of the principle that motivates criticism P).

       The difference from the illegitimate form is that the latter would try to dismiss P along with A. It is illegitimate to conflate the logically separate questions of whether P is a valid criticism and whether A is a good role model.

Which is exactly the use made by the original ironic/priceless comment. "A" (blog author) criticized "P" (poor color choices). "A" is also guilty of "P" (poor color choices). "A" was dismissed.

<comment><USER16> 1\. As another poster already said, "Readability and typography is not something someone who color grades deals with." EVEN IF I were to accept that this is not a tu quoque argument, the two skills are _completely different_. I am personally a web designer, and I have no basis or knowledge to comment on color grading in films. None.

Nevertheless, it's a moot point because...

2\. I believe the original poster's comment, "physician, heal thyself" is a reference to a person (in this case, the author), and not to a position.

Can I make this any plainer?

<comment><USER40> > I believe the original poster's comment, "physician, heal thyself" is a > reference to a person (in this case, the author), and not to a position.

That would therefore be an incorrect assumption:

<http://en.wikipedia.org/wiki/Physician,_heal_thyself>

"The moral of the proverb is counsel to attend to one's own defects rather than criticizing defects in others, ..."

Or, in other words, before criticizing movie color defects, attend to his own web color defects.

> I am personally a web designer, and I have no basis or knowledge to comment > on color grading in films.

Granted. But, would you say that your experience in web design and color selection would allow you sufficient knowledge to identify an absolutely awful movie color scheme? I would posit yes. The converse would also be true. Someone with movie color grading expertise should have sufficient knowledge of colors to at least make a reasonably passing effort at reasonable web color selection. I.e., the underlying basics apply and carry through in both arenas, even if the particular technical specifics differ.</comment></comment></comment></comment></comment></comment></comment></comment></comment>


The calls to reign in Mark Zuckerberg have never been louder - <AUTHOR> https://www.fastcompany.com/90346111/calls-to-reign-in-mark-zuckerberg-facebook-have-never-been-louder <comment><USER2> This is yet another clickbait article artificially amplifying the voices of a minority group of activists attacking [a tech company]. How many of these do we need to prop up on HN or Reddit or wherever? Writing something critical of Facebook is the lowest risk, least interesting piece a journalist can author.

The reality is that Zuck has done a fantastic job in bringing Facebook to where it is, and uncritical thinkers are laying blame at Facebook's feet for what largely is human nature or differing values/opinions across Facebook's customer base. And of course mixed in with various charges from these groups are the usual garden variety shareholder proposals that are just the far-left progressives weaponizing a corporate governance process for political ends.

<comment><USER3> The reality is your subjective take on Facebook? HARD PASS on your steaming hot take.

<comment><USER2> My subjective take is no more valid or invalid than others' personal opinions.

I don't think Facebook is without flaws, by the way. But I do think they're doing a lot correctly as well, and that Zuckerberg is smart enough to navigate the company carefully through very difficult decision points. It is easy for armchair activists to rant about Facebook en masse but there are no easy solutions, and at some point they have to square with the fact that yes, Facebook serves a lot of people who aren't themselves and who think differently from themselves.

When I see the constant stream of one-sided articles that offer no nuanced intellectual take on Facebook or operating such platforms neutrally, it does make me write off those journalists and those groups of activists whom the journalists feature. And the reason really is that they comes off as willing bad-faith participants in a political power dynamics struggle (who can foment the most outrage!) rather than people pushing for a principled outcome that fairly serves everyone, including those they disagree with.

<comment><USER4> Is breaking the law by selling and breaching the data of millions of users what you are referring to when you say that "Zuckerberg is navigating the company carefully through very difficult decision points" ?

<comment><USER2> That's under the "I don't think Facebook is without flaws, by the way"

</comment></comment></comment></comment></comment><comment><USER5> Too bad for all those calling for it he was smart enough to keep voting power.

I might not care for Zuckerberg particularly, but I hope if I ever own a company I have the foresight to never give up control.

</comment><comment><USER6> *Rein in.

I know it's in the actual article, but man that one really gets to me for some reason.

<comment><USER7> Why do I feel like this tells me all I need to know about the article?

I despise Zuckles as much as the next peon, but is he really the problem? Without him, would FB aspire less to evil, or just get more craftily (and overwhelmingly more) evil like Google?</comment></comment>


Mozilla WebThings - <AUTHOR> https://hacks.mozilla.org/2019/04/introducing-mozilla-webthings/ <comment><USER2> This is the Mozilla I love. I wish they did more projects like this, it's a shame Firefox OS went away, especially in this world of PWAs.

I do love that this dashboard can even be ran on your router. Also the web UI looks really clean.

<comment><USER3> Firefox OS has been rebranded as KaiOS, and its eating marketshare with $5 LTE bar and flip phones. Said devices are pretty minimally specced with a Qualcomm 205 and 128MB of Ram, but Mozilla did a great job optimizing for low end devices.

<comment><USER4> Source for the supposed "eating" of global marketshare? I can't find any marketshare report that even mentions such an OS.

<comment><USER5> Aren't Nokia/hmd featurephones all running kaios?

<comment><USER6> The only Nokia phone running KaiOS so far is the Nokia 8110 4G ([https://en.wikipedia.org/wiki/Nokia_8110_4G](https://en.wikipedia.org/wiki/Nokia_8110_4G)).

</comment></comment></comment></comment></comment><comment><USER7> Whoa, at the end of the article there's an announcement about "WebThings Gateway for Wireless Routers". Is this the beginning of apps for routers? I've talked about the idea before:

[https://news.ycombinator.com/item?id=18887403](https://news.ycombinator.com/item?id=18887403)

I'm excited to hear more.

<comment><USER8> What exactly differentiates "apps" here from regular programs you can install on routers? If your router runs a hosted system such as Linux and isn't locked down (e.g. OpenWRT), you can install/compile for any existing program that supports the architecture and system. Installing tor as you in linked post is just "opkg install tor". A lot of packages have webgui frontends, too.

Edit: I've read the article and Mozilla even mentions reskinning/basing off of OpenWRT. Which only puzzles me even more given you write "the beginning of apps for routers" as if OpenWRT/pfSense/etc doesn't exist.

<comment><USER7> Grandma can't compile and install OpenWRT packages. The idea is to let developers create apps (server apps) that anyone, especially Grandma, can install on their router. The experience should be similar to installing apps on iOS or Android phones.

NAS apps sound interesting, but not what I'm looking for. Router apps have untapped potential because routers are relatively inexpensive, always on, and have a real Internet address, unlike the rest of the home/office network.

What kind of apps would developers create? All kinds! Some would succeed and some would fail, just like phone apps. The point is to unleash developer creativity. Today, nearly all Internet traffic is routed to Netflix, Google, Amazon, and Facebook. Over the next few years, consumers will buy millions upon millions of upgraded routers. I think they would like to buy routers that do more for them than send all their traffic to a tiny number of huge companies.

<comment><USER9> Several good points. Only one aspect made me laugh. Even if I _can_ "opkg install <pkg_name>" to run the Mozilla WebThings Gateway, I'm lazy. I'd rather buy a box that maintains my privacy and is updated periodically with security and feature enhancements. What made me laugh is that I don't fit your stereotype. I first used ddwrt around 2003 then switched to OpenWrt and convinced QCA to adopt it as the basis for QSDK when 11ac routers came out. And if all goes well with my daughter-in-law, I'll become a Grandma in 2-3 weeks. But I am looking forward to easily installing apps, especially those that respect my privacy. :)

<comment><USER7> Congratulations on becoming a grandmother! Sorry I didn't think of a better example of the kind of user I'm thinking of. "Bob the accountant", mentioned by someone else, is probably a better example.

I've also run several generations of OpenWRT and I've decided it doesn't make sense for me to spend time maintaining it. For example, I'm interested in installing something like Zulip (an open source team chat service) on my router, but I know from experience that anything special I install in OpenWRT requires custom configuration and will need regular manual maintenance and upgrades. It's a big time commitment and I have to be careful with my time.

In a better world, I would tap to install Zulip on my router, automatic upgrades would be enabled by default, and I would be prompted to also sign up for a Zulip-oriented encrypted backup subscription service. Having spent only a minute or two to install Zulip, I would gladly pay for the backup service since the developers proved that they respect my time. I would no longer feel the need to sign up for another cloud service. Privacy would win!

<comment><USER9> Your desire not to have to admininster OpenWrt yourself is legit. I don't either. The Mozilla WebThings Gateway integration work is being done by Mozilla so that they can offer the result to OEMs who would sell a product with it already installed, and the Mozilla team would maintain the sw. So consumers at any tech skill levels won't have to be sysadmins in order to achieve the privacy and security protections they deserve.

</comment></comment></comment></comment></comment></comment><comment><USER10> This looks like a competitor to homeassistant/Hass?

<comment><USER11> Yes, it looks this way to me too. Interesting that they didn't join forces.

<comment><USER12> Thanks it took me way too long to figure out "what" this thing was.

</comment></comment></comment><comment><USER13> I expected to see MQTT as an integral part of the WebThings Gateway but haven't found it so far

<comment><USER14> MQTT is kind of crap so I'm not surprised.

<comment><USER15> What's the problem with MQTT? It's basically the interconnecting standard for all things IoT. I mix and match IoT devices, and everything is fed into Home Assistant through MQTT, plus logging to InfluxDB. I'm familiar with the protocol and haven't found any wart; the biggest problem is how to run it with redundancy and at a scale.

<comment><USER16> I cannot stand debugging MQTT devices. From establishing a connection to sending data, it is consistently difficult to pinpoint where the failure in a system is occuring.

Contrast this with HTTP and WebSockets that are extremely simplistic to use. Largely by virtue of bigger communities using them, but so it is.

Where's the benefit of MQTT? The code is just as large and more opaque by being an uncommon standard (compared to HTTP). Everyone says bandwidth, but that's hardly a concern often and when it is...I can never seem to find the numbers of how much data usage MQTT would save for a given application.

</comment></comment></comment></comment><comment><USER17> > We're also excited to share that we've been working on a new OpenWrt-based > build of WebThings Gateway, aimed at consumer wireless routers.

I'm impressed. Almost sold, even.

All I'm left wondering about is device-support.

How does this compare to (for instance) Home Assistant?

<comment><USER18> I've been using Things gateway for probably a year or so now (I'm just using z-wave devices, but Things supports lots of other types as well). The main thing I see missing that most home automators will want is support for locks/garage door openers/etc. The interior stuff like lights/alarms/plugs/sensors/etc. is all great.

A lot of emphasis is on their Web of Things protocol that looks really cool and would be fun to play around with if you wanted to add your own home-made device (or hopefully more vendors will be adopting that protocol soon).

</comment></comment><comment><USER19> Took a quick breeze though the intro and maybe missed it...

Where's the love for IoT DIY/tinkerer gadgets though? i.e. Arduino, Beagle bone, ESP8266/32?

<comment><USER20> Check the "Arduino" tabs on the WebThings Framework homepage [0]. See also the Supported Hardware list [1], which includes ESP8266, ESP32, and Raspberry Pi (among many others).

[0] [https://iot.mozilla.org/framework/](https://iot.mozilla.org/framework/)

[1] [https://github.com/mozilla-iot/wiki/wiki/Supported- Hardware](https://github.com/mozilla-iot/wiki/wiki/Supported-Hardware)

</comment></comment><comment><USER21> What products support WebThings right now?

<comment><USER22> Here is the maintained list of supported hardware:

[https://github.com/mozilla-iot/wiki/wiki/Supported- Hardware](https://github.com/mozilla-iot/wiki/wiki/Supported-Hardware)

</comment></comment><comment><USER23> Ok, so if I would like to have a motion sensor (and maybe a camera) attached to a server on a rasperry pi which sends alerts to my smartphone ... how much work and tinkering can I expect at the current state, if I am very good in javascript, node and linux, but not at "low level" things?

<comment><USER9> Try either the e-mail sender add-on or the twilio add-on, then create rules that notify you via one of those methods. Camera integration is tricky, mostly due to the lack of standards around data streams and extra sensors/actuators, dealt with in different ways by different vendors. Other binary sensors or variable sensors can be triggered easily with rules to notify you of things you care about.

</comment></comment><comment> white-moss A competitor, Samsung SmartThings has sandboxed-app system. It enables users to operate IoT machines with groovy based programming language.

Things Gateway also can control IoT machines, but its simple rule-based system. It is currently losing point and improvable feature.

I'm very excited with Things Gateway philosophy, so I can't wait for its next evolving.

</comment><comment><USER24> Are there docs for setting this up on a pi without flashing it? I want to run this alongside a few other things on my pi.

</comment><comment><USER25> Would this be compatible with Turris Omnia?

<comment><USER9> That's one of the targets for OpenWrt support, yes.

</comment></comment><comment><USER26> Any particularly good tutorials exploring it? How well does it integrate with existing tech, both closed and open? (E.g. in open-source Home Automation, MQTT seems to be the glue of choice)

</comment><comment><USER27> Everytime i see a Mozilla product announcement, i feel hope.

The hope for a better Internet.

It's opposite feeling with Google.

<comment><USER28> Google has done a fairly amount of work to help the world wide web survive while more and more gated mobile platforms are created, because their revenue still depends on it.

</comment></comment><comment><USER29> Sorry for the aside but what CMS does Mozilla use for these publications? Just out of curiosity

<comment><USER30> Looking at the source, it looks like they're just using WordPress.

</comment></comment><comment><USER31> Does it use multicast discovery?

<comment><USER32> yes mDNS

</comment></comment><comment><USER4> C'mon Mozilla, please. Less projects that will end up like Firefox OS, more work on _Firefox_.

<comment><USER33> Seriously? IoT is a quickly growing, potentially massive and ubiquitous field. Given the shit state of security and technical implementation of its initial era, in very glad that a well-resourced non-profit is helping to create an open standard.

<comment><USER4> And six years ago, mobile was a quick-growing massive and ubiquitous field. How did that pan out for Mozilla? A failed operating system and the beginning of a huge decline in both marketshare and performance for Firefox.

<comment><USER33> Last I checked, Mozilla was still a functioning, funded company pushing out regular updates to Firefox, among other projects. Mobile still is a massive and ubiquitous field, and Firefox Mobile is one of Mozilla's ongoing projects. You believe that a failed project means a company should stop innovating and entering emerging fields?

<comment><USER34> maybe if they'd actually ENTER it'd matter. partner up with a chinese manufacturer and make mozilla branded IoT stuff. providing a platform without associating a manufacturer is doomed to failure imo. Especially in the saturated hyper competitive markets mozilla chooses to enter.

<comment><USER35> I do expect them to be attempting to partner, so hopefully we'll see some announcements in the future.

</comment></comment></comment></comment></comment></comment><comment><USER36> it seems to be mostly for domotics right? what about IOT for other things like medical devices for instance that would be a good area to open source

<comment><USER9> the W3C Web of Things framework is agnostic to use cases and devices. Mozilla's WebThings framework can work in medical, industrial, etc. It's just that Mozilla's focus is to put people first. (Plus it's easiest to invite makers and community dev when contributors can use it themselves at home). All the code is open source -- I've already seen some industrial companies pick it up and customize for their needs.

</comment></comment><comment><USER37> this thread further illustrates the dumpster fire of self importance that is HN

</comment><comment><USER38> Are there any Mozilla projects that have any sort of market share and make money or are they mostly just living off that sweet Google cash for their ~10% Firefox market share?

Any chance Google stops funding them soon?

(Wow, a question was asked. Better censor it Mozillans!)

<comment><USER24> You also asked a question with a lot of editorializing in it. I wouldn't call downvotes censorship.

<comment><USER38> Exactly what part of it was editorialized?

Is getting $500 million dollars a year from Google not a sweet deal?

</comment></comment></comment><comment><USER39> My first reaction is "wtf? What about WebBluetooth?" That is an open standard that supports tinkering, integrates with Permissions api, etc. And it's been withering on the vine with no help from Moz... this looks like a poor alternative, tbh, unless I'm missing something.

<comment><USER40> What does Web Bluetooth have to do with IoT? Bluetooth is a short range, low- bandwidth protocol for 1:1 pairing of devices, isn't it?

That aside, Google's approach to introducing experimental APIs like Web Audio, Web USB, Web Bluetooth etc has been... less than ideal. Having been involved in it, I don't think it's surprising that other vendors are not interested in helping.

<comment><USER41> I'm making an IoT device that connects through web bt. Web bt allows us to circumvent having to publish mobile apps, at least for Android and desktop OSes.

<comment><USER40> Sounds like a cool use case, it just sounds nothing like what WebThings does.

<comment><USER41> It pretty much covers the same use case, except my device doesn't use wifi directly to access the interwebs.

</comment></comment></comment></comment></comment><comment><USER42> My first thought seeing this headline: Let me guess, another move from Mozilla to start gathering more personal data. I wish they'd proven me wrong.

<comment><USER43> Have you played with it at all? Mozilla isn't acting as a data broker, they're providing software and a framework. The world of iot doesn't have that many great offerings for private systems. Mozilla is taking their years of software experience and building something decent. I'm glad to see this hasn't been shuttered yet. I've been wanting to move more of my home automation away from cloud based services and this has a lot of potential. (The current best offering I know of is hass)

<comment><USER3> Even things Mozilla did pull support from and attempt to shutter, like Thunderbird and Firefox OS (now KaiOS) had vibrant communities that stepped up and kept these projects alive.

Mozilla does know how to build a community around the projects they work on.</comment></comment></comment>


Micro Frontends - <AUTHOR> https://martinfowler.com/articles/micro-frontends.html <comment><USER3> We do this, with a few hundred apps all loosely linked to each other, for many of the same benefits (and drawbacks!) as micro services.

Teams being able to own their stuff without needing permission from the rest of the org, being able to punt on some architectural decisions (since the blast radius is much smaller), being able to rewrite most apps in a pinch as need be (since they're small), much simpler tooling (off the shelf open source stuff work fine, without needing to scale it to hundreds of millions of LoC), and so on and so forth.

The same drawbacks apply: cross app changes can be tricky (if you find a security issue in a lib used by 150 apps, its not fun), lack of cascading pull request support in github is annoying, sharing actual business logic through libraries is often a bad idea (which is unintuitive to most).

Some challenges are FE specific: unlike micro-services, FE apps are in your customer's face. Being separate apps often means page refresh between apps if you want the full benefits of total separation, which in turn can be a perf issue (vs client side routing). The second is that unlike micro-services, people don't know about this kind of architecture, and every other new hire will wonder wtf you're doing.

Overall, if your product is more horizontal than vertical (tons of completely distinct features, vs a few very advanced features), it's great.

<comment><USER4> > sharing actual business logic through libraries is often a bad idea (which > is unintuitive to most).

Seems unintuitive to me too, would be curious to hear if you have more to say about it!

<comment><USER3> Imagine you have a React/Redux app with Rest endpoints. You have a dumb "Button" component. You share that with all the other apps. The Button is in React.

You now tie your entire ecosystem to React. Not having individual apps have to agree on dependencies is one of the benefits of micro apps, and you lost that. However, you only lost that for React, which many people agree is pretty darn good and not going anywhere. That's a tradeoff we take. Pure React components are also well encapsulated, so whatever the opinions are behind the Button doesn't pollute the apps. App owners are still free to architect their apps however they want: their only hard requirement is React.

Now, imagine you have a Medium style text editor built with React, Redux, and rest endpoints, complete with automatic draft save, a working publish button, onboarding experience, etc. If you share that, now all your apps have to agree on: backend, authentication, I18n, Redux, state management architecture, it probably uses local storage and cookies, is opinionated on what you do when logged out, and so on and so forth.

If you bring that editor in an app, you're now tied to all of this. If 100 apps use that editor, and they want to upgrade Redux in the editor, they all have to upgrade to get back to the same version. If you change the backend, you have to also upgrade all apps or keep the old endpoint forever. If you want to add an I18n language, you will have to rebuild/redeploy everything. If you don't encapsulate your state, its architecture will pollute the app, but if you do you're likely going to have a much more bloated library (more bytes, slower download). Apps are no longer free to make their own decisions.

It gets worse if you have transitive dependencies. Your app depends on A that depends on B that depends on C. Your app also depends on C. C releases a new version that your app wants. You now need to either bundle two versions of C, or upgrade the world. If C has global side effects, bundling 2 versions of C might not even be possible at all.

These kind of "full stack components" are tech debt the moment they hit your apps.

As the other reply to your post stated: you end up with the worse of both worlds. All the costs of micro-apps, with all the costs of a coupled monolith TOO. Its much worse than if you had picked either one or the other.

<comment><USER5> I'm confused. You say "business logic", but mention a "dumb button" which is the exact opposite of business logic.

Business logic would be the logical code to determine if a user is up to date on their payments. This logic is the same whether it is being used on desktop or android front end, in a back end job or API. And if this changes, it would change in all places simultaneously.

A button is technology specific component and should be shared with caution as technology requirements differ and change. The "up to date on payments" logic is inherent to your business. This is business logic and absolutely should be shared.

<comment><USER3> The button was the example of something that is okay to share because its not business logic.

</comment></comment></comment></comment></comment><comment><USER6> While I can see some benefits in terms of deployment flexibility, this really seems like a case of prioritizing your organizational chart over the end user experience. Its already hard enough to optimize a large JavaScript SPA so that it runs well on mobile devices - are we really suggesting that its a good idea to ship a UI to users device containing N different versions of React, Angular, Redux etc. all built using different build tools/pipelines with the final UI cobbled together and have it give a comparable experience to a native application?

Micro services work on the backend because the its effectively hidden from the user - thier device hits and endpoint and gets a response. On the frontend its a different story, the users device has to download and execute all that duplicated code.

<comment><USER3> > this really seems like a case of prioritizing your organizational chart over > the end user experience

No. It's case of being able to give the user more things they want, with each individual ones being built faster and optimized for their specific tasks without having to worry about the others. This comes at the cost of optimization of the whole (local maxima vs global maxima.).

If your product is something like, let say, Slack (one specific app that does one thing with a lot of features), it's a horrible fit.

If your product is something more like G Suite (several completely distinct apps that are semi related under an umbrella), that is where it shines. Other situations are things like internal apps where being able to DO something (at low cost) is often the priority.

There's a lot of ways to mitigate the UX impact, but yes, it has a UX impact. Its a tradeoff. Let's not forget that if you free your org of some burdens, they end up with more time to solve other problems, so it's not completely at the expense of the user.

<comment><USER7> There will be almost no UX impact if the decision on what defines each microfrontend is UX-driven. For example, feed and stories in Instagram-like webapp can be microfrontends - UX defines the structure of the container app and UI integrations, but then they can evolve independently.

<comment><USER6> There will almost certainly be a UX impact in the form of performance though - the whole point of micro-frontends as I can see it is that it allows you to have different infra&dependencies in different parts of the UI. The only reason you'd want to do this is because you don't want to share the same infra&dependencies across the UI which inevitably leads to duplication of frontend infra.

e.g. if my whole app is React based, why do I need micro-frontends?, using them seems needlessly complex. It only seems relevant if for example I have a product where team A has a legacy jquery UI, team B wants to add a part of the UI built in Vue, and team C wants to build out some features using React - <USER2> in that case the user is now having to download 3x the JS infra code that they did before because none of the teams can agree on a shared stack.

Also this pattern would seem to make composability of the UI much more rigid and inflexible. In the IG example you mentioned, lets say stories and feed got built out using separate stacks with separate codebases and infra. Now lets say we want to add a saved stories unit to the profile page, or add some recent stories as a new unit in feed (real examples - I used to work at IG :)) If we were on a common stack like React, I could just re-use the React story reel component from the stories tray and drop it into the Profile page (& maybe tweak a few props). With a micro-frontend, I'd have to create a content area for the other team to put thier story unit, agree on what the expected interactions between the profile & story unit were going to be, agree on a contract etc. wait for the other team to adapt the story reel so it was usable in the new context, make sure they deploy the new version of thier story unit...

The only situation I can see a micro-frontend being beneficial is as a stopgap pattern while migrating legacy apps - it certainly doesn't seem like an ideal end-state to me.

<comment><USER7> I agree with you that the use case with different stacks is suboptimal and may make sense only in enterprise apps. For consumer apps the impact is indeed too high.

However, just like with microservices the main point is not about having different technology, but about having different lifecycle and deferring the component integration to deployment or even runtime.

</comment></comment></comment></comment></comment><comment><USER8> My previous job was doing microservices for frontend and current job is doing monorepos. I prefer monorepo for frontend because:

      * Full page refresh between frontend services
      * Inconsistency between services.
        Sometimes services use different major versions
        between @company/footer @company/header components
        that is extremely ugly when navigating
      * Sharing data between services is hard.
        How can I update profile photo in header from my page?
        I saw iframe injection hacks to go around it!!
      * A single page can have multiple team owners,
        those things can get tricky fast
      * Monorepo is easier to make tooling for.

<comment><USER9> _> My previous job was doing microservices for frontend and current job is doing monorepos. I prefer monorepo for frontend because:_

I think you're misusing the term "monorepo", no? Monorepo is just a technique for organizing source control repositories. It's possible to have microservices AND monorepos.

You're probably thinking of "monolith".

[https://en.wikipedia.org/wiki/Monorepo](https://en.wikipedia.org/wiki/Monorepo)

<comment><USER10> While I agree with your analysis, do we have a good word for lots of little repos?

ie microservices : monolith and ?? : monorepo

<comment><USER9> "Multirepo" is the term I see the most

<comment><USER10> Thanks! I saw 'polyrepo' too, but multirepo sounds more intuitive.

<comment><USER11> 'submodules' too, but which further implies a) git; b) there's a (CD/infrastructure?) repo which collates the pieces.

</comment></comment></comment></comment></comment></comment><comment><USER12> There is no description on how micro frontends can be structured in practice. The run down in the marketing section is feels like a sales talk. No serious mentions of downside. Pretty blunt article hosted on martin fowlers domain.

What I would expect is an analysis of strategies to assemble micro fronteds.

<comment><USER13> I agree. There is no coherent analysis of how to actually enable this, and what the real pros and cons are. The article also assumes that you have the same order of frontends and services, which is a weak assumption, and that branding, style and design coherency are not important parts of a frontend experience, which is even weaker. This is an incredibly lame argument for any system. I expect a whole lot better from Fowler's blog

<comment><USER14> I think this is premature. They're starting with the 100,000 foot overview of why micro-frontends can be valuable. More installments in the series will dig into the details.

</comment></comment></comment><comment><USER15> I find this stuff to be utterly overkill unless you are building the next Bloomberg terminal (say) and have completely separate teams. Or you have more than say 100 frontend coders working on the same codebase.

If you think you need micro services you are unlikely to need a micro frontend for another order of magnitude of scale. The people talking about both of these things never seem to point out the downsides and huge delivery overheads to these approaches. Much better to make sure you are doing everything perfectly on a single codebase before you take high risk, difficult to manage decisions because you read how cool it was on Martin Fowler's blog.

<comment><USER16> Not to mention that you get many of the supposed benefits of "micro frontends" by just applying good engineering practices to a monolith. You can easily have independent teams and incremental changes by splitting your application into mostly independent packages without having them live in their own applications.

<comment><USER15> Exactly, Bounded Contexts is usually more than enough if you are reviewing the code properly.

</comment></comment></comment><comment><USER17> Amazon has been doing this for years, and Facebook does it too. There is one team that provides the overall "boxes" but then each team writes their own frontend for their own part of the box (and their own micro service behind it too).

I'm glad to see it getting more traction, but just like microservices, it's not for everyone. You need to be at some minimum scale for this to make sense, because just like microservices, there will be an engineering overhead for managing it.

<comment><USER18> Are those considered successful examples? I would argue both of those sites are a mess. You can't say they're not money makers though.

<comment><USER19> Well, what's your success metric? I'd argue that neither of them would have been able to implement the rich features they have at the speed and scale they've achieved - features that have given them market domination.

If pure aesthetics is your metric, then yeah, they're ugly. So?

<comment><USER20> Amazon's M.O. is "pay money, get physical item". On the scale of how much aesthetics matters on a website, that's way over on the "not at all" side. About the only thing I'd put further that direction is Craigslist (which is "maybe pay no money, maybe get physical item").

For nearly every other website, aesthetics is of significant or even primary concern. When I'm not receiving packages from it, I care about how it looks. Facebook, Google, and StackOverflow were all much cleaner designs than what they replaced, and Wikipedia is perhaps the biggest and most aesthetically consistent website there is. Aesthetics matter.

<comment><USER3> Does Amazon do micro apps on their storefront side? I know they do on the AWS side, but the ecommerce bit is very different.

<comment><USER21> Yes. For example, the ratings (stars) and reviews are separate "widgets" in the product page. Search, of course.

      - https://thenewstack.io/led-amazon-microservices-architecture/

</comment></comment></comment></comment></comment></comment><comment><USER22> Complexity arises in software at the interfaces of systems. Putting a bunch of small apps into a larger container doesn't address the elephant in the room of how to make these pieces work well with one another.

It doesn't matter that they aren't in the same repo, the minute one part of the app expects another to behave in a certain way there is a dependency regardless if that is expressed in code or not.

<comment><USER23> I think this is spot on. The problem lies in the incompatible interfaces.

I've been studying category theory recently and it is amazing how well things compose when interfaces follow monoidal / monad design patterns. They are so generalized that they can be used in so many different places. Unfortunately it is so rarely used outside of more academic environments.

If libraries/frameworks were structured to follow these kind of well defined "interfaces" I think we would have a very different experience than the one we have now.

<comment><USER24> Such monad interfaces are best enforced by language / compiler, however it is non-tractable to do that. Even in Haskell they just move the monoid check to programmer (especially associativity). What is worse, if the law is violated in some tiny subset of the data, that can lead to non-trivial bug. That is why it is difficult to apply in real world, which is usually very complicated :-(

</comment></comment></comment><comment><USER25> This really only works if you have at least one team dedicated to maintaining cohesiveness in design patterns across all the 'micro frontends'(i.e., one of those verboten 'horizontals').

Otherwise you are going to end up with a ux experience or even a _UI_ experience that diverges from app to app as each team designs and implements its own solution to common problems

<comment><USER3> The rise of design systems, and how its pretty much a must these days regardless of your architecture, kinds of takes care of that. It does mean one of the "micro services challenges", code sharing, hits you from day 1. If one app wants to use Angular and another wants to use React, you now need two implementations of your design system from the get go, and that's likely to be your biggest, most complicated and most expensive to maintain library.

So you usually want to make a tradeoff right out of the gate and standardize the core stack around a specific core set of UI libraries/frameworks. It takes away from the benefits a little, but its worth it. If you grow to ultra large scale you can have multiple implementations (which I think many of the big techs do), but for most its a bad idea.

<comment><USER25> In theory, yeah, but in practice the problem stems from product initiatives for new features that span those micro-front ends.

Each team responsible for a particular front-end gets a set of stories: 'implement feature x so that the user can blah blah'. This feature requires using a design pattern that is not part of the core set.

Each team, because of the silo'd nature of the article's model, _must_ therefore implment it's own version of that pattern, each subtly or grossly different from the other, et voila, you have inconsistency across what to the user is supoosed to be a cohesive app.

Sure, there are solutions for this, one of which is common ownership of that design system and having some kind of product coordination that allows for the contribution of new patterns to the design system in advance of the new feature, but that does require a lot of care in planning and coordination that negates a lot of the benefits of the this sort of model, imo.

<comment><USER3> Its not easy by any mean, but few things worth doing are. We have a team of engineers and designers working together to maintain our design system and its implementation, and all teams use it. When a new shared pattern comes up, its implemented in the design system and people use it. Teams are heavily encouraged to not make new patterns on their own from scratch (and its a lot easier to have the design system team handle it anyway). Sometimes folks go rogue, but that would happen within a large monolith too anyway.

<comment><USER25> > Its not easy by any mean, but few things worth doing are. We have a team of > engineers and designers working together to maintain our design system and > its implementation

That would be a horizontal team which this model does not account for.

<comment><USER26> In fact, it specifically recommends avoiding that, which is why I think this article falls short.

<comment><USER3> I can't read the mind of the article's author, but usually in these types of articles about micro-whatever you want to stress how horizontal teams/libraries/ownership is to be avoided, because people "default" to having them, and you have to fight tooth and nail to make them understand it shouldn't be.

But for micro-FEs, there's a few things that, IMO, are unavoidable. A design system implementation (keeping its components as "dumb" as possible, no server api dependencies of any kind, no opinion about frameworks beyond the component technology it uses) is one of them. A few very very core things like authentication is another, as well as how all the routes glue together. There's a few more (nav, service workers, etc).

It should still be avoided unless absolutely impossible to avoid or if the benefits are overwhelming.

</comment></comment></comment></comment></comment></comment></comment><comment><USER27> I see that many people are asking for examples.

Zalando is doing this for couple of years now, you can look at their talk [1] where they describe how they use this pattern + some open source libs for composing those UI components [2]

Many other components of this kind of infrastructure are described and linked here [3]

[1] [https://www.youtube.com/watch?v=m32EdvitXy4](https://www.youtube.com/watch?v=m32EdvitXy4)

[2] [https://github.com/zalando/tailor](https://github.com/zalando/tailor)

[3] [https://www.mosaic9.org/](https://www.mosaic9.org/)

Also this [https://jobs.zalando.com/tech/blog/front-end-micro- services/...](https://jobs.zalando.com/tech/blog/front-end-micro- services/?gh_src=4n3gxh1)

</comment><comment><USER28> Not a big fan of solving an organizational issue (how several people can work together on a same project) with a technical solution that adds more complexity and has its own drawbacks (splitting a project into micro services).

Last time I heard in real life about splitting a frontend app into micro services, it was because the team was composed at 80% of junior devs who didn't have a correct git workflow. And they were spending hours fixing git conflicts. "It doesn't work, it will never scale when the team will grow, we should split the app in smaller apps so nobody will work at the same time on the same project".

<comment><USER3> Thats kind of like saying we shouldn't have tests and type systems because people should just learn to code properly.

<comment><USER29> No, because git is unnecassarilly complex

</comment></comment></comment><comment><USER30> The fundamental problem is cleanly persisting data.

There's all sorts of design paradigms we use to attempt to send state through the presentation layer to the persistence layer.

Ultimately there's no clean way to do it and because of that it's hard to have something like a micro frontend. The presentation layer is always aware of the data persistence layer to some degree.

Take a physical light switch. The switch will still work if the power is out; it goes up and down. The same doesn't have to be true from a purely digital standpoint. If the power is out, we can actually disable the switch(assuming this digital display switch is powered by a battery in this case).

So in the digital switch case, the switch accurately reflects the global state of power. In the analog switch case, the switch still functions regardless of the global state of power.

In the digital case, one must write code that actually checks the global power state to conditionally enable the on/off functionality of the digital switch. So that code, is not strictly presentation layer code, rather it's state- maintenance code or I don't know what you'd call it. Point is, you now have the presentation layer now tightly coupled to the something outside of the presentation layer; in this case, the global state of power("is the electricity working?").

And this is just a simple example of an on/off switch.

Micro frontends are a difficult problem. One solution might be to have all frontends be signal based. So if you send a signal a listener can optionally handle it or not or maybe nothing is listening. In the analog on/off switch case, that's exactly how it works. If the power is off, the switch still flips.

<comment><USER31> I think that's part of the problem, but only a part of the problem.

One of the things I think we're slowly groping towards is the importance of composability in all sorts of programs. The problem is, where we'd like to write "app1 <> app2" and have the result be something sensible (as in monoidal composition in something like Haskell), the problem is that we don't have a well defined definition of "composing" two applications together when those applications each have their own page layout, HTML widgets, style sheet, data persistence, user authentication model, user authorization model, server communication methods, URL scheme, configuration information, and who knows what else I'm forgetting.

I was reminded of something like this today as I'm sitting here slicing an application up into bits, and I realized I was basically implementing a composition system for the bits of my app, but the composition of "a thing that has some HTTP handlers, and some data types, and some methods, and some logging code, and some services that it runs all the time, and an API" is really ugly. You have to go out of your way today to structure things that way, because everything is fighting you by forcing you to compose different things in different ways, and encouraging you in a million subtle ways to do something that will add a little spiky bit to your code that will make it impossible to compose.

Consider just the HTTP handler. How many "routers" out there make it easy to encapsulate a particular sub-application on a particular URL fragment like "/myforum", and then _all_ you have to do to move the application to a different URL is simply route it to something different like "/public/myforum", and no other changes have to be made? The ones I know that allow that don't particularly encourage it, and there's plenty for which it's all but impossible. It doesn't take many things that can't be composed very well to make composition difficult, and very few things in programming make composition easy right now.

<comment><USER23> I've had similar thoughts after learning category theory. I'm trying to develop a conceptual model where each different category (JSX, data layer, data fetching, validation, 2-way binding) cleanly composes.

With arcane nature of category theory not being common knowledge, frameworks, libraries, standards, etc, are unfortunately being created in ways that actually prevent patterns of composition.

It's almost to the point that I'm wanting to reinvent things from the ground up based on solid patterns of composition.

Have you done any work or discovered any patterns to make things behave more like the monoidal "<>" that you mentioned?

<comment><USER31> "Have you done any work or discovered any patterns to make things behave more like the monoidal "<>" that you mentioned?"

Only a lot of hard work, honestly.

In the case of the HTTP router case, I think it's important to pass the URL being used to access the resource cleanly down to the resource, but it's still up to the resource to then use relative URLs properly, which is an uphill battle.

</comment></comment></comment></comment><comment><USER32> Frontend-development in JS/TS is already complex enough. I can't figure out why you'd want to split up an application into "micro-applications" and provide a worse end-user experience with multiple SPA loads.

When will this madness end? Sure, if you're developing an absolutely massive system with dozens (hundreds?) of developers, I can see the potential benefits outweighing the downsides to this approach. But the fact is most frontend applications do not fit into this category (much like microservices - I've written plenty and never had to scale one beyond a single node.)

<comment><USER3> Unless you plan to have a 2-10+ apps to developer ratio, at least 50+ apps in the medium term, and looking into a future of 50-100+ devs at least, I wouldn't do this.

Exception: if your apps are very very distinct anyway. One company I worked at long ago where we did this, we were small, but the "screens" of our apps were very unrelated (no one really used more than 1-2 of them as part of their job), so it was very easy to split them up with zero impact on users.

</comment></comment><comment><USER33> There is also the plugin pattern. A small core, with a bunch of independent plugins that interact with the core via events sent out by the core, and calling the public methods of the core. Where it's very important that the independent parts don't talk to each other.

</comment><comment><USER34> We're doing this exact thing. Our micro front ends are React components (most of them are actually now using hooks!). Our 2 deployed UIs are angular (1!!!) apps. We use react2angular to slowly replace the angular app. The angular components are all Java backed using a poorly maintained swagger set up (and the swagger definitions don't match the actual services :( ). The new backend is all Graphql on top of typegraphql. The nice thing about typegraphq is how easily it converts our models into usable rest services, and allows us to create field resolvers, that basically extend other types and let us pull down additional concepts. Basically we let the front end then choose what it wants to pull down. It's very flexible, self documenting, and reduces the amount of boiler plate we had in in the Java layer a ton. One set of model objects (typeorm) that also have typegraphql decorators. Compared to Java that has models, swagger objects, converters (both ways)... Life before was literally a nitemare.

</comment><comment><USER35> Is this the equivalent of a portal and multiple "portlets" ? The main SPA is just a shell that holds everything together but the individual portlets build their own SPA ui backed by their own one or more services . Perhaps this gives the "portlets" spa owners to build and release on their own. Is there any React framework which lets you design in this manner ?

<comment><USER36> No, it's about splitting up web apps based on uris and loading different ui's for different uri. Thus page refreshes.

</comment></comment><comment><USER37> I appreciate the trend to break the frontend monolith - I think its one of the next steps for grand scale web apps. However, that noted this is certainly not for everyone and it has some downsides (e.g., complexity) that need to be tackled.

Right now there is also some lack on tooling and framework / library side. Nevertheless, there are some approaches already.

A project currently in the making is Piral ([https://piral.io](https://piral.io)). It is not production ready at this point, but I think it may hit some sweep spot depending on your requirements (see [https://github.com/smapiot/piral/blob/master/docs/features.m...](https://github.com/smapiot/piral/blob/master/docs/features.md) for features and comparison to other / similar frameworks for micro frontends).

Disclaimer: I'm one of the authors.

</comment><comment><USER38> The best microframework solution I've seen so far is the Single-SPA [1] meta framework:

[1] [https://github.com/CanopyTax/single- spa/blob/master/README.m...](https://github.com/CanopyTax/single- spa/blob/master/README.md)

</comment><comment><USER39> Norway's largest classified ads company, [https://finn.no](https://finn.no), has created and open sourced their micro frontend framework:

[https://podium-lib.io/](https://podium-lib.io/)

</comment><comment><USER23> I'd be curious to hear stories of how people are integrating multiple different frameworks and build processes together. The article doesn't mention any details in that regard.

Anyone have experience with combining legacy Angular 1.x and modern React? My current work involves porting from Angular to React and we try to style each app to look consistent and just link back and forth between 2 apps depending on the feature. It has a lot of issues like the long reload times and having to fetch data from the API's again. It would be nice if styling and some of the code could be shared between the apps.

Anyone have some use cases or insights they can share in this regard?

<comment><USER40> You could fetch and cache data into local storage to prevent re-fetching. Depending on how you are set up you could have both apps loaded at once and display one or the other (perhaps lazily loafing the one you don't need upfront)

<comment><USER23> We are doing this for simple data where we can but unfortunately having state in multiple locations (backend, memory, localStorage) means lots of cache complexity. How do you refresh and invalidate when the data are in so many places? We've opted to keep data in only 1 place as much as possible due to this exponential complexity.

We also have to be careful what we store in localStorage since it is relatively insecure.

</comment></comment></comment><comment><USER41> Let me repeat myself: [https://news.ycombinator.com/item?id=18627950](https://news.ycombinator.com/item?id=18627950)

So, are "portlets" coming back? Why should they work this time?

</comment><comment><USER42> Micro services that serve HTML content. No new architectural structures required.

</comment><comment><USER43> I feel like he is flogging dead horse here. There are scenarios where microservices make sense, for a large majority of problems, they don't and is harmful as they get companies into managing infrastructure that they have zero experiences, so you have this places that are developing stuff that is totally not appropriate for them.

I like things that are simpler and unless the problem is a natural fit for microservices, I would not use them and consider them harmful.

I do respect Mr. Fowler to clarify but just start where he says microservices exploded in popularity, he lost me there.

<comment><USER44> He's not talking about microservices in the article. He's likening micro frontends (SPA more or less) to microservices because there are some analogues between the two concepts.

</comment></comment><comment><USER45> I've spent more than enough of my life now trying to clean up the messes created by people following Martin Fowler's ideas. It correlates perfectly with my desire to leave the industry.

<comment><USER46> Cargo cult and reinventing state of the art snake oil all 5 years...

What are you plans for escaping the madness?

<comment><USER45> Unsure currently.

</comment></comment></comment><comment><USER18> So lets say you have a team that handles user on-boarding and account management. If you want a top bar with the user name, does this feature have to be owned by the user account team? If they're different teams with different microfrontends, how does the top bar frontend know to update based on activity in the account management frontend?

Basically, cross vertical information will exist, how do you solve the caching problems? Maybe some kind of app wide message passing?

<comment><USER47> If you are using react/redux it would be a rather trivial matter of defining an action/state tree contract between the teams. Other frameworks that use encapsulated state may have to resort to a message bus.

Edit: I misunderstood the context. If your front ends are separate applications this won't work.

<comment><USER3> Having that kind of tight coupling (not only interfaces, but also libraries beyond the minimum you need for core things like the design system) partly defeats the purpose. If you have a lot of micro apps and they share dependencies/frameworks, you won't get the benefits of eventual consistency when the next big thing comes along.

For something like onboarding, any team handling that will either just be a "think tank" (PMs/Designers working with the actual owners of the individual affected apps to build the experience), or will be people who jump in other folks' code bases to implement it. Alternatively, they could only be responsible for building a suite of components that the app owners bring in their apps to glue things together.

</comment></comment></comment><comment><USER48> It's disappointing that the article lacks any actual examples of how this might be achieved.

Take web apps for example - I imagine each micro-frontend loading in an iframe, which feels kind of icky. Alternatively, maybe you could build out a plugin architecture, where each micro-frontend is loaded as a plugin into the host.

What other approaches can be used, while keeping the "feel" of a single, cohesive app?

</comment><comment><USER49> We do this for our app already, right now the biggest issue is switching between pages causing the application to reload. I'm curious to see if anyone has a good solution for a problem like this, each of our apps are written in Angular.

<comment><USER3> We find that carefully picking app boundary is a big deal to reduce that pain. Also, performance has to be a first class citizen in your org. Since users will be page refreshing a lot, you can't tolerate 5 second load times. With that said, we find that techies care a lot more about fancy client side routing and not having page transitions than users do.

There are a few places where its critical though (places where users go back and forth hundreds of times a day), and the routes are too big to keep as a single app while keeping the benefits of our architecture. For that, having separate builds, each generating their own final scripts, but dumping them on the same page is a decent compromise. You don't get all the benefits (you will have a single page, so dependencies have to be compatible and play well with each other. One script can cause another to break, etc), but the user doesn't pay the price.

Thats a last resort, but sometimes it has to be done.

</comment></comment><comment><USER50> You can use single-spa to do this while still having a "spa" and not using iframes.

[https://github.com/CanopyTax/single-spa](https://github.com/CanopyTax/single- spa)

Disclaimer: I work at CanopyTax

</comment><comment><USER51> InnoQ coined the term "self-contained systems"[1], which seems to be related.

[1]: [https://scs-architecture.org/](https://scs-architecture.org/)

</comment><comment><USER52> It could just be a side effect of the more focused nature of the front end web sites - the more you focus on the content, the more you feel the less you feel the need for it.

</comment><comment><USER53> Spend a few moments within the Playstation network "site"(s) and this would be the best example of many front end independent services going horribly wrong.

</comment><comment><USER54> I wonder if multiple focused software products would negate the need to have independent front end teams improve and maintain a single giant product?

</comment><comment><USER55> The biggest challenge with this approach is how you handle 'user context' and how the different front-ends manage that dependency.

<comment><USER56> In React, a UserProvider at the top of DOM tree plus withUser HOCs wrapping your components should work.

</comment></comment><comment><USER57> The result of this architectural pattern:

[https://vimeo.com/166807261](https://vimeo.com/166807261)

</comment><comment><USER58> Isn't this similar to what Spotify does?

<comment><USER59> I don't think they do this anymore. Or at least not like they did around ~2015 with iframes

</comment></comment><comment><USER60> Reminds me of Zenga, at a certain point of scale, your whole organization will feel like you are playing one.

</comment><comment><USER61> I would think polymer/ web components is perfect for micro services.

Is anyone using that?

</comment><comment><USER62> So, they learned about WSGI middleware?

</comment><comment><USER63> all the disadvantages of microservices carries to micro frontends :D

</comment><comment><USER64> On Android, this pattern is achievable by breaking your UI into modules. And then by using Dagger multibinding to bind those modules together:

[https://dagger.dev/multibindings.html](https://dagger.dev/multibindings.html)</comment>


Ask HN: Classify relatedness between a query and a document - <AUTHOR> Hi there! I am looking forward to build a classifier for the field of Information Retrieval! The purpose of the classifier is to identify whether a query is related or not to a document. The document in here can be viewed as an article aka 'big huge text'.
I am here asking for ideas in many fields:
1. Do you know any work done previously in identifying the relatedness of a claim worth mentioning? 2. Do you know any datasets that I could use to train my model? maybe a similar Kaggle competition?
Thanks in advance! <comment><USER2> The industry standard tool is probably Apache Lucene [1]. It uses a well documented mechanism and is open source so it would make a good place to start research.

Good luck.

[1]: [https://en.wikipedia.org/wiki/Apache_Lucene](https://en.wikipedia.org/wiki/Apache_Lucene)

<comment><AUTHOR> Thanks, but Apache Lucene is a search engine. I want to build a relatedness classifier

<comment><USER3> The mainstream of IR research has deliberately avoided the development of a "relatedness classifier" in the sense of a system that produces a probability score that a document is relevant. The TREC organizers have been mostly interested in "get good recall" and less interested in P@1 or rewarding the kid who sticks his hand up really high when it's an easy question and knows the answer.

You can tune up a conventional IR function with these kind of methods

[http://scikit-learn.org/stable/modules/calibration.html](http://scikit- learn.org/stable/modules/calibration.html)

with the data that TREC publishes. The results are a little disappointing because the system will probably never predict more than a 70% probability of relevance.

I am interested in the promise of "Siamese networks" for learning relatedness, see

[https://www.cs.cmu.edu/~rsalakhu/papers/oneshot1.pdf](https://www.cs.cmu.edu/~rsalakhu/papers/oneshot1.pdf)

for example. For document-document matching I think this approach would be great (and supportive of relevance feedback, something that mainstream IR algorithms have never done that well at) Query-document matching may require something similar but different, since there is an asymmetry between queries (short) and documents (long.)

Click on my HN profile link and we can talk more. Thanks!

<comment><AUTHOR> Thank you for such a detailed answer! I'll get in touch you tomorrow then, for sure :)</comment></comment></comment></comment>


We aren't worried enough about the next pandemic. Here's why we should be - <AUTHOR> https://80000hours.org/2017/08/podcast-we-are-not-worried-enough-about-the-next-pandemi/ <comment><USER2> Nit: that title could use some work</comment>


Trump, our next president, promised to block AT&T/Time Warner merger - <AUTHOR> http://arstechnica.com/tech-policy/2016/11/president-trump-may-be-trouble-for-atttime-warner-merger-and-comcast/ <comment><USER3> > "Comcast's purchase of NBC concentrated far too much power in one massive > entity that is trying to tell the voters what to think and what to do," > Trump said. "Deals like this destroy democracy and we'll look at breaking > that deal up and other deals like that. That should never, ever have been > approved in the first place, they're trying to poison the mind of the > American voter."

My prognostication is that when they "look at" stopping it (if they do) they will find what everyone who has worked in the world he's entering found out long ago: it's only possible through strong regulation. Fine, he'll think: I'll just embolden the regulators. This, I think, will be when the people who elected him will start to realize how business is done and that, just like in their private lives, they've bought into yet another CEO's fanciful promises that once again turned out to be self-serving in their entirety.

<comment><USER4> Either that, or he'll just break his promise and let it go through.

<comment><USER5> Bingo. Promises, for Trump, are fulfilled upon announcement, and then forgotten. The examples are legion.

<comment><USER6> Honestly what else is new? I voted for Obama on pledges he'd end the war in Iraq and close down the constitutional abomination that is Guantanamo. 8 years later and here we are.

<comment><USER7> " I voted for Obama on pledges he'd end the war in Iraq and close down the constitutional abomination that is Guantanamo. 8 years later and here we are."

Obama earnestly tried to close Guantanimo.

He's a lawyer, and should have known better.

Guantanimo is a geostrategic issue - that only 'looks like' a Constitutional problem.

The problem is there are some very, very bad people in Guantanimo - <USER2> putting them through the American justice system would not work. Obama figured this out.

Paradox:

1) US Servicement are subject to a different legal system than Americans - harsher in many ways - but Dems wanted to put terrorist on US soil, subjecting them to regular courts - it would have been a farce.

2) US Soldiers are not the FBI. They don't do fingerprints. The kinds of evidence/investigation required to convict someone in US courts (meant for citizens) ... the defense attorneys could have easily kicked out the cases against the terrorists.

3) Many of these terrorists were caught on the battlefield. They could have been killed there - and none would have been the wiser. A young Canadian, was caught attacking US servicemen - and killed a medic. He was shot in combat, and was dying. US Special Forces arrived and medivaced and then applied super USA field medical technology to save this 'terrorist'. Then he was held at Guantanimo - in a really odd legal situation.

He was just a kid, but many of these guys are really, really bad characters, caught on the battlefield.

They don't belong in the US justice system.

So they go to Guantanimo and stay in limbo.

If you ask me - many of them deserve it.

As for the 'regular combatants' \- that's too bad - I wish where were some way to reintegrate them, I think it happened with some.

Anyhow - the realities of the situation hit Obama - and the above issues are far to explain to Dems in a populist manner.

Obama orders people to die in drones strikes. Not so 'peace and love eh'? He does it because he has to, and he knows it.

Obama's 1st term was pretty good.

2cnd term, he didn't accomplish much, that said, he did not have the power.

<comment><USER8> > If you ask me - many of them deserve it.

The point of justice is to avoid further crimes by rendering the criminal harmless, and by making an example out of them to scare away other potential criminals. What does 'deserving it' have to do with this, and how is it applicable? Do you think prisons exist out of resentment toward people?

<comment><USER7> "The point of justice is to avoid further crimes by rendering the criminal harmless,"

No. Or rather - 'criminal justice' as we understand it in the civil sense, does not apply here.

" What does 'deserving it' have to do with this, and how is it applicable? Do you think prisons exist out of resentment toward people?"

Some of the people in Guantanimo are terrorists of the worst kind. The people that planned 9/11\. The kinds of people that chop off heads, who commit genocidal massacres, who grab little girls from families, rape them, and sell them into slavery.

Suppose one of these mass murdering criminals could be 're-integrated' into society, without much fuss, i.e. he sees the error of his ways, admits he was 'caught up in false jihad'. And we felt he could go back to a more stable part of Iraq and roughly go about his business? And we let him do that, and he pretty much behaved.

Would that be justice?

No.

99% of ex-Nazi SS-officers, after WW2, then one's that 'escaped' \- went on to live relatively normal lives in hiding. They were 'reformed' essentially, and posed no threat to anyone. Their murderous activity was really in the context of WW2. Does that mean we let people who put people in the gas chamber go free?

No - some people deserve to die - and sometimes worse.

There are some kinds of 'bad people' that are either 'not reformable' or who have committed such grievous crimes such that 'true justice' is probably impossible.

I'm not advocating anything other than saying I have absolutely no sympathy for some of the people in Guantanimo.

Now - there are definitely some people there who were just 'villagers with guns, fighting for their village/community' whatever - and are not totalitarian, ideological, terrorists etc. - and sometimes that's a fine line, but clearly they don't belong there.

The 'injustice' is not the existence of Guantanimo, but simply our failure to apply 'actual justice' meaning some 'partly innocent' people are tangled up in a system designed for truly the most nefarious and evil types.

When we caught high ranking Nazi SS officers after WW2, we sentenced most of them to death. I suggest many ISIS fighters are far, far worse than SS officers.

Go ahead and watch the YouTube executions of thousands of Iraqi soldiers by ISIS after they took parts of Iraq. They were executed by the river, the river was literally running red with blood. I don't think that 'reform' is an issue that enters into one's mind when thinking about how to apply justice in those scenarios.

I appreciate that by enlarge, criminal justice should be focused on 'reform' but especially in these kinds of situations, it's really quite another reality.

I was in the (Canadian) Army a long time ago, and it was a difficult moral issue, but death is part of the equation. Think of this paradox: someone who has a gun and running from police, shooting back occasionally - will probably get a 'death sentence' on the street and that we generally accept. To think that mass murdering, genocidal people get more than that is a little disturbing.

Anyhow - I hope that we get better at separating the 'villagers with guns' from the 'genocidal terrorists'.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> > _But Trump 's promise to block the merger won't necessarily be fulfilled._

Cop-out in the subtitle followed by thirty paragraphs of navel gazing.

<comment><USER10> My wife and I were discussing issues like this tonight. We spoke about the fact that when most politicians make promises, you can point to specific votes or speeches during non campaign times to say "Yes, it seems like he/she is really against this." With Trump though, we have no comparison, he's never served any office before. The only thing we have is campaign promises and they mean so little. So journalists probably have a hard time deciding whether something he said is true or not.

<comment><USER11> Maybe, and this is a radical thought, journalists (as opposed to pundits) should wait for actual facts to emerge before branding somebody one way or another?

<comment><USER12> I understand what you're saying. There is an aspect of "damned if you do, damned if you don't" here, though, I think. In waiting, they're open to accusations of not reporting or paying attention to a candidate, whether or not the accusation is fair.

<comment><USER11> It is perfectly possible to report on what Trump proposes and says and does without becoming a mind reader and fortune teller. You can - and actually very much should! - still report on his lies by giving facts disproving him, or mention e.g. scientific consensus or lack thereof questioning or substantiating his claims, or contrast the opinions Trump holds by also reporting on the opinions his opponents hold.

You can write opt-ed pieces and be a pundit for a while if you think your own opinion might interest your readers too.

But mixing reporting with fact-free punditry and a heap of general virtue signaling in the same article is just detrimental to ones journalistic reputation and will immediately alienate everybody outside of your own echo chamber.

You researched facts why Trump's immigration policies are bad? People stopped reading after the initial "Trump is such a racist!" paragraph.

You researched facts why Clinton's Libya policies backfired? People stopped reading after the initial "Hillary is so crooked!" paragraph.

<comment><USER12> Agreed.

</comment></comment></comment></comment></comment></comment><comment><USER13> He's all about removing regulations, and then wants to regulate this?

<comment><USER14> Could you explain your thoughts on how those two ideas are necessarily inconsistent with each other?

<comment><USER15> Well, one is removing a thing, and the other is adding the same thing. QED _inconsistent_.

<comment><USER11> You'll first have to prove your premise that he is all about removing regulations (no matter what regulations), because that assertion is hardly an axiom.

<comment><USER16> He said that if any new regulations are passed, 2 must be removed.

<comment><USER17> That's not counter to regulation - add a regulation about large company mergers, remove regulations on CO2 and NOx producers. Done.

</comment></comment></comment></comment></comment></comment><comment><USER18> I haven't followed this deal that closely - but I believe it had significant antitrust headwinds before Trump said anything. Generally, if ATT wants to buy anything thats large - I would be concerned about a decrease in competition.

</comment><comment><USER19> He... promised to do a lot of things.

<comment><USER20> Clinton didn't promise much, she didn't say much at all. She wouldn't have this problem.

</comment></comment><comment><USER21> I don't care about yet another stupid merger, its the net neutrality weakening that should concern everyone. In the end whether AT&Time is your ISP matters little if you only have one choice for ISP and they charge you to access Google special.

</comment><comment><USER22> Remember that the world is not black and white, and that there is always a silver lining.

</comment><comment><USER23> Haha, our.

</comment><comment> at-fates-hands I stopped reading Ars Technica when they gave Trump an F on technology issues and Clinton an overall B+, including a B- on "privacy and security". I mean, how much more partisan can you get than that? The woman was under investigation for leaking classified emails and using an unprotected email server for fucks sake.

When a media outlet does something like that, I just can't take anything else they report on seriously.

here's the article: [http://arstechnica.com/tech-policy/2016/03/when-graded- on-te...](http://arstechnica.com/tech-policy/2016/03/when-graded-on-tech- issues-2016-presidential-candidates-dont-do-well/)

<comment><USER24> Anything not-pro-clinton gets downvoted without explanation on any social media platform I've seen, including HN (which is supposed to be less biased, more objective, and superior to the other networks).

<comment> throwaway-hn123 Oh come on, do you still need to pretend to be a victim? Aren't those days over now?

<comment><USER24> I'm not even pro trump, it's just an observation of overt bias.

<comment><USER25> speaking of observations of overt bias, i've noticed that any time i question what i see as overt male chauvinism here i get downvoted without any explanation. i even got hellbanned once about it. this is only something i run into here, but the only other place i really comment is jezebel.

<comment><USER26> I've felt the same thing about the comments here. It has led me to stop trying to discuss any issues related to gender and avoid HN more on the whole.

<comment> nommm-nommm Slashdot is worse, I stopped reading it for the same reason. :(</comment></comment></comment></comment></comment></comment></comment>