A tale of webpage speed, or throwing away React - <AUTHOR> https://solovyov.net/blog/2020/a-tale-of-webpage-speed-or-throwing-away-react/ <comment><USER2> Most people here are criticizing the author for doing some dumb things. I concur, but still think they have a good point.

First, keep in mind that the author's use case is a content-heavy app with sprinkles of interactivity. This is _very_ important because it sets the "webpage speed" goalpost to a concrete place: they want good lighthouse/first load times and good SEO.

I've fallen into the same pit before. I've used Create React App with a custom server-renderer, Gatsby and Next in different projects. None of the solutions is truly satisfactory for the author's use case for a single very strong reason: React's hydration process is both blocking and slow. I hope that sooner rather than later React is able to offer a good solution for incremental hydration, but it seems quite far for now.

Once you realize this, the only way to keep using React is to step out of the mainstream and play with multiple render roots, parts of the page that never get hydrated and so on. It is _possible_ to do things here, but it is definitely a rocky path.

Of course, there are many wrong things the author explains that you can avoid, but I'll throw a bone to them here too. Most "wrong things to do" they explain are both wrong and understandable. And they openly accept it.

For instnace, one wrong thing to do that I've had to fight against a lot is JS-based device-specific rendering. It is so much easier to implement a "mobile ? <MobileScreen /> : <DesktopScreen />" than to make a single screen that adapts properly using CSS that it's not even funny. Unfortunately, it also breaks SSR, leads to janky page-loads and poor performance.

I fully agree that as of today and for content-heavy sites React pushes you towards a pit of despair instead of a pit of success. You _can_ make it work, but ... is it worth it?

<comment><USER3> It's just apples and oranges. _Web pages_ should never even consider using React. Maybe a bit of vanilla JS/jQuery here and there for whatever interactivity you need, and then server side rendering for the content. Building _web applications_ on the other hand, has been revolutionized by the use of React. I would never seriously consider any other UI rendering library right now because of the sheer volume of support and active development around it and its' ecosystem. And hand rolling vanilla JS in a large scale web application quickly becomes a maintainability nightmare. The alternative of doing things old school with server side templates is _ok_ , but it massively slows down your iteration speed through reliance on tight coupling between backend and frontend.

<comment><USER4> > The alternative of doing things old school with server side templates is ok, > but it massively slows down your iteration speed through reliance on tight > coupling between backend and frontend.

Huh? Something like Rails lets you iterate on server-side stuff extremely quickly. There is a _lot_ of functionality you can implement that doesn't need JS at all

<comment><USER5> Never developed in Rails - does it handle:

* composable templates

* reusable JS snippets

* hot reloading in your browser

And additionally, given that the topic is "building web applications", I can't really understand how you think you can build interactivity without JS. Are you proposing form-based updates or is your understanding of "application" different than GP and mine?

<comment><USER4> > * hot reloading in your browser

We recently added this "feature" to our react-on-rails codebase, and the only thing I can ask is... why?

Hot reloading on Unreal Engine is a hot mess with all sorts of little caveats to think about. Meanwhile I can hit F5 and as long as my browser is configured right I can guarantee there's no old cruft to deal with. Why in the world would I want to add that kind of uncertainty in my work codebase??

<comment><USER6> Whenever you're doing design or interactivity focused tasks, and actually in many cases debugging logic, hot reloading is not only a huge step function improvement, but a categorically different thing.

The analogy I like to make is this: imagine a painter had to wait 3 seconds for every stroke they made to show up. Would they be as good? Would they try out as many variations? Discover new paths they could go because they had the time to "test that weird idea real quick a few times"?

Hot reloading works especially well on React (and not I assume on game engines) because React, with hooks, used algebraic effects, which means all side effects are properly understood by the system and are undoable. So it's not as hacky at all as you'd imagine.

I never understood the hate for HMR as a concept. Perhaps your implementation wasn't great, but as a general concept it's literally a game changer.

The same people who cast shade on it seem to always embrace incremental compilation (like in Rust) for some reason, too.

<comment><USER4> I guess I can see it in that regard, and knowing the implementation of it is complete and robust helps a lot. And I can see how this is useful for interface design; most of the good IDE gui toolkits of the past preview live as well.

But I also think this lessens the requirement for a solid mind's eye and ability to visualize changes before you make them. Having come from desktop development (with "live" gui development kits like VB) into webdev I guess I got used to code-a-bunch-of-stuff-and-hit-reload pattern.

As long as it doesn't get in my way, I'm cool with it.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> The initial motivation for intercooler.js (which the author forked) was performance. I was working on a large bulk table update and building the table dynamically in javascript. The performance was terrible (this was back in 2012, no idea what it would be like today).

I realized that I could just deliver and slam HTML into the DOM and that the browser engine, written in C, was very fast at rendering it.

That turned into a pretty big javascript function, which then turned into intercooler, which then turned into htmx:

