korm

From my research and experience the operating room effect is largely due to bad color rendering with most (cheap) LEDs.

Good artwork/video/photo lighting with LEDs is very expensive and bought from specialized shops or the manufacturer, but it's the closest I've found to true sunlight.

If you'd like recommendations I like the Yugi strips.

Step 1 becomes progressively easier after each wash. Steps 2, 3, 4 are completely eliminated by having an in-unit washer as you said, like most families in western Europe do at least. Step 6 is also pretty quick with practice.

To play devil's advocate, this has always been the case with React. Newbies always mutate props or use setState incorrectly or in the wrong lifecycle methods. We've relied on linting to solve this for a long time now.

Are you against using Babel and the class properties proposal? Binding members shouldn't have been a problem in your codebase in recent years.

I think you're talking about context, which isn't specific to hooks. Hooks give functional components features that only existed for classes.

First of all, context is slow, at least currently. Secondly, it's just a vehicle for delivering deep updates. It should be used when local state is not enough, but it's only an intermediate step before needing redux-like state Management and all the convenience it provides.

But... It's not a choice of one or the other, both global and local must be used appropriately.

Also the shape of your global state plays a big role in its maintainability and redux provides good tools and documentation to achieve that.

You'll eventually need data in the global state in anything but a toy app.

Thanks, this is incredibly useful, I use everything in this package! It also doesn't deviate from the spirit of Redux or abstract too much, like rematch for example. Without something like this, I find that many people structure their entire Redux code based on simple tutorials. They typically only read the docs or worry about best practices and complexity after they encounter problems. This kit will have them start off on the right foot.

> but you'll excuse me being skeptical that introducing more complex tools will solve my complexity problem

I'm a consultant and in my experience this misconception is by far the most common source of problems in redux projects. Redux is a very small and simple thing so you have to build a framework around it. Even redux-thunk isn't enough - that's only 5 lines of code.

I wouldn't recommend react/redux for public facing sites if there's no experienced, pure frontend team. A more batteries-included kind of framework would be better. There's a lot of thinking to do and hardcore levels of scaffolding to maintain before writing anything useful and maintainable with redux. But it can absolutely lead to maintainable applications.

Also, I've never seen any homegrown "vanilla" frameworks or data stores work well as complexity increases. It usually ends up as spaghetti, especially with a growing team + growing business demands. Or best case a poor re-invention of the wheel. There must be brilliant counter examples but they're probably rare, I may never have the pleasure of working with one.

These features existed in the form of 3rd party libraries like react-loadable for code splitting and recompose for hooks. I don't know any serious React devs who haven't used code splitting in the past few years, and recompose was very popular as well. We just have a canonical way of doing these things now.

I hope we don't go back to MVC for everything. I think we just have to use the right tool for the job. If an app is highly interactive or will have frequent data updates, or if it's supposed to be used almost like a native app, a SPA is the perfect way to achieve this. If it's going to be like most sites, traditional MVC will probably be better.

Not that react isn't great for traditional websites, I've just seen too many fullstack or backend devs struggle with it, so if they're going to be involved in the frontend it may be worth considering the alternatives.

When Reddit rolled out their new mobile site I had strong suspicions the org must be a mess internally. Out of all the problems one stuck out to me. For many months the comment sorting dropdown took 15 seconds to open from a warm start. That is a billion dollar company making newbie mistakes with React as if it was an intern doing the rewrite.

But the situation employees like you have been describing is surreal, I would never have imagined.

Curious why, React can do that just fine. It doesn't force you to build a SPA. What's different with Vue?

Oh-my-posh + a few custom scripts for better autocomplete that I found here and there. Wasn't very easy to configure and it's still nowhere near my fish shell, but at least it's much better than plain powershell.

I assume the point is that some people bog themselves down with tools that make them less productive just because they read that it's best practice, without deeper understanding.

For example, in most threads about Vue on Reddit, the fact that you can just add Vue as a script tag and start working with it is it's most frequently cited advantage.

A small app, especially for most newbies just starting out, doesn't need webpack. But obviously they didn't read the docs and didn't even try the same with React. They just went straight for webpack, even though they shouldn't have. Not to mention CRA exists.

Same with immutable and saga. Their benefits are apparent in much bigger applications, and even then there are arguably simpler and better tools like Immer, update-immutable, redux-thunk, redux-promise-middleware or even rolling out your own middleware.