[https://htmx.org](https://htmx.org)

<comment><USER8> I could definitely see something like intercooler boosting productivity. My only concern (possibly unfounded) is that you end up designing all of your server side endpoints specifically in an intercooler fashion. All of your endpoints must now return an html snippet, which is specific to the design of the page. So you have a lot of page specific endpoints. This is in contrast to a REST api where the api can be designed largely independently of any one use case.

If you ever need to switch away from intercooler you are going to have a large undertaking not just on the front end, but now on the back end as well.

But I might be missing something.

<comment><USER9> If you don't need a rest API, all it does is make everything far more complicated, i.e. every page now has two end-points, one for the html, one for the data.

It's trivial in most web frameworks to have an endpoint respond in two ways, one with all the html including head, menus, footers, etc. if you hit it with a GET, the other just the snippet if you hit it with an Ajax request.

A REST API is basically a massive over-complication unless you actually need it for a good reason, say you're running both a web app and a mobile app from it.

I've used this technique occasionally for over a decade and personally have always found this server-side approach very simple compared to juggling REST APIs with client-side rendering when a client or an existing code base demanded it.

I've also always found the defence 'you might need to switch' to be a flimsy one. Usually when you do need to switch, everything is so different even your 'future-proof' API design needs a massive overhaul too because you made assumptions you didn't even realize you were making.

Think of all those SOAP or XML APIs that were future proof...

<comment><USER8> Fair points. A couple of notes though - intercooler needs two endpoints as well. One for the page, and another for any dynamic HTML.

I mean I switched from jQuery to knockoutjs to react all on one application and the API served all those transitions well. So I'm speaking from personal experience here. But that is anecdotal and maybe it's not typical.

<comment><USER7> One pattern that I have used with some success is to reuse end points and use metadata that comes up with intercooler or htmx requests to determine the structure of the output.

For example, if I have search functionality at

/search

and I'm implementing the active search pattern shown here:

[https://htmx.org/examples/active-search/](https://htmx.org/examples/active- search/)

I'll re-use the /search url for the partial search results and check the HX- Request header to determine if I want to render the entire search UI or just the search results.

If you use hx-push-url as well, you can get a search dialog that acts like an active search for the user, but also retains copy-and-paste-able URLs

</comment></comment></comment></comment></comment><comment><USER10> This is the typical "we didn't spend any time thinking about our architecture therefore we're going to blame our framework" article.

React is a great choice for certain use-cases, but when low-quality developers are allowed to pick it up and apply it to everything you end up in a mess. The same thing happens with literally any tool.

If you want speedy initial interaction times and manageable codebases, (and requirement X) use the right tools for the job, and instil better, thoughtful, development culture.

<comment><USER11> In general, these posts sound a bit like this: I tried jQuery, and after a while it all became a mess; took up a Backbone project, and was good for a while, but eventually it became too complex; then I worked on Angular and that seemed a big improvement, but then... and finally with React my architectures are clean.

While the reality is more like this: I had 6 months of programming experience and used jQuery and made a disaster; with 1.5 years of experience I used Backbone and I fared better; with 3 years of experience I tried Angular and I was able to build a decent size application but ultimately shot myself in the foot; and now that I have 6 years of experience my software quality has improved a lot, it must be react!

<comment><USER10> Pretty much. It's similar to discovering the power of salt and pepper in cooking. When you first use it everything tastes better. But the next step is not to increase the amounts you use in every dish, it's to explore the much wider world of cooking with herbs/spices/etc.

If your mindset is persistently "this framework/tool will solve _all_ our problems" you're always going to have a bad time. Understanding the pros/cons of each element is essential to becoming a good developer.

<comment><USER12> It's almost like all "modern JS" are written by new programmers hired on the cheap by companies to work on their new hip UI frontends.

IMO UI is generally something new programmers like because of the visual/visceral "I built that", but once you get exposed to the sheer annoyance of UIs, programmers will migrate to backend.

So the most experienced people don't want to be constantly undercut in price by the incoming "talent", realize that WebUIs get chucked every 3-5 years anyway due to browser tech churn, and move to data monopolization.

<comment><USER13> The JavaScript world changes so fast that no one is ever going to be very experienced in the the they are using. I imagine that is partially to blame for all the crap we see in the front end.

<comment><USER12> I agree, the JS ecosystem is reflective of constant new programmers redoing the UI every couple years, although I need to grit my teeth and admit that React did at least standardize/structure the ecosystem for the last few years.

</comment></comment></comment></comment></comment></comment><comment><USER14> > we've discovered that React also leads to some questionable practices. Like > hovers in JS (rather than in CSS), drop-down menus in JS, not rendering > hidden (under a hover) text (Google won't be happy), weird complex logic > (since it's possible!), etc.

This is some strange reasoning that I have yet to seen myself. If you can do the hovers states/drop down menus in CSS, why not do them in CSS, even if you're using React? Seems to be blaming something on a library that the library has no care about in the first place (which to be frank, seems relatively common in web dev circles).

> In the worst case, we would serve you 2.5MB of minified (non-gzipped) JS

And holy guacamoly, how do you end up with this?! Seems that something was surely wrong in the compilation options, forgetting to mangle names or something, missing dead-tree elimination maybe?

<comment><USER15> Talking of bundle sizes, this isn't inherent to the React point being made here but it's arguably too easy to blow up what you're serving. A common example I like to reference is Moment[1] — unpacked size is 4MB, most of which is different locales. If you _don't_ want to bundle all of those with your project, you have to do extra work, instead of making locales opt-in. Perhaps slightly less used, but a more prominent example, a widely-used table component Ag-grid[2] is 25MB before being packed down. Instead of being served as a modular set of components, it's mostly a big blob with minimal separation of concerns.

The takeaway here is twofold: we need better tooling as well as better practices for how to use those tools. It's both an educational problem as well as a toolset issue. It is possible to build lean and fast pages, but it's currently considerably harder than building gargantuan monsters. I don't see the web bloat problem going away until the dynamic here is flipped — it should be easy to ship small bundles even with minimal experience.

[1] [https://www.npmjs.com/package/moment](https://www.npmjs.com/package/moment)

[2] [https://www.npmjs.com/package/ag-grid- community](https://www.npmjs.com/package/ag-grid-community)

<comment><USER16> At my last job I always tried to be quite strict about adding additional dependencies, if something was over 10kb it had to be very strongly justified.

Our designers wanted to add some SVG animations, they started off with Lottie ([https://bundlephobia.com/result?p=lottie- email@example.com](https://email@example.com)) because they could export directly from After Effects, but I said no chance because of its file size. Briefly considered Greensock ([https://email@example.com](https://email@example.com)), but it was also too big for the kind of animations we were looking it.

I'll need to double check what we ended up with, but it didn't have any library code, so each animation was just a self-contained bundle of SVG and CSS animation code, and fairly small.

Edit: I asked around and SVGator ([https://www.svgator.com/](https://www.svgator.com/)) is what we ended up using.

<comment><USER17> Too many people don't respect the risk of dependencies.

</comment></comment></comment></comment><comment><USER18> When I first read the haiku at the bottom of the HTMX homepage, I had a flash of insight.

 _javascript fatigue:

longing for a hypertext

already in hand_

What _are_ we doing? State management libraries? Hypermedia _is_ the engine of application state. Send data to client as HTML and have the client apply styles over it, rather than converting from JSON to local objects and storing in some sort of reactive data store. You will find that semantically structured HTML is almost as economical as JSON.

<comment><USER19> Why does is handling state on the backend better than handling it on the frontend? You will always have the cost of waiting for the server to return the full html every time you want something to happend and still you will have cases where you are handling state on the frontend

<comment><USER18> Theoretically, you have a point. Practically, you are reading this comment on a website that not only does exactly this, but refreshes the entire page (rather than a small block of HTML, intercooler-style). The performance benefits are evident.

<comment><USER20> This site also has almost no state at all per-user.

<comment><USER21> Every time you collapse a thread, that's saved on the server. Then, if you return to the page, it will render those threads collapsed. So that's a decent amount of state.

<comment><USER20> I disagree. It's Boolean and flat (there is neither sequential nor nested logic around the state). It does recurse for each sub thread, but only in the case where there is no state. There's also no business logic built around it, only display logic. It also is updated from exactly one location in the application.

That said, it's a very simple and effective design. It's an excellent program. But it's not a fair comparison against other applications which, for one reason or another, need significantly more advanced state.

</comment></comment></comment></comment></comment></comment><comment><USER22> _We need to look at it from two sides: if it's good for developers and if it's good for users. React was great at former and terrible at later._

React is not "bad for users". Developers build complex, fast apps with React all the time. It _can_ be fast, but if you make mistakes with it then it's easy to make something very, very slow.

The app I work on is huge. It's ~8MB of uncompressed React + Redux in development (much smaller in production though), and pages include a lot of assets so they can weigh in at 23MB in the worst cases. A complex page can have up to 60,000 DOM nodes under React's control with thousands of event listeners. It starts in about 3s and _never_ drops below 60fps.

<comment><USER23> > A complex page can have up to 60,000 DOM nodes under React's control with > thousands of event listeners. It starts in about 3s and never drops below > 60fps

Can one really make such affirmations regarding client rendered web apps? I'm assuming these numbers aren't solely measured on localhost in some state of the art development machine/device so won't it depend on the client's machine specs, browser, usage, bandwidth, etc?

<comment><USER24> I don't know what bandwidth has to do with react managing the DOM.

<comment><USER22> A naively built app will do things like take some user input from a form, send it off to an API and await the response, and then update the UI when if the request is successful or display an error if there's a problem. That means the user has to wait for the request to complete before moving on to their next task. In other words, the DOM update waits for the network. If you have a slow connection that feels horrible (snarky frontend dev note - if you build a server-side rendered app it's how _everything_ in the app works. Sucks if you have a slow connection.)

It's better for the user if the UI assumes the request has been successful and updates the UI with a _temporary_ success state, and then undoes the update if the request fails and gives the user the option to recover their update and try again. Most of the time there won't be a problem (especially with good client side validation) so they'll never see the recover state, and they'll never need to wait for a network request to finish either. Obviously you shouldn't use that sort of UX pattern for critical things though.

<comment><USER9> Ugh, this has got to be one of my biggest bugbears with SPAs. This pattern fails far more than you obviously think it does, and when it does fail, it's usually handled so poorly it's worse than the 'cure' you're peddling.

Give me a clean, server-side form submission any day over the "has it worked, hasn't it?" inconsistency of SPAs.

</comment></comment></comment></comment></comment><comment><USER25> > we've discovered that React also leads to some questionable practices. Like > hovers in JS (rather than in CSS), drop-down menus in JS, not rendering > hidden (under a hover) text (Google won't be happy), weird complex logic > (since it's possible!), etc. You can have a React app without those > problems, but apparently, you have to have better self-control than we had > (nobody's perfect!).

idk if this is fair. OP was using some pretty niche tools (clojure) whereas best practice React metaframeworks like Nextjs may have addressed some of those pagespeed issues.

additionally, I highly doubt that the author has replicated this functionality by using his new turbolinky framework.

So the post is better titled "I improved webpage speed by throwing away React AND a bunch of UI requirements". which is fair dinkum, but less exciting.

<comment><USER26> > additionally, I highly doubt that the author has replicated this > functionality by using his new turbolinky framework.

Which functionality?

> a bunch of UI requirements

So your point is that you don't really know, but let's blame them for trying, or what?

<comment><USER27> It's hard but take a few minutes off before responding to snarky comments.

Please answer their indirect question: "Did you replicate every of the react app's functionality in the app?"

<comment><USER26> This is why it took four months, we had to change all React-isms to something that works in both modes. One particular thing could load less HTML, and it'll require some attention to make it so - but as we're deprecating React version of catalogue, it'll be easier to do.

</comment></comment></comment></comment><comment><USER28> As others have commented, this doesn't seem like it's React's fault.

But it does illustrate how React isn't a magical solution to the front-end woes and how complicated the whole thing still is to do right.

I'd still use React for projects, but for now I've been incredibly happy with the LiveView solution that Phoenix/Elixir offers (or the variants for other frameworks. Blazor for C#, LightWire for Laravel/PHP?).

It's surprising how often I'll work on something and realize that the solution is quite simple now, where before it would definitely mean some serious thinking.

For example: libraries. I remember so many projects where I needed do do some date formatting or manipulation. Moment.js was the obvious solution, but including the whole library was not an option.

With LiveView I can just pull in whatever dependency I want, because it's all server-side. It's only the markup diff for the specific component that gets sent down the wire.

Or security. I need to show a user, but only a 'friend' can see the email address (or other profile details). The 'old-fashioned' way would involve separate API calls and a certain nervousness that perhaps I might end up in a situation where the front-end behaves how I expect, but the API calls somehow expose non-friend data.

With LiveView I can just add a conditional statement to the view, and since the resulting HTML is all that does to the client, I'm done!

Of course this only works with a persistent and relatively low-latency connection, but I can't remember the last time I worked on a project where this wasn't an implicit assumption.

I'm perfectly happy using React/Next/Vue when necessary, but it's a really strange experience to read these kinds of articles and threads these days when for so much of my day to day these problems just went away.

<comment><USER26> LiveView is also very interesting. The main reason we went other way is that amount of connections and state held on server will be really high, plus we have some clients with bad connections and regular HTTP works much better on those than websockets.

<comment><USER29> LiveView can use HTTP longpolling.

</comment></comment></comment><comment><USER30> How on earth does React encourage the bad practice of "hovers in JS"? React absolutely has zero influence on this - that one is entirely on the developers.

I'm also exceptionally confused why the Pagespeed score was sitting at just 5/100 - it doesn't sound like the dev team actually understood the result and attempted to resolve it.

It sounds like the author has found some new technology they're happy with for now, but it sounds like all the previous problem were self inflicted and they're bound to repeat them again.

While different tech and frameworks has an influence in the problems you'll face, you've still got to do _good programming_.

<comment><USER24> If you are writing JS styles, you don't have access to pseudoselectors like :hover. A quick solution adopted by many is simulating hover with onMouseEnter and onMouseLeave event handlers.

This can be remedied by using CSS or styled-components.

<comment><USER30> This is nowhere near a common practice (I've never seen it on any work project, or on community projects). React does not promote or advocate or make it easier to do it this way, rather than the proper way in CSS.

<comment><USER24> It is actually in the react documentation. [https://reactjs.org/docs/dom- elements.html#style](https://reactjs.org/docs/dom-elements.html#style)

I'm not saying that's how it should be done. I'm just clarifying what the author of the article was referring to.

<comment><USER30> Correct, it is documented. That's what documentation is - to list out and describe the API surface.

The entire documentation block for that is prefixed with a big yellow-box warning:

> using the style attribute as the primary means of styling elements is > generally not recommended.

And then it links to [https://reactjs.org/docs/faq- styling.html](https://reactjs.org/docs/faq-styling.html) which just says over and over again "use class names"

<comment><USER24> So just to be clear A) it didn't always have that warning and B) I wasn't defending the practice. Did you read the article?

</comment></comment></comment></comment></comment></comment><comment><USER31> Reading all of the cynicism on the comments I wonder if we are taking into account the business context for the development of the app. I'm not a fan of react even though I use it daily, but the licentious nature of react allows me to build/modify features pretty quickly, albeit, low quality. I'm as idealist as the next person about a good architecture, but if the code you are writing is for a new product that is still trying to find a market-fit spending a lot of time in the architecture of something that could drastically change doesn't make much sense to me.

All that I'm saying is that, as opposed to some other opinionated frameworks, react let's you do pretty much whatever you want, which is great for speed development but can also exhausting in the huge amount of decisions that need to be made.

<comment><USER32> If you're going for speed of development, it's hard to beat server side rendering in Rails. The creator built Rails for speed of development and happy engineers. It's also very opinionated (convention over configuration) which helps me just build out features rapidly without making thousands of pointless decisions.

I am not opposed to React for like, a calendar application, or a particularly complex part of a web app, but most web apps have 90% CRUD and 10% shiny.

And with well-tuned SQL and turbolinks dropped on, Rails pages load in 30-60ms with no page refresh.

<comment><USER33> The happy engineer concept is a much neglected one imo.

Rails devs who've mastered a lightweight js framework like Stimulus and perhaps a webhook utility like ActionCable are immensely more productive than a team of very separate front and back end devs.

Basecamp take this a level further whereby each dev is quite heavily involved in the design process, and their designers can also code in Rails.

With Hey I think they've shown that it can not only be lightning fast but pretty shiny!

<comment><USER32> Oh I agree, I lost a lot of nuance with my trite 1-sentence summary. Shiny is mostly good judgement, good taste, careful organization and a lot of sweat resulting in well-crafted CSS.

Especially in the past few years, as browsers have implemented a lot of animations and scaling in CSS which offloads to the GPU. You don't want JavaScript/CPU doing that math anymore.

Component-based JavaScript frameworks "force" us to organize our CSS in the same way outlawing cars in favor of bikes bikes ensures everyone follows the speed limit.

</comment></comment></comment></comment><comment> lf-non Not opposed to server rendering or backend heavy sites, but a lot of people are able to get much better Lighthouse scores for fairly complex sites through a combination of webpack code splitting, service-worker based caching, and CDNs.

So, the problems here may have had more to do with the clojurescript stack (which I am not much familiar with), or author's lack of familiarity with javascript optimization strategies than react, SPA model or client side rendering.

<comment><USER34> Code-splitting is supported in ClojureScript. Compiled CLJS is just JS, so service workers and CDNs should work in the same way.

However, CLJS really does feel like application development (which is why I like it, tbh) and the community doesn't seem to pay much attention to the use- case of regular web pages which just need some JS components to add interactivity. Googling for strategies to optimise CLJS for that use-case won't get you many results - you have to understand the stack well enough to do it yourself.

</comment></comment><comment><USER35> For sites that are content-heavy I've started wondering if it makes sense to have the content server-side rendered the old-fashioned way, and use multiple React roots for the parts of the page that need to be interactive. You can still use Redux etc. for managing app state globally (though not React context), and you get most of the gains of load time, and of using React where you need it.

It seems everyone uses <body><div id="app-root"></div></body> but React is perfectly happy being scattered around the page.

It's just a thought, I haven't tried it myself yet - has anyone else?

<comment><USER36> We do exactly this within SharePoint. We have various react parts that look things up in the database - sometimes quite heavy queries for reporting.

We have put together a small collection of fairly generic react apps that mean we can put one on a page, put in some config and have it displaying a report generated in SQL in about as long as it takes to write the SQL for the report. We have used this approach for generic SQL reports, SharePoint lists, imgage retrival and entry forms. Having the library of options to hand has meant we can confidently assemble a new (fairly complex) page much quicker than previously - and be confident that it will work as it is reusing known good components.

</comment></comment><comment><USER37> I've been doing Ajax practically since Day 1, and in the olden days when I was young and stupid I actually sent DIV IDs back to the server, which the server would then reply with -- in XML -- to tell the client which DIV to replace.

Then I realized Javascript could do lexical closures which meant the _client_ could keep track of the targets, which also meant the server no longer had to care about things servers shouldn't care about.

The next realization was that DIV IDs are global variables and thus in most cases a bad idea, so now my event handlers automatically search upward (and sometimes sibling-wise) from 'this' for DIVs matching classes or other selectors, to keep the scope local.

This TwinSpark library seems like the next iteration of all the good ideas, plus even more flexibility and proper separation of concerns, without JQuery or other dependencies.

Bravo!

</comment><comment><USER38> Just use Svelte. It's a super simple API, the "trickiest" part is the "reactive sections" but the whole API and reactivity part you can grok in an afternoon.

In the past I have used Angular and React - these days I just always reach for Svelte (speed and simplicity).

<comment><USER39> I was happy learning Svelte, felt like a breath of fresh air with how simple it was in comparison to the other more popular frameworks...but then when I started to kick the tires of Sapper I quickly realized that that's where all the complexity was shunted to

</comment></comment><comment><USER40> Surprised Solid hasn't been mentioned.

This: [https://github.com/ryansolid/solid](https://github.com/ryansolid/solid)

<comment><USER41> Ah, thanks! I was leafing through the Svelte tutorial recently, and I knew I'd read about this other project, but I couldn't remember the name.

<comment><USER40> I like it more than Svelte, personally. A little bit less magic (i.e. easier to reason about) and more performance.

</comment></comment></comment><comment><USER42> Looks like we've come full circle? First server side rendering, then client side, now server side again?

<comment><USER43> <jokes>Time to go bear on "client side" shares and bull on "server side" shares. Quick, grab as much PHP as you can get!</jokes>

All joking aside, I would argue the client side vs server side is a false dichotomy. The web has been doing a hybrid of both for a very long time now. Each have their pros and cons and there hasn't been anything stopping engineers from using a mix of both, where it makes sense.

Now about those cargo cult marketers...

</comment></comment><comment><USER44> > It supports only modern browsers (not IE or Opera Mini) but drops that 88kb > monster.

Whenever I read this, I usually take it the author is being serious. However, how long does it actually take to load a 88kb library these days, is it really 'monstrous'? If this was the authors top performance drain based on profiling, I commend their technical abilities.

<comment><USER26> Well, the reason why I started writing my own library is because I couldn't get all functionality I needed from Intercooler. Why it does not depend on jQuery? Because I wanted no dependencies. :-)

And a "monster" is sarcasm referring to that React bundle I described before.

</comment></comment><comment><USER45> Is this approach similar to Rails Turbolinks?[0]

[0] [https://github.com/turbolinks/turbolinks](https://github.com/turbolinks/turbolinks)

<comment><USER33> I think it's more similar to Stimulus or StimulusReflex? ie you can declare the targets and actions of the JS within the html tags

</comment></comment><comment><USER46> That 5/100 score is very very strange. Have you tried migrating your react code base to NextJs?

<comment><USER47> Right? I think there was something architecturally wrong with the app that the refactor fixed. It doesn't sound like react was the problem here. I sincerely don't believe that this sort of change and therefore the decrying of react for it makes much sense at all without seeing this guy's code.

</comment></comment><comment><USER48> If anything should be learned from this article is this:

"We need to look at it from two sides: if it's good for developers and if it's good for users."

It is a pity this change in thinking required the pressure from Google Pare Rank, but now I see it as something very positive.

Always remember: code is written once, and executed thousands or even millions of times.

No optimization is worse than "premature optimization", and you probably misunderstand what "premature optimization" means anyway.

<comment><USER26> Honestly, I now think that the main reason was different. I was fed up by my Macbook Pro's butterfly keyboard and started working on Macbook Air '15 again at the end of 2019. And in three months I was increasing annoyed by our site loading time.

And then it hit me. MBA is not the slowest laptop out there. It is much worse for a large part of our users.

This is where I started thinking we should jump off the hype ship. :-)

</comment></comment><comment><USER49> All of your issues like dropdown and hover in JS can be solved by CSS, why did you choose to implement them in JS?

About complex logic, it is everywhere. I once worked at an big ecommerce company and the server-side catalog page was more then 2000 lines, nobody want to touch that page. But it would be easier with React since we can break it down to smaller components.

Your 2.5MB minified bundle is actually too big.

<comment><USER50> >All of your issues like dropdown and hover in JS can be solved by CSS, why did you choose to implement them in JS?

Because it's modern? In all seriousness I've often asked questions along these lines and haven't always received great answers.

</comment></comment><comment><USER51> Here is an old story from 2016 but I hope this 3-part article is useful. We used React during its early days, to help Aditya Birla with one of their eCommerce websites.

1\. [https://alarisprime.blog/e-commerce-case-study-building- fast...](https://alarisprime.blog/e-commerce-case-study-building-faster- listing-pages-on-abof-com-part-1-cb99231a1e8a)

2\. [https://alarisprime.blog/e-commerce-case-study-building- fast...](https://alarisprime.blog/e-commerce-case-study-building-faster- listing-pages-on-abof-com-part-2-9aa0ac734c08)

3\. [https://alarisprime.blog/e-commerce-case-study-building- fast...](https://alarisprime.blog/e-commerce-case-study-building-faster- listing-pages-on-abof-com-part-3-4e4d32e0e884)

</comment><comment><USER52> Like what some people said 5/100 on the page speed score is pretty bad. My site used to have this. It boiled down to two things that caused it.

1) I wasn't code splitting by page, and had a couple heavy dependencies (which made things worse)

2) I wasn't pre-rendering my create-react app via react-snap. Meaning during the CI build react-snap runs Puppeteer visits each page on the site, and generates ready-to-go html versions of each page.

Those two changes took me from a 7/100 to a 95+/100 in short order. Makes logical sense too. Now a days the site hovers at 85/100\. But I don't have the time right now to reinvestigate it.

With the options at the time, I'm happy with my tech choices. If I had to start with React again today. I would do Next.JS with a static build output. Would save me a bunch of time scaffolding things.

</comment><comment><USER53> I think there are some interesting points here, though many (including the author) seem to forget: React is a UI _library_ , not a _framework_. This means it is up to the user to decide and implement everything else, such as:

* Code splitting * Loading of the code (at appropriate times, eg: ) * Any other optimisations

I think the author simply failed to do this well and then blamed the library for their own shortcomings, and moved on to the 'next shiny thing'.

There are plenty of patterns you can use to make your React app responsive, and many tools to help you achieve that, it's just a matter of being able to implement those tools effectively.

</comment><comment><USER54> Thought this was a good read - and nice to see the progression of frustration with front-end development throughout the last decade, and then the introduction of mobile. This is a pretty common timeline for web devs who have been doing this ~10+ years.

I wonder why the author did not contribute to intercooler rather than writing his own version. Would it really have been that difficult to avoid inheritance (or add an inheritance free api) and add batching to that library?

<comment><USER26> Batching is doable. I even understand how to do it in htmx. The problem is that

1) htmx started later than I did

2) inheritance is like a plague, and I'd really want it to not exist

I'll try to explain my stance. When you're a developer, you naturally drift to solutions which require you to write less or write faster. And inheritance certainly helps with that in simple cases. TwinSpark had inheritance up until we tried to implement sign-up/in logic.

Damned popups... Anyway, that's the day we've killed inheritance: [https://github.com/kasta-ua/twinspark- js/commit/5714ceea9836...](https://github.com/kasta-ua/twinspark- js/commit/5714ceea98364efc41bc4c9c7b9031c2b23cf2a4)

And if you have two APIs - with and without inheritance - developers will use the first one by default. And when it bites you it'll be painful.

So if Carson reads my rant and decides to remove inheritance - I'll gladly move to htmx. If not - maintaining a library which is less than a thousand lines of code is not that big of a burden. :)

<comment><USER54> Nice thanks for the details - I didn't know you were in talks with them about changes to intercooler, too.

Nothing better than a nice pop-up to ruin your day... they're a different kind of plague

</comment></comment></comment><comment><USER55> The problem is how you think, and all frameworks is the same, they try to visualize the tree structure. The key to understanding async is to think of functions and state propagation.

</comment><comment><USER56> Part of me wants to create a hugo template that takes advantage of this (or htmx). You could make each "request" be a rendered snippet. :thinking: I may try this out.

</comment><comment><USER57> the whole React thing got so ridiculous that you almost cannot call yourself a full stack developer if you don't use it on the front end.

</comment><comment><USER58> Why not a static site (i.e. JAMstack)? If it works for this use case, it can side step so many performance issues it feels like cheating.

</comment><comment><USER59> Today I threw away all the sockets in my set that weren't 14mm, because I only needed a 14mm socket.

</comment><comment><USER60> > So I made a proof-of-concept implementation of our catalogue page in > Intercooler and it worked! Except there was a dependency on jQuery and some > other irritating stuff…

Actually the original author of Intercooler has a renamed 2.0 version that removes some warts - including the jQuery dependency: [https://htmx.org/](https://htmx.org/)

<comment><USER61> HTMX is discussed further down in the same article.

</comment></comment><comment><USER62> This seems to me yet another story of "We didn't knew X enough, so we switched to Y" or even worse, "we implemented our own".

No framework solves the problems of knowing your tools and learning every day, React is no different, not a red pill for every problem, you have to know it's quirks the same way just any other language/framework/tool you use.

</comment><comment><USER63> I love the simplicity of Alpinejs, why bothering with old tech like React ;)

</comment><comment><USER64> In the article though he does not mention whether React with SSR is an option?

<comment><USER26> It always had server side rendering. [https://solovyov.net/blog/2017/server- side-rendering/](https://solovyov.net/blog/2017/server-side-rendering/)

</comment></comment><comment><USER65> You can populate an ordinary web page with some react and get the best of both worlds.

Plain javascript is painful.

It's nit necessary to throw out react to address the issues identified here.

The author comes across as fairly junior.

<comment><USER60> > Plain javascript is painful.

Which is exactly why he isn't advocating plain javascript. You should take a look at micro-frameworks like Intercooler (and htmx, unpoly alpinejs etc). For devs who don't remember the days before megaframeworks it can be quite illuminating to see a different way of looking at things.

</comment></comment><comment><USER66> In short, the OP changed the architecture from a client-side rendered app (in React) to a server-side rendered one (built on a custom-made framework cloned from Intercooler.js) and that resulted in a significant performance improvement for their app.

Overall not a good critique of React as such to justify the "throwing away React" title in the front page of HN. In fact, not a lot of good conclusions can be drawn from the read. Maybe just "if YOU build/find YOUR own framework for YOUR problem space excitement will follow."

On the other hand, I doubt the complexity issues, also mentioned by the OP throughout the article, was solved by using the new framework. In fact:

> On the developer side, I think React is better still

So tit-for-tat.

<comment><USER67> 6-12 months from now another article will be warranted, the author will have changed their mind again. That's the pattern you see throughout the entire thing, non-stop jumping. It's a solid bet as an indicator of the lack of maturity as a developer, incessant tech hopping.

<comment><USER68> You mean in nine years its Backbone, then React, then server-side rendering? Yeah, that's tech hopping every 6 months in its finest.</comment></comment></comment>


Org mode for Emacs – Your Life in Plain Text - <AUTHOR> http://orgmode.org/features.html <comment><USER2> Org mode is one of the greatest things that ever happened to Emacs.</comment>


Mobilenotifier beta5 for iOS - <AUTHOR> http://www.peterhajas.com/blog/2011/5/29/mobilenotifier-beta5-ecstatic-eggo.html

<comment><USER2> How usable and stable is this?

I do use a jailbroken iPhone (for LockInfo) but am gun shy trying any other app that messes with the system.

<comment><USER3> I've been using it for about two weeks now, and while I don't like to tweak my iPhone (4) too often, this is a really nice tweak. It's set to not show the annoying, interfering blue notification popups while my phone is unlocked/being used, and the "Recent notifications" list (which I have set to be pulled down from the status bar, like in Android) works really well.

I'm generally not a fan of Android's UI but I think it's one place where they've nailed it.

</comment></comment><comment><USER4> I wonder how comparable this is to the revamped notifications in iOS 5? Because the experience looks pretty good.

I love how you don't have to switch out of the application to respond to the notification.

<comment><USER5> What revamped notifications in iOS 5?</comment></comment>


Did a Solar Storm Detonate Deep Sea Mines During the Vietnam War? - <AUTHOR> https://www.smithsonianmag.com/smart-news/did-huge-solar-storm-detonate-mines-during-vietnam-war-180970771/?platform=hootsuite <comment><USER2> Vietnam formed a task force called GK1 to research how to safely detonate those mines during the war. According to them the mines at Hòn La were detonated due to lightning stroke nearby.

Source: all 11 members of GK1 were from my university. I still remember the first day at school and they were talking about how they provided engineering effort for the war (bazooka clone, sea mines clearance, 2nd Mig pilot to downed a B52 etc..) but I'm sure some of them are just propaganda.

</comment><comment><USER3> > In the United States, sparks burst out of telegraph equipment, sometimes > starting fires.

> Should such an event happen today—when our lives our so intricately linked > to technology—the results could be catastrophic, causing mass power losses > and disruptions to GPS and satellite communications.

I wonder what would be affected if this was to happen today. Would it only be power distribution, or telecoms as well?

<comment><USER4> Aren't electronics today more sturdy from am EM perspective than their counterparts in the 60s and 70s? Not that a strong solar flare couldn't cause problems regardless.

<comment><USER5> If they're specced to be (military, aerospace), sure. But the move from vacuum tubes to transistors, for all its incredible advantages, made everything a lot more EM vulnerable.

</comment></comment></comment><comment><USER6> Curious if it set off mines underwater but had no effect on the planes flying above the area. You'd think they would at least have noticed some unusual radio interference.

(My partner just pointed out that it was probably Bruce the Shark that's set them off. :P )

<comment><USER7> The planes were probably too small and far away to set off the detectors.

<comment><USER8> I think then statement was "wouldn't the planes have detected the solar storm" vs "wouldn't the planes have set them off"

</comment></comment></comment><comment><USER9> to avoid such mines ships are de-magnetized. I never though heard of "over- pulse-magnetizing/etc." of de-mining ships (or even say low&slow flying planes) as a way to trigger those mines from a safe distance - a de-mining approach that the solar flare triggered explosions suggest.

<comment><USER10> Towing a magnetic field generator behind a boat or aircraft is a common minesweeping technique. The generator is usually mounted on a floating 'sled' to maximise depth capability, but aircraft-mounted degaussing coils were used in minesweeping by the British in WWII.

[https://en.m.wikipedia.org/wiki/Minesweeping](https://en.m.wikipedia.org/wiki/Minesweeping)</comment></comment>


How do you deal with Stress? - <AUTHOR> How do you deal with Stress ? <comment><USER2> Walking and/or running. even if you do small and irregularly it helps. if you are consistent then it make significant impact on the way you deal with stress and several other issues. It tool long time to realize this, but for me it works really well for me.

</comment><comment><USER3> Please get professional help, do no underestimate the importance. I do believe another undertaken advice is around hitting the gym. Try to find the root cause. Write down every small tasks in your mind into a notebook and clear them one by one.

</comment><comment><USER4> Magnesium may help, if you don't already get enough from your diet. [https://www.huffpost.com/entry/magnesium-the-most- powerf_b_4...](https://www.huffpost.com/entry/magnesium-the-most- powerf_b_425499)</comment>


Show HN: Speedproject to display books I have read  in 2013. - <AUTHOR>

I was inspired by Arron Swartz's post: http://www.aaronsw.com/weblog/books2011 and Harper Reed's collection: https://harperreed.org/books to start tracking what I read as well.
This is my attempt: http://crismannoble.github.com/tabula/
Feedback welcome. <comment><AUTHOR> clickable: <http://crismannoble.github.com/tabula/></comment>


The Easiest Data Analysis Mistake to Make - <AUTHOR> http://blog.statwing.com/easiest-data-analysis-mistake-to-make/ <comment><USER2> This is a very simple and very pathological example that's easily ferreted out with a few more summary statistics (median, min, max) but it's a good illustration of the blind application of statistics. Short of visualization, non-parametric statistics really help with such things. Correlation is a fragile, linear measure, and things that are obviously correlated by inspection can easily appear mathematically uncorrelated -- points on a unit circle, for example. Likewise, the mean of any skewed distribution tells you very little, but that's the statistic that's always cited. Quantiles, medians, and non-parametric measures of correlation such as rank correlation are simple and often overlooked. They do a good job screening for pathological data sets like Anscombe's quartet and real world ones.

It's also worth mentioning "dumbbell" data sets. Two clusters of data, each of which have a independent, meaningful correlation in them, can easily leverage a linear regression into a meaningless line passing through the two clusters. That's a pretty common issue with high dimensional data (obviously you can see it in a 2D scatter plot), and it's not easily caught short of looking at regression diagnostic statistics.

<comment><USER3> I believe the "dumbbell" effect you are referring to is Simpson's paradox: [http://en.wikipedia.org/wiki/Simpson's_paradox](http://en.wikipedia.org/wiki/Simpson's_paradox)

As you point out _obviously you can see it in a 2D scatter plot_ , but you have to select the correct two variables.

</comment></comment><comment><USER4> I think, typically, if you've gone to the trouble of calculating variance and correlation, you would have also calculated the median and mode of these datasets. The differences would have been obvious with those basic analyses.

<comment><USER5> How do you define the mode of a data set where all the values are different?

</comment></comment><comment><USER6> [http://en.wikipedia.org/wiki/Anscombe's_quartet](http://en.wikipedia.org/wiki/Anscombe's_quartet)

</comment><comment><USER7> Statwing looks great!

Right now I do my data analysis in numpy, but this looks good for my Excel- based colleagues.

What library is doing the statistics?

<comment><AUTHOR> Thanks, really appreciate it! We use numpy, scipy, and pandas.

EDIT: clarified libraries we use.

</comment></comment><comment><USER8> So a concept you find in a beginner stats textbook is now 'news'? Definition of blogspam surely...

<comment><USER9> I would agree with you. Anyways I hope people were not making such errors and if we were, then at least someone would benefit from reading this!

</comment></comment><comment><USER10> My favourite part of this (aside from the message) is that it links back to this exact discussion page.

</comment><comment><USER11> An equally common mistake is to visualize without analyzing :-)

</comment><comment><USER12> who doesn't look at the data range, min, max, mode???

<comment><USER13> Range and mode won't save you from the quartet, and they're a red herring in any case (you'd need to add statistics until you go blue in the face).</comment></comment>


Ask HN: Should you localize error codes in the console? - <AUTHOR> <comment><USER2> I generally don't like a localized console (German here). Copy and pasting error messages to Google is much easier when it is in English. I frequently run stuff like

       LANG="C" make

to ensure English output.</comment>


Undercover video suggests Facebook wants extreme and disturbing content - <AUTHOR> https://www.cbc.ca/passionateeye/features/how-does-facebook-moderate-its-extreme-content <comment><USER2> The headline seems to be a rather extreme (and willful) misrepresentation of the facts.

As the article points out, framing is important for the decision making, and I see absolutely nothing wrong with that. A video showing the horrors of war, and being presented as an argument against war, just is different from a video showing violence with an accompanying message promoting such violence.

One case in point is the Kim Phuc photo of a naked crying girl running away from Napalm in Vietnam. That photo being deleted actually was widely criticized, as it should.

At least my experience using Facebook also speaks against the article's thesis: I cannot remember ever being shown any gratuitous violence. If they are trying to shore up click with shock value they are doing a mightily bad job at it.

There's a lot to criticize about Facebook, but this just doesn't seem like it.

<comment><USER3> Some images become iconic and symbolize a greater issue such as that photo. But I think that's different from calling any gratuitous real graphic violence just because it's contextualized "correctly", acceptable.

<comment><USER4> They would have less of an opportunity to become iconic if the biggest media distributors censored them immediately.

<comment><USER3> While big media is imperfect and has its large problems, they provide a nuanced filter with regard to things like self-harm, suicide, genital mutilation, etc. I'd prefer not having very personal very dark themes go through a lowest common denominator since many people lack judiciousness and good judgement when it comes to these issues. Is an image informative or is it promoting something further? Exploitative or Journalistic?

</comment></comment></comment></comment><comment><USER5> > A video of a toddler being beaten by an adult would prompt hundreds of calls > by Facebook users for its removal. But as the documentary reveals, a video > showing just that is being used by CPL to train moderators on the type of > content that should remain on the platform.

> In this case, the video was left to circulate online for six years after > being flagged by online child abuse campaigners.

> The decision to ignore or delete extreme content appears to rely on how it's > being positioned. In one instance, the undercover moderator asks the advice > of his colleague regarding a video that shows two underage girls, one of > them being beaten by the other. "Unless it has a condemning caption, it's a > delete," says the colleague, referring to the text accompanying the video.

> In other words, if the caption were promoting the violence or poking fun, it > would come down. But in this case, since the caption condemns the fighting, > the moderator is told to leave it up with a "mark as disturbing" warning. As > the __colleague notes __, "If you start censoring too much, then people lose > interest in the platform. It's all about making money at the end of the > day." (emphasis mine)

> The undercover reporter inquires about a far-right page that touts anti- > Muslim and anti-immigrant content. He is told that these pages, though they > have exceeded Facebook's "allowed content" violations, remain active and are > "shielded," preventing the CPL moderators from deleting them. "Obviously, > they have a lot of followers, so they're generating a lot of revenue for > Facebook," says one __moderator __. (emphasis mine)

That's all the substantive material from the article. I find it noteworthy that at least two of the damning quotes come from co-moderators, not any sort of official material. Whether that's an intended culture on facebook's part or not is up to the reader to infer.

<comment><USER6> "If you start censoring too much, then people lose interest in the platform."

It's interesting to hear them say that. I usually see moderators/administrators on the internet characterized as being quick to wield the ban hammer or purge stuff that could harm their brand. I rarely see this other side depicted, wherein mods/admins intentionally hold back because purging too much will make the place no longer cool. Good to know people consider that a concern, though in facebook's case maybe they're taking that sentiment a little too far.

</comment></comment><comment><USER7> Non mobile link: [https://www.cbc.ca/passionateeye/features/how-does- facebook-...](https://www.cbc.ca/passionateeye/features/how-does-facebook- moderate-its-extreme-content)

<comment><USER8> Good grief, thank you.

</comment></comment><comment><USER9> The title is "How does Facebook moderate its extreme content?", which seems more accurate than "Undercover video suggests Facebook wants extreme and disturbing content."

<comment><AUTHOR> This was the original title linking from the front page of CBC

</comment></comment><comment><USER10> This title provided by the OP is intentionally misleading and taken from a quote by Roger McNamee.

There are other platforms out there (liveleak and worldstarhiphop for example) that it only takes a minute or less to reach extreme content. If Facebook _really_ desired what the OP suggested, assumed by Roger McNamee to push ad revenue by engagement then that's exactly the first video one would see when logging in Facebook. The first video I see is always some shallow inspirational video by an "influencer" or a Buzz feed video on cooking.

Dang, I'd rather at least the original title be used so that anyone reading the article can reach their own conclusion and then bring whatever fire and brimstone need be.

<comment><AUTHOR> This was the original title linking from the front page of CBC

</comment></comment><comment><USER11> > _if the caption were promoting the violence or poking fun, it would come > down. But in this case, since the caption condemns the fighting, the > moderator is told to leave it up with a "mark as disturbing" warning_

This sounds exactly right. How the heck are we supposed to confront and fight society's ills if any video highlighting them is immediately deleted?

Maybe if people were more aware of the shocking problems that people are facing in the world, they would be more inclined to act upon it. Out of sight, out of mind.

</comment><comment><USER12> I read nothing in this article that confirms the headline, rather it just shows that content moderation is hard.

<comment><USER7> 'The film also uncovers how some Facebook pages that promote hate speech are left up and running. The undercover reporter inquires about a far-right page that touts anti-Muslim and anti-immigrant content. He is told that these pages, though they have exceeded Facebook's "allowed content" violations, remain active and are "shielded," preventing the CPL moderators from deleting them. "Obviously, they have a lot of followers, so they're generating a lot of revenue for Facebook," says one moderator.'

</comment></comment><comment><USER13> Content moderation is difficult, and there are _many_ legitimate and arguable edge cases.

The existence of these edge cases and difficulty of moderation does not negate or excuse FB's overall behavior, which goes far beyond, as noted by several examples in the article.

Roger McNamee, an early investor in Facebook: "This is essentially the crack cocaine of their product. It's the really extreme, really dangerous form of content that attracts the most highly engaged people on the platform, So they want as much extreme content as they can get."

This is the same reason that FB makde a top level decision to leave posted a video known to be maliciously edited to make the subject look drunk or impaired -- the subject is the person 3rd in line for the Presidency of the United States. Nevermind that this effectively amplifies & legitimizes false propaganda on one of the world's largest publishing platforms.

This is the same reason that FB ignored massive interference in the US election by Cambridge Analytica, Russia, etc. The content was surprising and increased engagement time, nevermind that much of it was false and micro- targeted at people's specifically tested fears, and corrupted the electoral process.

Anything that people cannot turn their eyes away from, simply to extend "engagement" time and rack up counts of adverts displayed. The ruthless pursuit of attention in the attention economy.

The only restraint is the limit of how grotesque the content can be before people turn away, and that boundary is apparently being continually pushed forward by exposure.

Of course, they justify it all on varoius grounds ranging from 'freedom of expression', 'let the viewers decide', 'we're not editors', etc., ad nauseum.

To be clear:

This is beyond malicious, this is knowingly (or at best intentionally ignorantly) poisoning society for their own profit.

Not that this is unusual; corporations have often poisoned the water, air, & land for their own profit. Except that this is at the scale & scope of modern technology.

If we don't want the tech industry to soon be seen in the same light as the old smokestack or cigarette industries, this needs to be curbed.

</comment><comment><USER14> > The decision to ignore or delete extreme content appears to rely on how it's > being positioned. In one instance, the undercover moderator asks the advice > of his colleague regarding a video that shows two underage girls, one of > them being beaten by the other. "Unless it has a condemning caption, it's a > delete," says the colleague, referring to the text accompanying the video.

</comment><comment><USER15> I am distrustful of "undercover" investigations in general now, mainly due to the activities of James O'Keefe and Project Veritas. It's very, very easy to cut a "bad guy edit," especially when people don't know they're the subject of an interview.

> In one instance, the undercover moderator asks the advice of his colleague > regarding a video that shows two underage girls, one of them being beaten by > the other. "Unless it has a condemning caption, it's a delete," says the > colleague, referring to the text accompanying the video.

> In other words, if the caption were promoting the violence or poking fun, it > would come down. But in this case, since the caption condemns the fighting, > the moderator is told to leave it up with a "mark as disturbing" warning.

This seems like a reasonable balance to strike. Context is extremely important; a video of Nazis marching down an American street can mean two very different things depending on who is posting it, and why.

> [Early Facebook investor Roger] McNamee describes how the platform's > business model actually relies on extreme content, as it keeps users on the > platform longer, feeding them more ads and increasing revenue. "This is > essentially the crack cocaine of their product. It's the really extreme, > really dangerous form of content that attracts the most highly engaged > people on the platform," he says.

This gets to a more salient underlying issue; Facebook, and pretty much every other app on your phone, makes money from your attention, and they're designed to be addictive. This is true with Facebook notifications, Reddit karma, games ... the art and science of triggering compulsive behavior has been weaponized by advertisers and is being used against us.

The fact that some people's compulsive behavior is triggered by fake videos of Nancy Pelosi doesn't matter to Facebook. There is no political angle there, only financial.</comment>


A visual history of the future of cities (2014) [pdf] - <AUTHOR> https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/360814/14-814-future-cities-visual-history.pdf <comment><USER2> I've only skimmed at this point as it's a lengthy PDF, but this looks like it'll be an enjoyable read - lots and lots of really interesting ideas and concepts from the last few centuries. To be clear, it's not about the future of cities, rather, as per the title, the _history_ of the future of cities - i.e. what can we learn from where we previously thought we might be going?

<comment><USER3> Minor correction: Mostly from the twentieth century, not the "last few."

</comment></comment><comment><USER4> More info on the project that produced this (and links to other similar resources) at [https://www.gov.uk/government/collections/future-of- cities](https://www.gov.uk/government/collections/future-of-cities)

No obvious word (though I only had a quick scan) if nicely printed copies are likely to be available.

</comment><comment><USER5> Looks like a fun read. I did a search, and it looks like there was no mention of the EPCOT project[1]. I would have enjoyed the authors' take on the subject.

[1][https://en.wikipedia.org/wiki/EPCOT_(concept)](https://en.wikipedia.org/wiki/EPCOT_\(concept\))

</comment><comment><USER6> Such a nice and inspiring book.</comment>


Twitter Should Decentralize (And Make Money) Via Twitter Server  - <AUTHOR> http://www.techcrunch.com/2009/10/04/twitter-should-decentralize-and-make-money-via-twitter-server/ <comment><USER2> The current value of Twitter is not in it's technology, it's in it's userbase. You could write a better engine to do what they do, but you can't convince enough people to use it. Your suggestion to decentralize essentially has them giving credibility to external sites (who licence their engine) at a cost of what they value most (their users). Once I'm buying t-server from them, a new startup can compete on features..

I'm sure there are lots of good ways for Twitter to make money, but I don't think that diluting their user base is one of them..

</comment><comment><USER3> The Exchange analogy doesn't apply to Twitter. For starters, most people want to keep their Exchange email confidential. IOW, the rest of the world can neither see the contents of the "inbox" nor the "sent mail" folders. OTH most people want their twitter status updates to be seen by others and there isn't much incentive to host it securely.</comment>


Fifteen Years Ago, America Destroyed My Country - <AUTHOR> https://www.nytimes.com/2018/03/19/opinion/iraq-war-anniversary-.html <comment><USER3> Content such as this really doesn't belong on this forum. It redditifes this forum for conversation.

I've also noticed people jump to attacking each other quite a lot more in the comments of pieces like this.

<comment><USER4> agreed. Still, I think of myself as an optimist and would like to think we HNers could civilly discuss any topic that popped up on HN :)

</comment></comment><comment><USER4> This is the opinion page of NYT. I wonder how far this perspective wanders from reality. If there's anything I've learned from studying the Arab-Israeli conflict its that most individual perspectives provide a universally bad account for causes, effects, and relations in a given situation, while simultaneously offering a rich amount of insight into human bias, error, emotion, and self deception.

That is, however, not to say that that is what this account is.

On that note, does anyone have a suggestion for the most non-biased sources i.e. books for understanding the conflict? I realize it's probably going to be very hard right now since distance in terms of time usually leads to more accurate and less biased analyses of a historical event.

</comment><comment><USER5> American here. Never supported sending troops over there. Not a lot of people did. But Bush did it anyway. Didn't vote for him. Sad to see what it did to people.

<comment><USER6> Thankfully, we avoided war-supporting Hillary Clinton.

</comment></comment><comment><USER7> Man, that's depressing. While I never argued for invasion, I deeply regret supporting those who waged the war thinking that lack of support would lead to a quagmire and a situation that was worse than before, and that was pretty awful. The more I read about the war, I came to the conclusion it had absolutely no chance of being anything else. It's got to be one of the worst cases of collective sunk cost fallacy.

Empires are evil. America is one of the least evil, but that doesn't justify its empire. It might have been necessary to defeat Nazism, and to hold back the spread of communism, but we are squandering our future's prosperity to accomplish what exactly? I could understand if it was a question for survival, but American citizens enjoy so much security it's ridiculous, even 15 years ago. Even with all the mass shootings.

Boycott news media. Boycott national politics. The world will be better off.

<comment><USER8> We were defending the petrodollar in Iraq. i.e. attempting to maintain American hegemony. Viewing all recent conflicts through that lens really helps to understand. "Yellow cake" and the like is just how it was sold.

</comment></comment><comment><USER9> ' _Some credible estimates put the number [of people who died since 2003] at more than one million._ ' ' _The invasion of Iraq is often spoken of in the United States as a "blunder," or even a "colossal mistake." It was a crime. Those who perpetrated it are still at large. Some of them have even been rehabilitated thanks to the horrors of Trumpism and a mostly amnesiac citizenry. [...] The pundits and "experts" who sold us the war still go on doing what they do._ '

</comment><comment><USER10> >I left Iraq a few months after the 1991 Gulf War and went to graduate school in the United States, where I've been ever since.

Love the ambiguity here.

<comment><USER11> There's no ambiguity though.

<comment><USER10> On my first read I interpreted it as they'd been stuck in grad school for almost 3 decades, which seemed almost believable.

It's one of those context dependant sentences - if it had said since 2016, then that interpretation would be most likely correct.

</comment></comment></comment><comment><USER12> Why oh why is this flagged? Does HN lack the stomach for civil debate about a contentious issue?

For those trigger happy flaggers - the responsibility ordained on you shouldn't be abused. Reddit will devolve into partisan piffle, HN IS the only space that's remotely capable of civility. So, don't flag - <USER2> diversity of thought!!

</comment><comment><USER13> Wonder if this guy will also apologize for the horrible things Iraq did to both Iran in the early 80s and Kuwait in the 90s.

<comment><USER14> It's a little odd to hold a civilian citizen of a despotic regime accountable for his government's actions.

<comment><USER15> And similarly it's a little odd to hold an entire country of 350 million people responsible for the self serving decisions made by a small cabal of powerful oil people(Bush, Cheney, Rumsfeld et al.)

Similarly was the entire country of Iraq responsible for horrific transgressions against the Kurds, Iran and Kuwait or just a small cabal of corrupt people with real power?

<comment><USER14> I guess "Fifteen years ago, American armed forces and American mercenaries destroyed my country at the bidding of the democratically elected leaders, but with only partial consent of the citizens" was too wordy.

To be serious, blaming an "entire country" is a _little_ more understandable if that country is a functioning democracy. Of course, if it's actually an oligarchy where the government is above the law and many voters are disenfranchised and easily manipulated by unchecked propaganda, then... well, that's frustrating.

<comment><USER15> >"To be serious, blaming an "entire country" is a little more understandable if that country is a functioning democracy."

No it would be "more understandable" if that country was a direct democracy and the people actually voted on the resolution. The US is a representative democracy and often resembles a plutocracy at that.

<comment><USER14> Yes, compañero, this is pretty much what I was getting at. I said it was a little more understandable, but I didn't mean to imply it was correct.

</comment></comment></comment></comment></comment></comment><comment><USER16> So is the United States this man's country, or is Iraq this man's country?

<comment><USER17> Neither most likely. I think that this man is an apatrid and that he doesn't have a real home judging by a similar string of events in my life. My country was economically devastated due to unfavorable Geo-political circumstances and I eventually had to choose to move, rather than to prolong meaningless suffering. I was lucky to have a choice. Although, I'd say it was not as dramatic as in the case of Iraq. Anyhow, I feel as if I don't belong anywhere.</comment></comment>


Tinder in Meteor - <AUTHOR>

Hey guys, This is me trying to create Tinder in Meteor.
http://ishq.mobi/
Still a work in progress but basics have been done and you can match and chat(no notifications so you have to come back to the site to see your matchs).
Allow to use your location otherwise it doesnt show how far other users are. <comment><USER2> You misspelled "matches".</comment>


Amazon's new competitive advantage: putting its own products first - <AUTHOR> https://www.propublica.org/article/amazons-new-competitive-advantage-putting-its-own-products-first <comment><USER2> The repeated comparisons to (grocery) store house brands is entirely disingenuous.

Most consumers know those brands are associated with the store, and the store makes no effort to hide the fact.

"Amazon Basics" makes no effort to hide it's association and I'm okay with that.... But many of the rest of Amazon's brands seem entirely designed to obfuscate their association with Amazon itself.

As a matter of fact, Amazon doesn't even provide a complete list of its house brands. Pretty telling if you ask me.</comment>


Ask PG: did you just change the password hashes? - <AUTHOR>

I've noticed that this morning (for the first time ever), that I've had to re-login to hn on an already loggedin browser. Pray tell how was the password data stored previously? :) <comment><USER2> Not sure what's going on with you but I didn't have to login again.

</comment><comment><USER3> Your session was probably stolen by the man in the middle :o</comment>


Intercom raises $50m - <AUTHOR> https://blog.intercom.io/50m-round-ceo-message/ <comment><USER2> CEO of Intercom here.

We launched here, 1,741 days ago apparently! :flushed:

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

Thank you for your help along the way. The HN community has always been really good to us.

</comment><comment><USER3> A cool video! We have built a SaaS app and a bootstrapping on the smell of an oily rag, so have minimised our costs on all third party tools, but we spent up to subscribe to Intercom and glad we did, because the ROI has been excellent.

Hope to see them become bigger and stronger, same as I hope we can make a similar announcement about our app in the future! :)

</comment><comment><USER4> Love the casual tone of this. No fancy champagne party, just a VLOG style video from the CEO. We need more of this kind of modesty and humility. Thanks for building this!</comment>


Get used to failure - <AUTHOR> https://letterstoanewdeveloper.com/2018/12/31/get-used-to-failure/ <comment><USER2> Great work is rarely easy.

<comment><AUTHOR> Is it _ever_ easy? I can't think of any instance.

<comment><USER2> Maybe the beginning can be great like observing mold failing to grow in part of a Petri dish. But the greatness comes after that.</comment></comment></comment>


Java 6 vs. Java 7 vs. Java 8 between 2013 – 2016 usage stats - <AUTHOR> https://plumbr.eu/blog/java/java-version-and-vendor-data-analyzed-2016-edition <comment><USER2> tl;dr; Java 7 still below Java 8, Java 6 phasing out quickly shrinking 2x each year

<comment><AUTHOR> Well, this is definitely one way how to aggregate it. Next time will contact you to craft a catching headline for the article.</comment></comment>


Ad-Removal Extension Youtube Options to Charge Monthly Subscription - <AUTHOR> https://spoi.com/change

<comment><AUTHOR> I would say it was an april fool's joke, but they announced it on the second and it still hasn't been removed.

</comment><comment><AUTHOR> this is the link to their site itself : [https://spoi.com/software/yto/](https://spoi.com/software/yto/)

it has links to extensions for chrome, firefox and safari</comment>


Of course smart homes are targets for hackers - <AUTHOR> https://mjg59.dreamwidth.org/45483.html <comment><USER2> One threat model I think is being missed here: the fact that scanners and geolocation services both exist, makes the job of burglars much simpler in an insecure IOT world.

Basically they go to their friendly shodan-alike and get a list of ip running IOT cameras (etc). Then they pipe that list through a geolocation service and grep for their target region. Then they just monitor for good targets, and when they are unoccupied.

Much like the big hubub when people pointed out that mentioning vacations on an open facebook feed was burglar bait.

Both take away a lot of effort for reconning homes, so they are probably being used to narrow the search for good potential targets.

<comment><USER3> This isn't the threat it is made out to be. Most homes are empty every day when people are at work. It isn't really necessary to perform advanced analysis to find an empty home.

<comment><USER4> Most homes, but not all homes, especially with home offices being an actual thing that's becoming more popular. I doubt many burglars want the risk of running into somebody during their "heist", so they will stake out possible targets. Staking out a target used to be time-consuming and a bit risky, because the burglar needed to be on location for quite some time to conduct surveillance themselves, in person. Now they can stake out multiple targets at the same time, from anywhere they want, with all the anonymity the Internets allow for.

<comment><USER5> While the addition of anonymity would certainly be appreciated by would-be burglars you seem to be leaving out a small detail. It is trivially easy for a burglar to determine if someone is home. They can just walk up to the front door, knock and see if anyone answers.

If someone is there ask for a glass of water, ask if they have accepted Jesus, ask if Steve lives there or whatever other BS excuse they have ready before simply moving on to another prospect. If no one comes to the door then the home is very likely empty and they can proceed.

This has the added benefit for the burglar that anyone seeing them enter the property will assume they have good reason to be there. After all they marched straight up to the front door and rang the doorbell which is what non-thieves do so its less suspicious if they then go around the side of the house when no one answers.

<comment><USER6> In some ways, this is just another class of "Thieves are following you on Twitter so don't let anyone know if you're going on a trip." Sure, for some high profile individuals, keeping your movements secret may make sense. But for most people this is sufficiently far down on the list of threats that it probably doesn't matter.

</comment></comment></comment></comment></comment><comment><USER7> This article, like many security articles, shows an unwillingness to reason about security in a non-extreme manner. All aspects of life include risk, internet or IoT security are just one axis of risk that must be weighed when making decisions and, well, living. I find The Wirecutter's advice to be perfectly sound and reasonable.

<comment><USER8> Most people aren't sufficiently informed to be able to make those decisions in a reasonable way, and having the Wirecutter provide this kind of advice without explaining that there are cases where some people _do_ need to be more paranoid is harming those people. Telling people that everything will be fine when we know that for some people there's a much higher probability that it won't be shouldn't be acceptable.

<comment><USER9> >>Most people aren't sufficiently informed to be able to make those decisions in a reasonable way

Exactly. The _vast_ majority of people aren't aware that their "smart thermostat" can be hacked and used to perform a denial of service attack on websites.

<comment><USER10> I'd wager that the vast majority of people also does not care the slightest about that. The manufacturer is at fault for that, not the person who bought the device. Unless people themselves get any drawback, why should they care?

<comment><USER9> Well, it's like how people used to not care about leaving their wifi access points unprotected back in the day. It took several years of news stories of neighbors downloading child porn through those WAPs (and things like that) before people became aware of the risks and password protection became standard practice.

</comment></comment></comment></comment></comment><comment><USER11> Can someone fill me in on this IOT hacking phenomenon. Surely the vast majority of devices sit behind a NATted router with a firewall on consumer premises, they don't have dedicated IPv4 addresses and don't touch the internet unless they are requested to (or already have a bad binary on install). How is this hacking happening?

<comment><USER12> Also consider the hubs. To take a well known example, Phillips Hue lightbulbs don't connect to the net directly and don't have any significant computational resources to speak of. They are just an 8-bit Atmel microprocessor with a Zigbee radio to talk to the hub ( [https://blog.adafruit.com/2016/06/14/teardown-of-a- philips-h...](https://blog.adafruit.com/2016/06/14/teardown-of-a-philips-hue- led-lightbulb-with-zigbee-and-atmega2564-avr-iot-iotuesday/) ).

On the other hand, the Hue hub is running a full embedded Linux distro (which has even been rooted, though it requires physical access [http://colinoflynn.com/2016/07/getting-root-on-philips- hue-b...](http://colinoflynn.com/2016/07/getting-root-on-philips-hue- bridge-2-0/) ). A lot of the "real" smart home gadgets are using this model and they will gleefully punch a hole in you firewall, so it comes down to the security of the hub(s).

From what I know, Mirai is mostly hitting stuff that isn't what I think of as IoT - stuff like routers, security cameras and DVRs. Seems like it's being misrepresented, though that's not to say that an attack on something more in line with what I think of as IoT/smart home isn't possible. I have no doubt that tons of refrigerators with Wifi and connected coffee makers are vulnerable. Part of me wonders if Mirai was meant as a grey hat warning since it's just showing what's possible only picking on low hanging fruit ("Mirai" means "future" in Japanese).

<comment><USER13> > _Part of me wonders if Mirai was meant as a grey hat warning since it 's > just showing what's possible only picking on low hanging fruit._

I would wager that is correct. I certainly took it that way, especially after the source code dump. [0] That seemed to be almost out of frustration.

[0] [https://github.com/jgamblin/Mirai-Source- Code](https://github.com/jgamblin/Mirai-Source-Code)

</comment></comment></comment><comment><USER14> A long, long time ago - before JohnCompanies and rsync.net and Oh By - I was a windows sysadmin.

One thing I noticed was, for the most part, the intelligence of a user was inversely correlated to how much shit they had running in their windows system tray.

The smarter you were, the fewer little blinking mini-icons you had down in the lower-right corner of the desktop. You didn't need those gimmicks and you understood the value of simplicity in a running system.

I wonder how smart homes and smart people correlate ?

<comment><USER15> I always get annoyed at how many things want a system tray icon now. There's _no reason_ for my mouse to need a piece of software that lives in the system tray. There's _no reason_ for my IM client to live in the system tray. There's _no reason_ for my video card driver to have an updater service that lives in the system tray. It's ridiculous. Of the 12 things in my system tray, I've only ever clicked on _three_ of them. It's infuriating.

<comment><USER16> _" It's infuriating."_

I sure hope you don't own an HP printer...

Get into Services and set unessentials to manual, bloatware to disabled(if cannot uninstall & keep functionality or driver). Some searching[0] around will show more than a few MS services can be disabled without anything of value lost.

edit: blackviper's still up and running. wow. :

[0] [http://www.blackviper.com/sitemap/](http://www.blackviper.com/sitemap/)

<comment><USER17> My favorite piece of HP software was some printer "accessory" that would hang out on the desktop, overlaying the icons there, and on occasion overlaying every other piece of software as well, taking up pretty valuable screen real estate and mindscape, too.

</comment></comment></comment></comment><comment><USER18> I am not sure I follow - is the implication that some "creepy" person I met at a bar/cafe/etc. who knows only my first name will somehow exploit $RANDOM_IOT_DEVICE in my home? Even if you allow that they might be able to ID me accurately (say with a phone camera), they'd need to find my IP (which changes regularly, DHCP from my ISP), get through the firewall, and compromise the device. That isn't impossible, but it would make a better subplot for Mr. Robot than something I should spend time worrying about. It seems much more likely IoT devices will be exploited by scripts, running over ranges of IPs, and their "creepy" owners will be thousands of miles away from my home.

<comment><USER13> Do you have anything in your home that you might wish to keep private? Any texts with loved ones? How about any intimate moments, whispered nothings that you would prefer not be recorded?

Oh, you say you have nothing to hide.

Do you have a bank account? An investment portfolio? College funds for your kids?

A skilled attacker can make all of that vanish.

Without many people noticing, the IoT has slowly invaded the average American home. Almost every TV is a Smart TV, internet gateways are smarter, Alexa, Siri, Cortana, light bulbs, door locks, refrigerators, thermostats...

With a little effort, an average pen tester could own your system, publish your secrets, steal your life savings, record you with your wife, and brick your iPhone, TV, and furnace just for good measure.

It's time to take IoT security seriously.

*It actually was on Mr. Robot. There was a subplot wherein Darlene compromises an E-Corp exec's smart home, causes the appliances and security system to malfunction to drive away the occupant, and then uses the place as a hideout.

<comment><USER19> Even if you literally have nothing valuable to hide, consider that a hacked device on your network could be used for malicious things like DDOS, hosting illegal content, proxies for other attacks, etc etc.

<comment><USER20> More importantly, consider how much more empowered malicious state-backed entities become. At the moment we can only be surveilled (which is plenty terrifying). What happens when we can be physically influened remotely at scale

</comment></comment></comment></comment><comment><USER21> How is a consumer supposed to answer any of these questions for themselves?

<comment><USER22> Just don't buy smart-house equipment in the first place, if you ask me. Dumb houses are good enough; and unless you're talking about panic buttons to call the police, more connectivity means more vulnerability.

(Now, to find a TV that doesn't have a microphone.)

</comment></comment><comment><USER23> It entirely depends on the thing. If someone hacks my light switch all they can do is turn the light off and on while revealing to me I have a problem I have to fix. Anyone can call my home phone number and turn on my car plug for 4 hours. All they will do is waste a small amount of electricity. If they want to disable my alarm and open my door, well that will be a lot harder, particularly if they want to try to do it remotely.

If there is anything that can, say, let someone remotely cause a fire then the problem isn't security. The problem is that you have something under software control that can cause a fire. Chances are that regular faults will burn down the house much more often than "hackers" will. Note that such faults can be caused by things like lighting hitting the power lines somewhere in your city. They don't have to be actual bugs.

Of course the "internet of things" is kind of a joke right now. What with the lack of any sort of standardization it is unlikely that the owner will be able to usefully control things much less some remote attacker.

<comment><USER24> I looked into electronically controlling the lights in my house 15 years ago. I was hard pressed to see any value in it. Walk into a room, flick it on. Walk out, flick it off. The light is for the person in the room - why flick it on and off when nobody is there?

(Yes, I know about deterring burglars.)

<comment><USER12> My roommate has an extremely annoying habit of leaving lights on, despite constant reminders of "hey turn off the light." We otherwise get along pretty well, so it wasn't worth fighting over. So I modified the switch to add remote control using a simple wifi controlled switch and also added a motion detector. Now the light turns itself of. Sure it's overkill, but it really is convenient and made for a fun project, plus it only cost about $10.

Similarly, our HVAC puts out most of its air upstairs and we use a fan to help move air down the stairwell. I set it up to coordinate with the HVAC to turn on and off in time with the cycles and also to turn itself off in the evening when we are all asleep and back on in the morning. Again, not essential but fun and handy.

The HVAC itself is also controlled by a somewhat complex system that I made over the course of about 6 months. It makes a big difference in keeping the house temperature even and also saves something like $10 per month in electricity. My point here is that well targeted smart home devices can be really handy. On the other hand I made this stuff myself specifically tailored to my needs. IMO, it's hard for commercial products to really hit the sweet spot between being easy to use and yet adaptable enough to fit into everybody's life tightly enough to not be annoying.

<comment><USER24> LED lights consume not much power. How does that compare with the power used by a wifi + motion detector system running 24/7?

It's pretty clear that an HVAC system that is on a timer can save considerable power. I have a programmable thermostat for that reason, but the user interface for it is so awful I need to reread the manual every time. It would be better if it was wifi and presented a web page as a UI.

I also bought a programmable cat feeder. Again, one needs a manual to figure it out. What is wrong with those engineers? You shouldn't need a freakin' manual to set up a cat feeder. And the UI couldn't be satisfied with 5 buttons, no, you've got to do chording and hold buttons for various amounts of time to do various things. It's complete madness.

(I don't want the cat feeder hooked to the internet, though. I'm suspicious the cat has been plotting against me, and it might be able to coordinate with other cats via the cat feeder interface, which could spark the cataclysm.)

<comment><USER12> > LED lights consume not much power. How does that compare with the power used > by a wifi + motion detector system running 24/7?

It's barely a rounding error. Sleeping the microcontroller, average current draw is a couple mA. LED lights draw around 500 mA.

Regarding the HVAC, what I made is more focused on keeping the temperature balanced by taking a weighted average of temperatures across the house, with the weights adapting to where people are, similar to the Ecobee thermostats but DIY. It also has a web interface where you can view temperatures and power usage, which is far more useful than I thought it would be.

</comment></comment></comment></comment></comment><comment><USER25> The author poses some interesting questions, but unfortunately doesn't provide really useful answers.

How is the avarage consumer going to find out the security reputation of a vendor of smart home devices? How to find a reputable vendor for such or such device like a baby monitor, security cam, smart lightning or wifi repeater? In an easy way and easy to comprehend?

Is there a website to check to security of smart home devices, or a list of reputable vendors? That would be a first step.

</comment><comment><USER26> Let me grab this occasion to ask: WTF is going on in general? I readily presume most people have a wifi router with these iot devices and while obviously those are not the best security wise (I presume again most don't run pfsense or openwrt) but still they are there, NATting away happily. How would a baby monitor appear on the open web...? I can't imagine the average user setting them up in DMZ or port forward or ... what is happening here? I am obviously missing some primarily home networking oriented protocol probably because I am configuring my own routers and I am simply unaware of some feature of the factory firmware that allows traffic inwards.

<comment><USER27> I don't use those products, but I can imagine many of them automatically doing port forwards ([https://en.wikipedia.org/wiki/Universal_Plug_and_Play#NAT_tr...](https://en.wikipedia.org/wiki/Universal_Plug_and_Play#NAT_traversal) ) and possibly even automatically registering in a dynamic DNS service, all for the "convenience" of the "I don't know what a port is and I don't want to know" user.

<comment><USER26> > Many routers and firewalls expose themselves as Internet Gateway Devices, > allowing any local UPnP control point to perform a variety of actions, > including retrieving the external IP address of the device, enumerate > existing port mappings, and add or remove port mappings.

Are you bloody kidding me? Why do you even have a firewall, rudimentary as it is, then?

<comment><USER28> UPnP comes from the view that NAT is an unfortunate artifact of residential ISPs only giving out one IPv4 address per household, not a crucial security strategy.

If you really think of your NATing router as a security device, turn off UPnP. Though I'm not sure how much good that will do, as any device can still phone home or reverse tunnel.

<comment><USER26> Sure but port scanning and forming a massive botnet is impossible if they are not even capable of listening on an open port which NAT gives you for free. It's like the lemonade you could make when life you gives you lemons. Except now it's spoiled too.

<comment><USER28> On the other hand, UPnP is the only currently viable strategy for average people to run devices on their home networks and control them from the internet without looping in a third party server.</comment></comment></comment></comment></comment></comment>


Show HN: Ipinfo.io – ip details api - <AUTHOR> https://ipinfo.io <comment><USER2> I like this API but one piece of information [https://ipalyzer.com](https://ipalyzer.com) included that I think lead you to post your API is spam scores and whether the IP is blacklisted by anyone. I think this extra information would be very useful if you can also get that.

</comment><comment><USER3> Rubyist here, no one is going to use Excon (what i never used or heard of) instead of open-uri which is already built in. I assume open-uri and json to be the very same than your Excon call.

Like: JSON.parse(open("[http://whatever.io"](http://whatever.io")).read)

<comment><AUTHOR> Thanks. I'll update the example.

<comment><AUTHOR> Updated.</comment></comment></comment>


KeyBox – A web-based SSH console that executes commands on multiple shells - <AUTHOR> https://github.com/skavanagh/KeyBox

<comment><USER2> Comments moved to [https://news.ycombinator.com/item?id=8649518](https://news.ycombinator.com/item?id=8649518).</comment>


Grub-snub strikes again: another restaurant scammed through ordering service - <AUTHOR> https://www.abc6.com/grub-snub-strikes-again-another-providence-restaurant-scammed-through-ordering-service/ <comment><USER2> Welcome to the restaurant delivery business.

Next up. "Getting Grubbed" using a stolen credit card to order 5 all the way pizzas to someone that beat you in an online game.

<comment><AUTHOR> The situation surprised me having been on the other side fighting GrubHub over missing food...getting $11 back from them is pulling teeth, but this guy stole nearly $400, and $288 on two occasions, and GrubHub refunded the _entire_ order within minutes over a claimed "incorrect order" and only refunding the restaurant after media stories</comment></comment>


What are your thoughts on the new Ustream Home Page? - <AUTHOR> http://ustream.tv

<comment><USER2> I was there recently -- maybe two weeks back? -- and the HP was a mess. This new one is great. Clean and easy to see what's what. I also love the LIVE banner on things.

<comment><USER3> I respectfully disagree. Looking at the website is sensory overload. There's too much information for the brain the process quickly.

The search bar should really be the focus of the homepage, and not everything else. When I visit a streaming website, I'm typically searching for a particular stream, and not just browsing.

The featured stream bar is annoying and there's really nothing to distinguish the different "Recommended" and "Recent Highlight" categories. Maybe it would be better to merge them into one category, and eliminate the "Community" "Trending" and "Events" panel.

The scrolling "Featured" bar is annoying and distracting.

Keep it simple.

</comment></comment><comment><AUTHOR> We organized the page to showcase our top content/broadcasters, highlight joining crowds, and to simplify the navigation between categories.</comment>


Google's Holiday Gift to Devin Nunes - <AUTHOR> https://popular.info/p/googles-holiday-gift-to-devin-nunes-afd <comment><USER2> Just read the FBI OIG report. Then read the Nunes report. Then read the Schiff report. It's pretty clear who was spreading lies.</comment>