It's about choice. 2 billion people with Androids aren't sysadmins. The phones work fine out of the box. The parent likes choice, while some people don't miss it. No need for strawman arguments.

I just don't think the online news media will learn anything from tangential HN discussions so we might as well do away with these types of comments and either discuss the article's content or not visit the link at all. I think that's the proper etiquette, unless of course there's something exceptional worth noting.

I too wish this terrible UX was an exception, don't get me wrong.

I didn't defend anything and I'm not a media employee. I complained about a common type of comment that is low effort and doesn't advance discussion, in my opinion at least.

The state of news sites is well known to everyone on HN. It's not nice to have this same comment pop up every time instead of discussing the article.

There are article outlining services and add-ons you can use. I really don't mean to offend, I just think it would be better for HN if this wasn't one of the first comments on every thread.

The history features are incredible and also the only ones I use, eg diffing, showing changed dirs/files/lines, blame, file/dir commit history.

I've never used it for anything else git related because the ui is strange.

I think if the conversion is led by a very experienced React developer this could be a good decision. We decided to write all our sites in React a long time ago and couldn't be happier. It doesn't have to be a SPA because it's React, we have static sites too.

Judging by how your org made the decision without the devs input though, I'm not too confident it won't be disaster. It's depressing but I've been offered too many contracting opportunities to rescue a project after a similar conversion that is a total dumpster fire.

Here are my personal opinions as a long time Dart/JS/TS developer.

- Dart had a lot of features before either JS or TS. Important features like cancellable promises or optional chaining are still missing (I know they might be coming soon). Also some nice quality of life features like named constructors.

- As a superset of JS, Typescript has a lot of idiosyncrasies that might bother people. Personally I don't mind, but people new to web development often find Dart to be a friendlier experience, with fewer pitfalls.

- To me, and this is very subjective, the TS syntax is uglier than either JS or Dart. The types get in the way and add noise to the code. I find Dart's and pretty much any other language's type declarations much cleaner.

However, I have two very big problems with Dart that prevent me from using it as much as I'd like to.

- JS interop is much much cleaner in Typescript/Flow. Every compiled-to-JS language that isn't a superset suffers from this. It's what prevents me from using ReasonML seriously too.

- No support for JSX. I can't go back to writing nested createElement after using JSX

This is not a fix, on mobile 100vh and 100% are different due to the auto-hiding address bar.

Safari is not as bad as IE was compared to other browsers. However, calling it the 'new IE' is accurate if the definition is 'the browser with the worst support of new features and most bugs'. Here is a comparison http://html5test.com/compare/browser/safari-10.2/ios-10.3/ed...

What is especially frustrating for web devs is that all browsers on iOS are Safari underneath. We have to deal with those weird bugs and missing features the same painful way we dealt with IE, hence the title of the article. Saying that it's not as bad is not the point, IE 11 was also not as bad as IE6, we still had to deal with its quirks.

React 16 (Fiber, release candidate) has pretty much the same performance as Vue https://rawgit.com/krausest/js-framework-benchmark/master/we...

Angular is close enough too.

Not sure I understand your question. Functional components and class components both use createClass internally IIRC. In any case, they are the same. A PureComponent is simply a Component with shouldComponentUpdate written for you. Functional components can't be pure, but you can use an enhancer for them.

> When using immutable data structures the comparison in `shouldComponentUpdate` is very cheap.

The equality check is always the same in pure components. Whether the data is immutable or not, pure components do a reference equality check. This will result in failing to update correctly with mutable data.

For simplicity, I guess you could go with PureComponent by default, and remove it as an optimization instead, which is what I've been doing with good results.

A functional component is not pure, it's exactly the same as its class counterpart. You can use recompose's[0] 'pure' HOC to turn it into a PureComponent.

[0] https://github.com/acdlite/recompose

pub global activate dart_repl

pub global run dart_repl

And I'm sure Go has a repl too.

I agree with your last point, it's hard to trust, which is why I err on the side of caution and try to avoid sites pushing one radical opinion over others. Paleo, vegan, atkins, there are tons of people, physicians included, insisting their research is the best. So I think it's prudent to hold a more moderate stance on nutrition, an attitude of 'we don't know, let's find out' instead of 'I know best, trust me'.