My struggle to learn React - <AUTHOR> http://bradfrost.com/blog/post/my-struggle-to-learn-react/ <comment><USER4> Honestly I don't know how I learned React. It's not fun at all. Oh sure, the basics of React is not too hard. If you ignore all the outdated examples and code (using var, no JSX, overusing component lifecycle, not using functional components). But then learning Redux, React Router, React JSS, Reselect, Redux Thunk, Webpack, etc., is just terrible. Sure, there are tutorials for each individual library, or maybe even two or three of the libraries at once. But combining all of them and making sure that it's not a total mess of code is like trying to play QWOP with your code. Now that I have everything compartmentalized and understood, it's pretty easy. But getting there is a long long journey.

I've played around with an idea for a tutorial on modern web development that starts with just basic JS DOM fiddling, then introduces various features and techniques as they're needed. So you'd start with just using old school document selectors. But then, as all the getElementByClassName calls become annoying, maybe you'd introduce transpilation, so that you can querySelector with a map/filter. Then, as the updating starts to get hairy, you could introduce a library like React. As state becomes an issue, Redux. But the point would be to start with the basics and build up an understanding of _why_ we need these libraries. And what problems they solve and what problems they don't solve. But of course, the moment anybody writes this tutorial, half of it will become outdated. Ah well.

<comment><USER5> So don't use Redux, React Router, and Thunks. I don't even know what React JSS is. Use create-react-app's tooling.

Even Redux's author tells people Redux is overused. A pretty big percentage of the value of the flux pattern is just in having an event pubsub system, so if your application is so complicated that you really feel like you need to structure it, you can just use EventEmitter.

I frankly don't understand the popularity of React Router. The core thing React Router accomplishes can be done in ~50 lines of code including the switch statement for "routes". If you like and grok React Router, use it. But I don't think it's a good idea to push through your resistance to it.

<comment><USER6> I mean this in a nice way, I'd really appreciate a gist showing how you get the core concept of react-router in 50 lines. It's in a project of mine now and maybe it shouldn't be.

<comment><USER7> Well, it really boils down to

      const path = findThePath();

      class Router extends Component {
        render() {
          if (path === "/about") return <About />
          else if (path.match(someRegex)) {
            const data = parseSomePath(path);

            return <Page { ...data } />
          } else {
            return <Default />
          }
        }
      }

Seems as though React Router has gotten a bit complex because it's abstracted away from the concept of a webpage, such that one can use it in the browser, or React Native (which can be a number of environments).

Of course, I say just buck-up and learn the damn thing, it isn't that complex... earn the "Engineer" in your job title!

Maybe I'm just an out-of-touch neckbeard these days?

<comment><USER8> React Router v4 is _particularly_ difficult to get used to when compared to earlier versions. While I don't much mind it (I get it working, then I don't need to touch it anymore), it definitely took me some time to wrap my head around it.

So yeah, it works good when you get it working, so yeah, the best thing to do is to just buck up and learn if it you need it. But boy does it suck getting there.

All of that said, I don't understand where this view comes from that Redux is extremely confusing. It can indeed sprawl a little. Say, if you keep you containers, reducers, and actions in their own directory trees. The overall architecture didn't take me very long to grasp and start to leverage.

Plenty of folks find their home in Flux or MobX instead, but I'd have to guess that a lot of the confusion is _actually_ confusion about state containers and their uses.

<comment><USER7> Partly, the fact that React-Router has upgraded so many times in divergent ways in a short amount of time has left many folks with a bad taste in their mouth.

If the router was just "Buck up, learn it, and you're golden" I suspect we wouldn't hear too much hollering about it. Unfortunately, the hassle of using it is so close to clockwork I feel like I should just schedule a week every six months or so for maintenance.

<comment><USER5> What's the win to keeping up with it? Am I wrong that the problem it's solving is really pretty simple?

I had the same problem with react-bootstrap, which I used for about a year and ran into regular upgrade compat problems. I wouldn't mind that much except that wrapping a React component around a fragment of HTML is not a problem so difficult that I'd endure compat problems in a dep to solve it.

<comment><USER7> > What's the win to keeping up with it?

With the router, it was never a matter of us just deciding to upgrade for the sake of upgrading but rather ending up being painted in a corner with peer dependencies requiring upgrade. Additionally, because we were a micro service / many SPA outfit, we ended up with a dozen or more applications at varying levels of libraries so you had to deal with 2.x, 3.x, and 4.x or just upgrade.

For those of you reading along thinking "This sounds like a dysfunctional environment!" You're right! Imagine having five heads of department, albeit two interim, in a year.

> I had the same problem with react-bootstrap, which I used for about a year > and ran into regular upgrade compat problems.

I'm in the middle of building out an internal component library based on `react-bootstrap`, so that's fun to hear...

Have your issues mostly been upgrades of the library? Or of Bootstrap versions? We internally decided we're just sticking with Bootstrap 3 for the foreseeable future with the hope that it will mean we don't have many issues to deal with.

<comment><USER5> It's been a long time since I used react-bootstrap. I just stopped using it and wrapped the Bootstrap HTML myself. I wouldn't be surprised if it had settled down.

It's possible react-router has settled down too, but the experience I had of "I can't believe I ever wasted time trying to figure out react-router" after implementing a "router" myself was so powerful that I'm pretty averse to finding out.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> I've been doing web development for over 15 years, and I've seen a lot of trendy web application / UI frameworks that are going to be the The Final Paradigm come and go.

That experience has taught me an important lesson about trendy framework stuff: If it doesn't make sense to a lot of people after a lot of thought, and there's a lot of rationalization required to plug that gap, it's probably not working out very well.

As of now, I have still yet to see a JS framework that made any sense to me. They're all really weird to me and solving problems I've never had with UI development, or regressing previous best practices in ways I don't think make any sense.

I'd much rather just use template rendering than this stuff most of the time. At least with that, you're just using Real JavaScript (TM) and you don't have to learn some new special HTML attribute based language.

<comment><USER10> Honestly, something like React/Vue has got to be as close as it gets to "The Final Paradigm". At this point, it's been a long time since I've seen a new paradigm that does anything vastly different or more productive and simple than JSX + React/Vue lifecycle & state hooks. Most of the new UI libs that come out (Glimmer, Marko, etc) seem to be heavily influenced by React and don't offer a giant leap in how UI is done.

I think there's plenty of more opportunities in state management, CSS management, application structure, tooling, and making those more simple, but generally I think the view layer is more or less solved.

<comment><USER11> It's funny to think retrospectively that something like Backbone.js absolutely did not solve view state management at all and people adopted it because it somehow looked like Rails with big models, Angular.js misunderstood the issue completely with factories everywhere instead of a single dataflow.

The new paradigm would be the browser handling all that and there is no need for frameworks anymore. We are not there yet given how poor web component support is : [https://caniuse.com/#search=web%20component](https://caniuse.com/#search=web%20component)

<comment> 52-6F-62 I think you nailed it (though I think Jeremy Ashkenas and Mike Bostock and that NYT group are brilliant... especially working in the media space at a company that doesn't encourage that kind of work to put it mildly).

I've had my whimsical entries into experimenting with Web Components, but they just haven't felt like they're quite there—ignoring the lack of support. They're workable, but I think design patterns surrounding current paradigms might need more readily addressed. As they are, you'd probably want a framework on top of Web Components to improve the semantics and just make working component state in generally less verbose.

I have a hastily-written example here playing with them:

[https://robert-fairley.github.io/es6-webcomponents/](https://robert- fairley.github.io/es6-webcomponents/)

(No repo, it's not worth it. Just check the source–it's short enough)

</comment></comment></comment></comment><comment><USER5> This is a fine article.

But I just want to say, as an alternate data point, my experience has been _exactly the opposite_. I _love_ React. React is the first front-end technology I have ever managed to get to stick.

* ES6 is just a detail, I know. But for me, ES6 transforms Javascript from an idiosyncratic scripting language where I constantly have to look up the ordinary way to handle basic programming tasks into something resembling a modern high-level language. To me, ES6 turns Javascript into Ruby. I don't love programming in Ruby, but I can do it quickly and without the language getting in my way.

* The basic idea behind React, that your UI rendering code is always working with a snapshot of the current state, and 95% of your job is just to take that state and re-render it wholesale, eliminates a huge amount of the cognitive load I experience trying to do front-end stuff. I allows me to stop thinking in state machines, and just write straight-line code. If you've been primarily a backend person and have always sort of hated doing front-end stuff, check out React and see whether it's just the programming model that's been bugging you.

* Unlike the author, I've always been more of a programming person than an HTML/CSS person; I would kind of rather eat a bug than fiddle with CSS. One thing that makes React so nice for me is that you can just buy an HTML template and gradually turn it into JSX to "animate" it into a UI. Another thing is that it so nicely decomposes into components that there are a bunch of high-quality UI component libraries to draw from.

I have a lot of the same problems with React that everyone else does:

* "This" and the JS class model still feel like own-goals and I'm regularly tripping over them. But I'm never stumped by them; the bugs are always pretty obvious and easily fixed.

* Perf has been an issue, particularly memory consumption. But to me, this just suggests that I'm actually productive in React, that I'm getting to the point where I'm comfortable enough belting out code that I'm generating perf problems to go fix. (This has come up on relatively complicated UI projects, like the debugger interface we did at Starfighter, which was a monstrosity).

* The tooling was a disaster before create-react-app. But now there's create-react-app, so the tooling isn't a problem.

* I still have no idea what the right way to test things is.

I'm not rebutting the article at all! Different people, different issues. I just thought, if that perspective was valuable, mine might be too.

<comment><USER12> >>* The tooling was a disaster before create-react-app. But now there's create-react-app, so the tooling isn't a problem.

But what happens when you inevitably need to step outside the boundaries set by create-react-app? From that perspective, it simply _delays_ the problem, rather than solving it.

<comment><USER5> I don't know, because haven't needed to step outside those boundaries. I'm sure it will be painful when that happens, but by that point, I'll have gotten so much done that I probably won't care too much.

I had a gulp build process I used before create-react-app; it was gross to get working, but then worked just fine. I could live without create-react-app, but why would I?

<comment><USER8> If you hit the point where you're considering ejecting, check out react-app- rewired. If you just need additional Webpack plugins, react-app-rewired can do that for you without the need to completely eject your app.

</comment></comment></comment></comment><comment><USER13> I think I can understand the struggle of the author. I experienced JS as a non-robust / fast-moving programming environment. Frameworks, Buildsystems and Language Features that change every few month. So when I first heard, that React is the new thing and everyone should use it, I did not want to use it. I use React now everyday and I really like it. But instead of writing it with JavaScript I use ClojureScript with a library called reagent([https://reagent- project.github.io/](https://reagent-project.github.io/)). So changes in JS or React aren't really my problem and CLJS seems to be a reasonably finished language. But I do not want to rate whether it makes sense to trade the weird React syntax for a Lisp.

<comment><USER14> > and Language Features that change every few month

On the other hand, there was a period where JS devs could use one new language feature in a decade. And when it did come, it was ActiveX. (I'm exaggerating, but not by much.) From this perspective, it was kind of inevitable that at some point JS will overdo this and become a kitchen sink.

I tried using ClojureScript in its early days, but the JVM ecosystem was painful. I don't see a point in having very similar, but not 100% compatible languages on backend and frontend. Either you use the same language, or two different languages, in which case you can as well use something you like more on the backend.

Some time ago (a year or two, I think?) CLJS got bootstrapped - is it finally possible (and practical) to use with node only?

<comment><USER13> > I don't see a point in having very similar, but not 100% compatible > languages on backend and frontend.

I have an applications consisting of frontend cljs code, backend clj code and some code that will be compiled to both ends (called cljc). Even if its not 100% compatible, I think its helpful that I only have to write data validation (e.g. clojure.spec) once and can use it in every part of the system. Also if you wrote pure algorithms for complex data structures, its nice to use it in cljs and clj. The parts that are missing to 100%, can often be bypassed with a simple reader conditional ([https://clojure.org/guides/reader_conditionals](https://clojure.org/guides/reader_conditionals)).

> Some time ago (a year or two, I think?) CLJS got bootstrapped - is it > finally possible (and practical) to use with node only?

I dont have much experience with this, but I think that shadow-cljs ([http://shadow-cljs.org/](http://shadow-cljs.org/)) will make this mostly possible.

</comment></comment></comment><comment><USER15> I'm surprised the tooling isn't mentioned more...

create-react-app is awesome and huge time saver but as soon as you have to step outside of that realm there are so many dependencies and other tools to get the sausage made that it's daunting for new-comers.

It's not at all fair to compare JS and Go BUT that is the one part of Go I really, really love- `go fmt` is built in and most of the tooling Just Works™ with minimal config (e.g. gometalinter). I find myself stuck when figuring out where the next piece of the JS puzzle should go in my local dev at times and how to make some other things production ready. But we're in a much better place now than we have been!

<comment><USER16> The equivalence of go fmt in React/JS would be prettier. It parses JS/JSX into AST and outputs them out using pre-defined formatting.

<comment><USER17> And prettier is much much better than Go fmt because it breaks lines for you

</comment></comment></comment><comment><USER18> I had the complete opposite experience... I've managed to stay fairly current with JS all along from ES5 through the influence of babel and other tooling towards ES6 and now. When I first started playing with React, I felt "finally!"

I had worked with .Net (both VB and C#) in the past as well as with ActionScript (Flex and Flash) and working with EcmaScript for XML (E4X) combined with XML literals in VB.Net was very natural to me... I'd wanted something similar to build from in JS/HTML for a very long time. React did that for me.

The flux pattern made sense, but most of the earlier libraries had way too much going on... when Redux came out it was such a natural fit to me.

When I look at other state management, or even Angular (1 and new) they just feel like _less_ to me.

<comment><USER19> There's also mobx which imo is even better.

<comment><USER18> mobx just feels dirty to me, kind of like ngrx instead of angular-redux on the angular side... I like the cleaner feel of a state reducer in redux.

</comment></comment></comment><comment><USER6> At this point, the JS ecosystem with React is a bit too complicated for a hobbyist to learn quickly. I have friends spending months with just React, not including other libraries.

But React is a tool for building complicated UI's, and overwhelmingly complicated UI's are requirements for startups, corporations and organizations, not personal sites or small toys. So like many other technologies, this one is perhaps best learned on the job, and it doesn't need to be optimized for the hobbyist.

That being said, losing the hobbyist comes with serious costs to community and innovation, a fine balance needs to be found.

<comment><USER20> Agreed. I am very familiar with most front-end stacks. I typically choose React for my projects, and I really love it. But when a beginner asks me "What is the best framework for me, having little knowledge of front-end dev/ecosystem?", I almost always just recommend Vue.js. I personally don't mind the setup of React, even for small projects, but I wouldn't wish that upon someone jumping into front-end dev for the first time.

</comment></comment><comment><USER21> At the risk of looking like a shill for my own stuff, I'd suggest an alternative way to learn React.

Part of the difficulty is trying to understand it all "from the bottom up", where you can't see the big picture because you're getting constantly tripped by ES6 vs. JSX features and trivial differences in component declaration syntax and whatnot. Instead you can learn it "from the top down" using React Studio:

[https://reactstudio.com](https://reactstudio.com)

It's an application modeling environment that lets you experiment visually with concepts like data binding and immediately see how it affects the resulting JSX code.

Because you're always working on a complete web app (rather than e.g. isolated components), it can be easier to understand the full picture of how things fit together. For example, you can start by simply placing some elements in a screen, then move them into a component of their own, then bind the contents of those elements to some props that come through the component, and finally use that component within a list that gets populated from a real data source. (Speaking of working with real data, there's a great plugin for Firebase Cloud Firestore [1] that lets you do realtime database reads and updates.)

Under the hood, the exported projects are using Facebook's create-react-app. There's no proprietary framework layered on top, it's just plain React with minimal dependencies (no Redux, etc.) There's also git integration and a rather elaborate plugin system, so you can modify the output and integrate custom code as needed.

This "top-down" approach isn't right for everyone, but might be a good fit for a UI designer skill profile. You get to build applications and learn modern JavaScript along the way by examining the output, rather than having to figure out everything from scratch.

(Disclaimer: I wrote a big chunk of the React Studio UI and code export.)

[1] [https://hackernoon.com/the-easiest-way-by-far-to-build-a- rea...](https://hackernoon.com/the-easiest-way-by-far-to-build-a-real-react- firebase-web-app-5dc6fa6f1b61)

</comment><comment><USER22> Note that I've felt the same way for a long time. I ended up giving up and checking Vue.js and it instantly clicked.

</comment><comment><USER23> I think this is the reason so many are picking up Vue rather than React or Angular these days. Vue offers the component approach and is generally fun to learn IMHO.

<comment><USER24> I have done both Vue and React projects. I like React philosophically. But my coworkers, who were keen to learn react, struggled conceptually and I ended up doing a lot of the React work. Then on another project we trialed Vue which worked out far simpler for people to learn and I also find I'm far quicker developing things using Vue. So while I'd tend to recommend Vue, I'd encourage people to trial both on something not too trivial before settling on either.

</comment></comment><comment><USER25> My skill set used to be very similar to Brad's. I followed his blog for years and learned a lot from him. Several years ago, I decided that there seemed to be better jobs for people who could write JavaScript, so I started teaching myself. The learning curve was insanely difficult. There were so many tools, syntaxes and buzzwords that I had to navigate and on top of that, it felt like things were changing every week. I'd post a question on StackOverflow or IRC about how to do x, and the answer would be that first I had to do a-w. I feel like this is what Brad is going through now. But by the time I got to learning React, I had already been writing ES6 for over a year and I had figured out the worlds of Grunt, gulp, Webpack, Babel, etc. And I knew some fundamentals like functional programming. Having all of that background made React extremely easy. I've never felt that I've used a technology or framework that's so easy and straightforward. Redux took a little bit more effort for me to wrap my head around, especially when trying to sync application state with a database, but I think that's difficult for a lot of people, which is part of the problem that things like GraphQL and Apollo solve. And even though Redux was more challenging, I found it to be a really useful pattern that ultimately helped me keep apps way more organized as they grew. All of that being said, I empathize with people who are trying to learn all of the parts of being a developer from ant high level entry point like React. There are a lot of contextual things that you have to know first and it can be overwhelming to someone who hasn't yet had the opportunity to learn those things. The biggest problem, in my opinion, is that things in the JavaScript world are moving so fast and the APIs for things are changing faster than people can keep up. I can't remember the last time I read Getting Started docs or examples that weren't already outdated by the time I was trying them out.

</comment><comment><USER26> This is more of a criticism of modern web development, and not specific to React. A modern web developer has to install node, webpack, babel/typescript, react, redux, sass/less just to write HTML, Javascript and CSS. It's especially frustrating for newbies since ES6/JSX and React always seem to "travel together." But you can write non-ES6 and non-JSX React.

\- [https://reactjs.org/docs/react-without- es6.html](https://reactjs.org/docs/react-without-es6.html)

\- [https://reactjs.org/docs/react-without- jsx.html](https://reactjs.org/docs/react-without-jsx.html)

This is what all the JSX and ES6 compile down to. It's just not as fun.

But React at its core is very simple: Same props always render same UI. Different props always render different UI.

      add(1, 2) -> 3
      add(2, 1) -> 3
      add(2, 2) -> 4

That's the core principle. And it is the drive to organise your code into declared props that naturally drive how your React code is organised.

      add({'num1': 1, 'num2': 2}) -> 3
      add({'num2': 2, 'num1': 1}) -> 3
      add({'num1': 2, 'num2': 2}) -> 4

It's a reaction to the unpredictable nature of "typical" jquery code where data and actions flow in both direction and it became difficult to pinpoint why something changed. If you clean up how you use jquery and are disciplined about it, you will eventually build something like React. There's no magic to React. The virtual DOM is not React. It's just an optimisation.

Same with Redux. When you eventually start writing large React applications, you will eventually end up re-inventing something similar to Redux.

</comment><comment><USER27> I originally started with AngularJS and hated it, I was learning javascript alongside it and I couldn't stand the abstraction layer, I felt I wasn't learning anything except how to make things 'work' in angular. Then comes react, I get to see all my logic right along with my html/css! It was great, I learned how to debug, where things were going wrong or right and then began to work on the better practices and work flow. They take time and deliberate practice to really understand 'why'. THEN add redux and see how you can use it to help your app communicate. Multiple component-prop passings/pervasive callback chains all start to disappear and that's great. I can't stress enough how sexy and clean a productive vanilla react app looks to me now. I also just started a new job 2 months ago where we use modern angular(i actually really like it now). So it goes...

</comment><comment><USER28> I think this person needs to think in terms of a series of onboarding ramps. You aren't going to learn to fly a commercial jet from nothing. You might want to get a private license first. Before that you learned to walk, talk, read, write and add up.

In other words, learn JS proficiently without any libraries first.

Then learn basic react, maybe without all the complex toolchains - <USER2> include the CDN link that compiles the code on the page and grok React.

Then finally do some basic React coding without the Redux etc.

</comment><comment><USER29> _> 6\. i'm less competent at js than html and css_

This is why a lot of front end folks should look at an alternative like intercooler:

[http://intercoolerjs.org](http://intercoolerjs.org)

It is far less violent to deal with, with a much lower barrier to entry and satisfies most needs of most web apps.

</comment><comment><USER30> "My Struggle to Learn JavaScript" would be a much more accurate title.

</comment><comment><USER31> If you don't understand JavaScript, why is it a surprise that you don't understand one of its libraries?

</comment><comment><USER32> > 4\. Getting lost in this-land.

This is one of major design flaws in JavaScript; when one goes deeper into prototype land and using 'this' in closures/functions, facepalming happens all the time as the semantics is completely different to what one would expect in better designed languages like C++ and Java. So you have to workaround around these warts, making the programming akin to walking on eggshells. Especially if JavaScript is only one of languages you know well, and you have to switch back and forth between many different languages that are more-less compatible with each other in this regard.

<comment><USER33> I'll take EcmaScript over C++ any day :-)

But I started programming back in 83, before the PC industry decided that some bastardized knock off of Simula 67 was the one true programming model. In contrast, a language which traces its origins back to Smalltalk/Self with a longing to use some Lisp/Scheme techniques can't be all bad.

</comment></comment><comment><USER34> Have a look at Elm, Cycle.js, ReasonML with BuckleScript-TEA, GHCJS/Miso or PureScript/Halogen.

I tend to believe the problem with React is not React it is JS. Therefor most FWs mentioned above are not in JS (except for Cycle.js, but that uses JS functionally).

</comment><comment><USER35> More accurate to say 'My struggle to learn ES6'. My newcomers confuse what's ES6 syntax vs React specific.

</comment><comment><USER36> The examples don't work inline anymore, but [https://chibicode.com/react-js- introduction-for-people-who-k...](https://chibicode.com/react-js-introduction- for-people-who-know-just-enough-jquery-to-get-by/) was what made React click for me.

My approach to React was similar to Brad's, as I am far more proficient with HTML and CSS than JavaScript. I'd done plenty of wacky stuff in jQuery, and that tutorial demonstrated how React can iron out some of the problems that spaghetti jQuery can create.

I'll also add that part of the problem with wading into React is that, if you're a certain kind of frontend designer, you remember the browser wars, and you would often wait until tech was mature before you went out and used it in production. But React was adopted quickly and has changed quickly. React Native is even worse in that regard. So even if you learn how to do something a certain way, that knowledge could be obsolete in a year, or less.

</comment><comment><USER37> I've been doing React Native development in my spare time, and I've found that React is...finicky. `class` this and `extend` that, and if you get it wrong, the whole thing screeches to a halt. There are a few other comments noting that it's mostly difficulties learning ES6 and I would actually agree - <USER3> doesn't mean React itself is any less difficult to learn, due to the fact that the entire ecosystem depends on all of these ES6 features.

I was discussing this with another developer who had the same sort of impression - it seems like it should be simple, conceptually, but there are a myriad of details to keep track of to keep the build system happy, to keep the components happy, to keep JSX happy. Compared to learning Vue, the whole process is much more difficult.

</comment><comment><USER38> I feel React's best use case is as a view backend in micro-frameworks like re- frame in ClojureScript.

React only gets complicated when you use states and mutable props, or when logic is put inside components.

As a view backend it just becomes a FSM translating app state into pure views and nothing more.

</comment><comment><USER39> The takeaway I got is that it seems like the React stack has worse or non- existent separation of concerns and thus it'll affect how your frontend engineers work, possibly to their detriment if they're not proficient in javascript.

<comment><USER40> As a proficient developer I find react to be one of the first languages where I can group concerns correctly.

HTML, js and CSS aren't separate concerns. Each component is a separate concern.

</comment></comment><comment><USER41> I just have to mention Mithril.js ([https://mithril.js.org/](https://mithril.js.org/)) here as an alternative to React. It has built-in routing and XHR, and I think it is fairly easy to learn. Combined with the (optional) streams library, it makes developing web UIs extremely pleasant. Like React, it is also based on virtual DOM diffing.

As a very minor point, I think its surface API looks more JavaScriptesque. For example, the life cycle event componentDidMount in React is called oncreate in Mithril.js. Doesn't matter much, but looks better to me.

<comment><USER42> I second Mithril as a great choice. My latest spare-time project in Mithril a couple months back was a port to the web of an interactive fiction Delphi desktop app I wrote twenty years ago. That project also used Tachyons for (essentially) inline CSS so almost all of the app is just plain JavaScript/TypeScript. [https://github.com/pdfernhout/storyharp- js](https://github.com/pdfernhout/storyharp-js)

Mithril works well and has a small friendly community and works well. That said, it is the HyperScript API used by Mithril that I consider most essential -- and a similar API can be used with React instead of JSX. Several other vdoms support the HyperScript API as well.

== Some design and industry rambles

JSX is IMHO an unfortunate choice emphasizing making code look sort of like HTML to _seem_ simple to web designers at first glance because it looks familiar -- but in reality JSX actually makes development more complex by requiring more tooling and making debugging and refactoring harder.

React has in my opinion a lot of needless complexity and bad design enshrined as best practice through pushing JSX and also by encouraging storing a lot of state in components.

React obviously has good features too like widespread adoption, third-party add-ons (unfortunately mostly using JSX), mobile support, and server-side rendering. React used to have a huge licensing problem related to their non- standard patents clause (why I looked for alternatives like Mithril) but the React licensing issue finally got fixed a few months ago.

So, React used via HyperScript is not that bad -- but even that combination still has lots of accidental complexity relative to what most single-page web applications need. Of course, React+HyperScript is still a far better combination than, say, Angular.

I have been using Angular for my day job for the last two years due to technology choices made by people before I joined the project -- people who have mostly moved on and so have not had to face the legacy consequences of maintaining their choice of (a then alpha) Angular. Angular can be made to work, but Angular makes supporting a web app far more painful than it has to be -- especially when you know of better alternatives like Mithril or even React+HyperScript. Angular's HTML-ish templates create the same kind of issues JSX does, making debugging and refactoring harder. Plus then Angular adds my- way-or-the-highway dependency injection, Zones, routing, RxJX/Observables as other layers of complexity for little payoff. And all those interlocking choices in Angular make it harder to migrate away from them piecemeal. Still, at least Angular is in TypeScript and its dirty checking is not that bad -- so it has some redeeming qualities.

It's sad that so many technology choices get made based on fads or promotions by big companies or even licensing issued instead of based on the intrinsic merits of the technologies. Kind of like when I knew ParcPlace Smalltalk well and loved working in it but the world and job opportunities moved to Java and then JavaScript. Sun tried to license ParcPlace Smalltalk but ParcPlace wanted run-time fees, leading to Oak/Green/Java, and then IBM put marketing muscle into Java instead of its own Smalltalk, and then indirectly we got JavaScript as a copy-cat of some of the Java syntax even though the semantics were somewhat more like prototype-based Self. Although Self was never proven as a good language or IDE the way Smalltalk was given a different tradeoff in flexibility vs. maintainability of prototypes vs. classes.

That said, programming in HyperScript+TypeScript+Tachyons feels to me a bit like Smalltalk development used to feel -- still not quite as integrated, but certainly better than many worse alternatives and with its own advantages including no run-time fees and easy deployment. And modern computing power makes feasible the easier-to-reason-about redraw model with vdom and the Mithril approach (to update on any data change or network response) rather than to use a harder-to-reason-about dependency-based approach to hooking up UIs common in Smalltalk and used in many other UI tookits in different languages. And a functional model mixed with strong-ish typing of classes can sometimes provide the best of both worlds when designing.

<comment><USER41> I am also using Tachyons together with Mithril. I can't recommend it enough.

</comment></comment></comment><comment><USER43> Svelte - [https://svelte.technology/](https://svelte.technology/) has components written in HTML. It's compiled to vanilla javascript, which results with components that are faster, use less memory, & have a smaller payload.

Also, Svelte is easier to work with. A simpler API, Computed Properties, events. The Svelte Store is also nice. I'm forced to use React in a project, but I prefer to use the Svelte Store opposed to Redux or MobX.

</comment><comment><USER44> React is fine. The problem is:

1) Flux (Redux) 2) Ecosystem (Webpack)

It really feels like something out of Dr. Seuss labs, where things just feels hacked together and wants everyone fit into their use case. It's over designed and some of the process is not required for most projects.

We really need some pragmatic hackers to come in and simplify these things. Someone who can create an efficient alternative that will fit into 99% of web projects and not the 1%.

I do see Vuejs / Mobx are going that direction. But I think we need more of it.

<comment><USER18> Don't use Redux if you don't need it... Context objects are really easy now, and create-react-app hides the complexity of Webpack.

</comment></comment><comment><USER45> Am I the only one who felt compelled to fill in all those bubbles with color on the web site?

<comment><USER46> Haha. Naa. Same here. No wonder colouring books sells like crazy.

</comment></comment><comment><USER47> I can understand to a certain extent the need for advanced (complex) frameworks like React, Vue, Ember etc... if you're working on a sizable team and really complex front-end application. However if like me, you're used to the simplicity of Backbone.js you end up very quickly getting a tad frustrated with the hoops and loops you have to jump though to wrap your head around the frameworks and the development setup they all encourage you to use (webpack, framework cli, ...)

I've finally settled on Riot.js. It's easier in my opinion to consume in morsels and build up your development workflow anyway you see fit. I must say although the online documentation is good enough to get you going, I found the "Master Riot" course [0] was very helpful in synthesizing all the various concepts.

      [0] https://www.udemy.com/master-riot/

Edit: Seems the course is no longer free but I think for $10, it's still very much worth it. Ray is a great instructor and really makes getting up to speed on the framework a breeze.

</comment><comment><USER48> I know that feeling. To me as someone who is not fully immersed in the JavaScript world the problem was also that there are so many different parts working together. You are describing that in your article as well. It helped me a lot to really just focus on one part of the machinery at a time and completely understand what it's purpose is and how it works exactly before moving on to the next. For example, take 1-2 days to learn webpack, then do the same for JSX and so on. Things become a lot clearer quickly when you understand why each part exists and it will make a lot more sense why things are done in a certain way.

JavaScript frameworks are more like loose constructs that don't hide the interfaces between the different parts very well. This is not a good or a bad thing but it is very different from, for example, Rails which I found much easier to learn as a whole. You can accomplish a lot with Rails without even knowing about the different gems of which it is composed.

</comment><comment><USER12> For me, the process of learning React has been terribly frustrating. The ecosystem moves too fast, and the various training materials out there become outdated very quickly. I was going through one of them and got stuck several times, and after spending several hours I found out that the function call covered in the course had been deprecated.

</comment><comment><USER49> First I love the design of this website. I haven't seen a blog that was so simple and easy to read (hacker news style)... ALSO be this pretty.

Also I'm curious what podcasts you were listening to? Has anyone picked up a new language from listening to a podcast. I can't imagine getting much out of it without the visuals to go with it.

</comment><comment><USER50> the fact that the author spent so much time/money/effort to learn react, and it still isn't clicking... I don't think that's a good sign. I think react has an approachability problem - maybe it's a design feature, or an issue of speed and documentation.

Obviously, react works for some people. It clicks with them. But I think a lot of folks prefer something with more clarity. Things change so fast that guides go out of date and devs/codebases fall behind on whats best practice. and this isn't without significant costs on the people who are trying to learn or maintain.

Conversely, Frameworks like Rails (<3) and Vue.js are powerful but more natural to pickup, with a clearer surface area and better docs. Also different problem spaces in some sense too.

My point is: It doesn't have to be this way. This mess is man-made and not beyond clean-up, but doing so may require some changes.

</comment><comment> at-fates-hands I guess this is part of the whole divergence of the JS community.

This is one of the questions I ask at every interview I do now when looking for a new gig:

"Do you prefer one JS framework does it all like AngularJS, or do you like to mix and match your JS libraries like taking ReactJS and combining it with say AmpersandJS, BackboneJS, etc?"

This is where we are. One group wants to use ReactJS and add complexity as they need it. Others just want a complete framework (however complex, and let's be honest, Angular is pretty complex!) out of the box. I've always been happy with full stack frameworks out of the box for several reasons, but it's what I prefer.

I'd be interested to know where all of this ends up in the next 18 months though.

</comment><comment><USER51> I think the way developers tend to think about front-end is misguided. Front- end development can be just as complex as backend, and IMO is analogous to iOS / Android, but interacting with a different environment.

Having started in ASP.NET web forms, I wholly welcome React & Redux / etc., because those were painful years.

Also, in many cases, developers are paid quite well ( a doctor like salary in some cases). I don't see problems with the notion of "having to keep up with the industry" since we're paid so well to do so.

</comment><comment><USER19> I find it odd that he tried to learn it by having someone else implement something in it for him. That's like expecting to learn by having someone else do your homework.

</comment><comment><USER52> Use Vue and you can be happy. Use angular 4/5 and you can at-least be sane. Use React and then pull out your hair, lost in a sea of badly-matching libraries, versions and continuously outdated best-practices.

React is a nice engine. A modern web-app is a car. Personally, I prefer leaving to the framework designers the job of giving me a car. Yes, you have to like the car they give you, but at-least it will be standardised and well- tested.

</comment><comment><USER53> I can definitely sympathize with the issues that come from not being familiar with ES6. I'm working through a React Native tutorial currently and, while I've managed to understand some of it via context, there's some very odd looking syntax that I still don't understand.

Can't really comment on the rest of the React ecosystem until I get through the tutorial and start trying to do things on my own.

</comment><comment><USER54> Points 2-4 reinforce my suggestion to learn modern (es6/es7) JavaScript before taking on React. Vanilla JS alone can be tricky, see: `this`[0]

[0] [https://github.com/getify/You-Dont-Know- JS/blob/master/this%...](https://github.com/getify/You-Dont-Know- JS/blob/master/this%20%26%20object%20prototypes/ch1.md)

</comment><comment><USER55> The problem that I have faced repeatedly in the past is whenever I try to follow a tutorial, most of the time things don't work because React/other react libraries change so frequently and articles get outdated very quickly.

Where can I learn react and its other components if so far my only experience is in javascript and Jquery(similar experience as point 1, 2 and 3 in the article).

</comment><comment><USER56> I don't know that non-programmers should or need to learn react.

I understand that for employment - front-end devs need to learn react. I just question if websites have finally become more app-like, and hence require app- developers, not front-end developers.

They're two separate skills, and one cannot easily go from one to the other, nor should one expect it to be a smooth transition.

</comment><comment><USER57> I use react, react-dom and react-hyperscript. Write a component, render to the DOM. Transpile with browserify. End. Maybe there should a be tutorial that just does that, but no, people want to write a begginer tutorial that uses JSX, Babel, Redux, React Router, Webpack and GraphQL.

</comment><comment><USER58> I've also struggled to learn React, but for me it's because I learned ClojureScript/Reagent/re-frame first. I get demotivated because I vastly prefer those tools, but unfortunately there are many more job opportunities for JS/React than CLJS.

</comment><comment><USER59> Could have been titled "My struggle to learn ES6?".

Very little if any was specific to React.

</comment><comment><USER60> re: #5: At my previous job we wrote our own UI toolkit with React and css- modules. We had many dev-only views that we used to inspect and test our components. It worked great because it let you visualize all the states a component could have for a wide range of inputs, so you knew they were all being handled well. For example: If you get a long input prop do any of your styles break from visibility overflowing? If a nullable value is missing, are you styling it appropriately while showing a placeholder? Unfortunately it wasn't open source, but it's being done.

<comment><USER61> This is pretty cool. But I've seen it done at a handful of companies. Where they have component libraries written in house. All those companies never open sourced their work - and it seems to me that it's a lot of reinventing the wheel

</comment></comment><comment><USER62> I've been writing Java for 20 years and never for a moment had the least doubt about the value of 'this'. ES6 has been slowly morphing into Java yet it hasn't solved this basic issue very well.

<comment><USER63> Why did you decide to learn React? Could you share some resources you used to learn it?

<comment><USER62> Just the Facebook docs really. That and sitting with experts.

</comment></comment></comment><comment><USER64> I had quite a similar experience. The looking at the official site method is not an easy way to learn react.

In addition to that, one needs to keep reading the release notes because it is constantly evolving.

</comment><comment><USER65> I found React one of the easiest frameworks to learn and pick up but I had the benefit of learning React after working for a few years with Backbone and Angular. I found the opinions of the framework to be sensical and guided by the realities of web application development and developer experience.

> 1\. i haven't invested enough time on learning it.

I usually find the types of tutorials Brad references in this section to be very bad at actually connecting with the real process of using a framework. _What_ you're building is just as important as _what_ you're building it with. When you find the right project to use the right tool, it helps the principals click so much more quickly.

> 2\. react and es6 travel together

This is definitely a pain point but I think the crux of this is JSX. Most every other convention in React is a very straightforward use of ES6 syntax. Most of the awesome, difficult, but not broadly available parts (generators) of ES6 aren't used in React's public API.

> 3\. syntax & conventions

I think React could benefit from a clearer breakdown of how JSX translates to actual JavaScript. Babel's REPL is a good first step. [0]

> 4\. getting lost in this-land.

For the most part I've found React's use of JavaScript OOP and `this` to be the most sane. You can use what amounts to a bit of boilerplate in any component that needs state and use `this` within lifecycle methods without batting an eye. Backbone and Angular had all kinds of headaches when trying to explain `this` to junior developers. And don't get me started on libraries that used `this` to pass context around.

> 5\. i haven't found sample projects or tutorials that match how i tend to > work.

I think React excels at matching his ideal workflow, but doesn't do a good job explaining how to achieve it. Higher Order components and smart/presentation components are very under-documented.

[0]: [https://babeljs.io/repl/#?babili=false&browsers=&build=&buil...](https://babeljs.io/repl/#?babili=false&browsers=&build=&builtIns=false&code_lz=JYWwDg9gTgLgBAJQKYEMDG8BmUIjgcilQ3wG4AoczAVwDsNgJa4BhXSWpWmACgEo4Ab3Jw4RGNSjMAPABNgANzhoANigDO6gHIoQSALwAiTBAiG4AegB8FAL5A&debug=false&forceAllTransforms=false&shippedProposals=false&circleciRepo=&evaluate=false&fileSize=false&lineWrap=true&presets=es2015%2Creact%2Cstage-2%2Ces2015-loose&prettier=false&targets=&version=6.26.0&envVersion=)

<comment><USER66> > I think React could benefit from a clearer breakdown of how JSX translates > to actual JavaScript.

I think a key factor here is that JSX is JavaScript but it pretends to be HTML. Things like `className` vs. `class` aren't insurmountable but it seems to be a common source of confusion until people have internalized that divide.

</comment></comment><comment><USER67> It's hard but eventually clicks.

Create-react-app has made it infinitely easier to learn.

</comment><comment><USER68> I don't get what the benefit of using React is, aside from having it on my resume. A virtual DOM? What does that get me? It renders faster? Rendering speed is not a problem my CRUD screens have. Etc., etc.

Perhaps some UIs are so complex and dynamic that they're easier to build and maintain using React. I'm not saying other people shouldn't use React, but I'm fairly certain it wouldn't give me enough payback to justify the investment it requires.

<comment><USER69> Let me add a different point of view. The adoption of React in the world of ClojureScript was pretty much instantaneous and total. I don't think anybody writes ClojureScript webapps in any other way these days. But the way React is used is different: it's used as a smarter mapping from application state to DOM. Clojure and ClojureScript programmers already know how to manage state and limit its spread, React (plus the usually tiny adapter libs) was just a way to efficiently produce DOM renderings of that state.

It fits like a glove. And while it's not all roses, there are fewer friction points it seems than in JavaScript (but then I think JavaScript programmers don't have it easy anyway). Plus, because of the nature of ClojureScript, most articles I read about optimizing React performance do not apply to me, because all the hard work has already been done for me (for example, immutable data structures mean that you can efficiently prevent re-rendering if data hasn't changed).

Anyway, to sum this up with an example that I'm basing my opinion on: PartsBox ([https://partsbox.io/](https://partsbox.io/)) is something I wrote, using React.

<comment><USER20> Do you have any links/resources for using React with ClojureScript?

<comment><USER70> There are a couple Clojurescript interfaces to React: Om ([https://github.com/omcljs/om](https://github.com/omcljs/om)) and Reagent ([https://reagent-project.github.io/](https://reagent-project.github.io/)) are two I'm familiar with.

For an example of how a Clojurescript project would be built using these libraries, I'd recommend checking out re-frame: [https://github.com/Day8/re- frame](https://github.com/Day8/re-frame)

</comment></comment></comment></comment><comment><USER71> The people who will learn React the quickest are those who have been building applications on other platforms beyond the web.

<comment><USER28> I think it is worth learning Elm first because it many ways it is much simpler. No JS "this" issues to worry about. No props vs. state. It is very opinionated. But it is also virtual dom and "component based" so the paradigm is instilled in the brain to go across and learn React.

Disclosure: I learned some Haskell before Elm so I may be "immunized" against some of the struggle!

<comment><USER71> I don't know, I think it's better to just dive straight into what you're trying to learn, otherwise you're basically procrastinating.

<comment><USER28> I think it depends. For a hard deadline, yes.

For building understanding and mental models, I think it can be bad to jump into things that are too much of a struggle.

However the best of both worlds is some kind of tutorial that explains it really well. Like the recent "explaining functional programming to my 6 year old" article. Then you can dive straight in, but get off to a solid start.

</comment></comment></comment></comment><comment><USER72> If the author sat down for an afternoon he could fix most of these struggles, in probably less time than was invested writing about them.

The thing about ES6, braces, promises, and anything else in programming is that you need a few core examples to wrap your head around and everything else is an application of that.

Beautiful website btw.

<comment><USER73> Every question is easy to answer once you know the answer, the trick is finding the answer. It's often harder to know what you don't know, than actually finding the answer.

<comment><USER72> I agree with this statement, but in this case the author lists concrete things he has difficulty with, like => and promises.

I am responding based on my experience doing some react/redux work coming from a non-JS background, but the author says he is a designer so maybe that's where the difficulty is coming from.

That's not to say there aren't hard parts, but those come farther down the line when you're trying to do something unconventional.

</comment></comment></comment><comment><USER74> I am pretty disappointed that React won the JS UI wars and not another framework. Angular 1.0 was I think the best framework for UI around and then then they smashed that with Angular 2.0 which went into obscurity. Probably Google's biggest mistake that ended up with them losing the UI framework war to Facebook's React.

</comment><comment><USER75> It appears that the biggest argument for React is:Facebook is using it. Really? PHP folks say they same thing: FaceBook is using PHP. There is article on how they write a custom PHP in C. When I view source of FB, it looks like SSR - and they are not using node.

Maybe some small notification widget is sprinkled on top of PHP.

But what kind of argument is: FB is using it? What is the FB reputation even?

It is: who cares. My POV is, show me a react project, and I'll show you a poor tech manager. Because react and js frameworks are so much worse than LAMP even. The productivity is shit. The maintenance is: lets re-write it. Etc. etc. The point is not to program, but to solve business issues, ex: SEO, user engagement, etc. Best thing you can do as a manger: get the react programmer to work for your competitor, that is a win.

<comment><USER75> Got a few upvotes, and then a bunch of downvotes.

</comment></comment><comment><USER76> He didn't even get to the part that I find confusing; the naming of things. componentDidMount? componentWillMount? Wtf is mounting? This isn't a goddamn harddrive. Props? Do you mean properties? or arguments? Wtf is a prop? Reconciliation? Portals? The fuck?

And then, to top it all off, you can't _just use React_ , you need to pair it with a set of other libraries, each with their own set of ridiculous jargon and paradigms.

I honestly think a bunch of very talented Facebook devs got bored and decided to make something complex just so they could keep themselves entertained. And then other developers followed suit because it has cool words that make you sound important and inflate your ego, even though it's doing the same shit the web has been doing for 30 years.

<comment><USER77> If you think React is complicated stay far far away from Angular.

<comment><USER76> Ha! I'm a full time Angular dev. It's full of the same kind of bullshit, but for some reason, I found it easier to "get".</comment></comment></comment>


Mysterious Planet-Size Object Spotted Near Mercury - <AUTHOR> http://news.yahoo.com/blogs/sideshow/mysterious-planet-sized-object-spotted-near-mercury-154443870.html

<comment><AUTHOR> they say it is an image processing artefact.

[http://www.youtube.com/watch?feature=player_embedded&v=6...](http://www.youtube.com/watch?feature=player_embedded&v=6X96xI1gLdQ#t=57s)

After having already watched 6.5 seasons of TNG on Netflix i believe them that it isn't a cloaked Klingon warbird (because the warbird is smaller that the ship in the image :)

</comment><comment><USER2> Rendezvous with Rama!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

</comment><comment><USER3> That's no moon...</comment>


Shrinking bull's-eye algorithm speeds up complex modeling from days to hours - <AUTHOR> http://news.mit.edu/2015/shrinking-bulls-eye-algorithm-speeds-complex-modeling-days-hours-1116 <comment><USER2> From a cursory reading of the article this looks like it's solving an extremely similar problem to Gaussian Process Bayesian Optimization (GBPO [1]) in a fairly similar way. I wonder what a head-to-head comparison between these two would look like.

[1] J. Gardner, M. Kusner, Z. Xu, K. Weinberger, and J. Cunningham, in Proceedings of the 31st International Conference on Machine Learning (ICML-14) (JMLR Workshop and Conference Proceedings, 2014), p. 937

<comment><USER3> Yep, MOE [1] is an example of an open source GPBO.

[1] [https://github.com/sigopt/MOE](https://github.com/sigopt/MOE)

</comment></comment><comment><USER4> Sounds like simulated annealing described in a simplified-for-the-journalist way. Anyone know what the new thing really is?

<comment><USER5> Original paper was linked from article and is here [1].

Although I'm vaguely familiar with MCMC and Metropolis, it's not nearly enough to pass comment on this advance.

[1] [http://arxiv.org/pdf/1402.1694v4.pdf](http://arxiv.org/pdf/1402.1694v4.pdf)

<comment><USER6> The significant change in Bayesian methods is moving away from Metropolis Hastings to an approach based on Hamiltonian dynamics, implemented widely in the STAN package. It would be interesting to see if this is what is being used.

</comment></comment></comment><comment><USER7> I don't understand this paper yet, but Marzouk is an awesome fella--a great explainer, a brilliant researcher, etc. I almost took a job with him a few years ago.

If I get through this paper quick enough, I'll post back any significant thoughts I may have (if any).</comment>


The Square Knot - <AUTHOR> https://tylercipriani.com/blog/2019/12/31/the-square-knot/ <comment><USER2> I, too, switched to the non-granny after reading Ian's site but then switched again to the fake magician's knot where you make a loop, pull another loop partially through, then tighten - the ones where pulling the loose end will undo it "magically". Works great, basically never comes undone, takes seconds, and is a lot less fiddly for old people (like me.)

(Think it's called "The Dissolving Knot Trick" in magic circles.)

</comment><comment><USER3> I too didn't learn to tie my shoes until my (late) 30s. Turns out that one used a square knot and the other a granny.

And just like the author, I also learned about the problem, and how to recognize it, from reading [https://www.fieggen.com/shoelace/grannyknot.htm](https://www.fieggen.com/shoelace/grannyknot.htm) .</comment>


Why doesn't Google spin-off Reader? - <AUTHOR>

By now Google has a fairly established track record of developing products and killing them. But why wouldn't they ever sell these? Spin them off as independent companies? Or put them up for auction? If the problem is that they are not making enough, why not cash in on all that investment? I can't think of when they've ever done anything like this with one of their services and can only speculate why. But I can imagine lots of companies who would love to inherit a hard-core audience as large as Reader. <comment><USER2> _For instance, it was Google Crawler that gave the system ability to make lightening fast connections and also bring up recommendations. It is one of the main reasons it cannot be open sourced. The systems is too intertwined with Google's search and other infrastructure to be sold as well._

<http://gigaom.com/2013/03/13/chris-wetherll-google-reader/>

</comment><comment><USER3> Google has a couple of massive databases that store basically all the data for all of their services and internal tools as well. And Google Reader is tied to your Google account. So to spin it off, you'd have to re-write the backend, and the front-end, so you'd practically be starting from scratch anyway.</comment>


New law to make San Francisco street sweeping even more unfair - <AUTHOR> http://blog.getfixed.me/post/97216491157/new-law-to-make-san-francisco-street-sweeping-even-more

<comment><USER2> This is already very common in Amsterdam where citations are written automatically and not even placed on the car. The fine will arrive in your mailbox fully automated within a few weeks.

In other Dutch cities a similar system is used, however the officer still writes a physical ticket and puts it on the car whenever the scanning device shows a hit.

</comment><comment><USER3> It's not unrealistic to think that this data will be sold to the car repo industry:

[http://betaboston.com/news/2014/03/05/a-vast-hidden- surveill...](http://betaboston.com/news/2014/03/05/a-vast-hidden-surveillance- network-runs-across-america-powered-by-the-repo-industry/)

</comment><comment><USER4> Privacy concerns aside, it seems a little ironic that a tech startup is arguing against efficiency via automation.

Anyway, doesn't Fixed have a vested interest in more parking citations issued? Or does the photographic evidence hurt their ability to win cases on behalf of their clients?</comment>


The Bike Index: Let's Stop Bike Theft, Together - <AUTHOR> http://www.kickstarter.com/projects/1073266317/the-bike-index-lets-stop-bike-theft-together

<comment><USER2> Ugh. So many problems:

1\. It's a violation of "Kickstarter cannot be used to fund e-commerce, business, and social networking websites or apps."

2\. This is a website, right? Then why: "Travel to the eleven biggest bike cities in the United States to meet with shop owners and give them the ability to register bikes for free (the cities: NYC, San Francisco, Portland, Seattle, Philadelphia, Madison, Tucson, Austin, Denver, D.C., and Minneapolis)."

(Awesome, let's use Kickstarter to pay for me/us to take a trip through the US "to meet with bike shop owners and give them a chance to use the website"...)

3\. "Offer region specific recommendations for reporting bike theft to the police." \- so an extended goal of this site is to "recommend how to report to the police, customized for regions"?!?

4\. Some stickers.

5\. Oh, and you have to pay to register with the Index.

And they seriously want $50K for this? Sorry for the cynicism... but this is a website, some stickers, and a tour of the US for the founders.

<comment><USER3> I think some of your points raise legitimate concerns. 5. is wrong though, out of curiosity I googled the site, and registered my bike -- and no payment was required. Where did you get the information that it would be paying? Is that after the kickstarter is funded?

Registration of all new bikes is probably a good way of solving the problem once and for all, although I'm dubious it would work correctly without the legislator involved, and you don't want to involve the legislator, because it wouldn't be free.

<comment><USER2> Their Rewards structure hints at point 5: "$60: Free bike registrations forever".

</comment></comment></comment><comment><USER4> While you're waiting for this kickstarter to be funded, you can just tweet a picture of your bike: [https://twitter.com/ceequof/status/372166690273898496](https://twitter.com/ceequof/status/372166690273898496)

(And since google doesn't appear to have indexed that serial number, a vanilla html page: [https://bbot.org/bike](https://bbot.org/bike) )

<comment><USER5> sharing on a G+ community would have done the trick

</comment></comment><comment><USER6> A better idea would be something like LoJack for a bicycle that fits in the stem underneath the seat. It would transmit on a frequency which can be picked up by the police and in theory you should be able to get your bike back fairly quickly. Alternatively, it could have a cel connection (like whispernet for a Kindle), and any time it picks up a frequency it could send out its GPS coordinates or triangulates itself.

Either way, technology is the solution, not registering your bicycle. Most cities have registered bikes for years (in Palo Alto I believe there is still a law on the books making it mandatory, but it's never enforced), and very few bikes ever get recovered. You're better of perusing Craig's List to wait for someone trying to sell your bike and just go and steal it back.

</comment><comment><USER7> In a world without paint, metal files, sandpaper, grinding discs, tape, interchangeable bike parts, semi-smart bike thieves, etc...this would make sense.

/u/Patrick_Devine is spot on and the best place to test this concept would be the bike theft capital of the world: Amsterdam

</comment><comment><USER8> In Japan, police forces people register that. If you ride on a bike without registration, police would stop you (precisely speaking, stop everyone "looks" bad then check) and check the record if it was stolen.

</comment><comment><USER9> I wish startups would stop using the 'save the world' mantra and lose the 'awesome' descriptor. It's not professional.

</comment><comment><USER10> There's a government website that does this in the UK. immobilise.com.

If there isn't something like this in the US then it's a great idea but I'm reluctant to believe that a commercial venture is the best way to build it.

</comment><comment><USER11> I get the feeling this is going to become a a comprehensive registry of stolen bicycles.

</comment><comment><USER12> I don't even know why people pledged over $11000 for this. It will fail, and hard.

</comment><comment><USER13> Lol, bike theft is notoriously ignored by LEOs. Less than $500 value items usually, which barely pays for the salaries and doesn't pay for gas, food, equipment, or repairs/health.

Besides, you can just shell out $100 for a shitty bike while you save up for your next one to get stolen. Here's an idea! Just buy a stolen bike.

</comment><comment><USER5> what a great idea, i like it</comment>


Minecraft Billionaire Markus Persson Hates Being a Billionaire - <AUTHOR> http://recode.net/2015/08/29/minecraft-billionaire-markus-persson-hates-being-a-billionaire/

<comment><USER2> There have been numerous threads about this in the last few days, including [https://news.ycombinator.com/item?id=10139734](https://news.ycombinator.com/item?id=10139734) and [https://news.ycombinator.com/item?id=10144309](https://news.ycombinator.com/item?id=10144309).

The Schadenfreude in many of the comments is vicious. Those of you posting those ought to reflect on why you do that.

Beyond that, it's wrong for us to be conducting message board threads about the happiness and mental health of a human being. It's off-topic for HN in any case, because it's garden-variety celebrity gossip. But it's also wrong, and I wish I'd realized this earlier.

It's time this stopped. Since more of these threads are sure to be posted, please flag them if you see them before we do.

<comment><USER3> I thought you guys manually chose what went on the front page? Or is it an algorithm?

<comment><USER2> It's an algorithm, of course, but humans make moderation decisions too.

</comment></comment></comment><comment><USER3> I got the impression from the article that Markus is looking to the money and saying "money, are you making me happy?". He is spending it partying and dancing and doing gods knows what in Ibiza. He appears to not find happiness in that either.

For me I find happiness in having a small number of true friends, trying to have the best family relationships I can, trying to be as fit as I can be, being a good father, doing computer programming which I love, and pursuing my other interests like kickboxing and going to movies. It's not a billionaire lifestyle, and I'm very, very far from rich. Even if I had money though I wouldn't pursue much else for happiness except maybe some travel too.

I wonder if Markus might find happiness not in billions and the associated lifestyle but by finding happiness in the very ordinary.

Someone wise once said to me "You'll only become happy when you truly accept your mediocrity.". I think that's especially true for people who think they are not mediocre for some reason.

When he is not happy, he appears to blame the money.

<comment><USER4> A common refrain of the rich, and especially the newly rich, is difficulty in cultivating such "true friendships". This is especially true when it comes to romantic relationships. The impossible to know if someone like you for who you are or for the money you have.

</comment></comment><comment><USER5> I vow that when I do become a billionaire I won't do that.

Happiness is relative, yes I understand that logically, but you just won't be able to illicit empathy from others for the pain of having too much money.

His last tweet has it right, the guilt will pass, just relax, go somewhere no one knows you and disconnect for a while. Hell, you're in the billionaire club, go ask Musk how he handled it. He handles it by taking on larger problems I imagine.

<comment><USER3> >>when I do become a billionaire

I like your confidence! Are you actually doing anything to make that happen?

<comment><USER5> Yes, but my goals are more modest for the near term. I have a better chance of pulling of a "life style business" in the 6-8 digit yearly revenue which is what I'm working on now. Small team, unsexy and reliable market.

The billions come into play after that, when I start investing into infrastructure and community services. I figure I could hit that mark in 30 years, well probably a lot less considering inflation, but then we'll all want to be trillionaires.

</comment></comment></comment><comment><USER6> Notch makes a bunch of early-morning tweets, these get dissected in the press with sentences ending in ", no really" and explanations of how much the toilets in his new mansion cost. And now the comments (even in here) mock him.

He has a history of mood issues and blogged about how his father killed himself due to depression. [0]

He is a human being in trouble.

You can do better, HN.

[0] [http://www.polygon.com/2012/12/13/3763968/notch-father- minec...](http://www.polygon.com/2012/12/13/3763968/notch-father-minecraft)

<comment><USER5> He is in emotional distress and anyone who wants to be helpful should suggest he not turn to Twitter for support. Anywhere but Twitter in fact. There are specializations psychologists go into helping people deal with the problems he is facing.

<comment><USER6> Of course. To always turn megaspotlights on him every time he decides to utter... anything, really, publicly isn't helping either, though.

</comment></comment></comment><comment><USER7> At least he's not deluding himself that he's not still a regular human being. I prefer a super rich guy trying to identify as a regular person, even if cringey, than a rich guy who's suddenly convinced himself that he's special and gets to live in a different world just because he made money.

</comment><comment><USER8> Until he figures out what he wants, the money is going to be a distraction rather than helpful. If I had that much money, and was finding life tricky, I'd start with a call to Tony Robbins...

</comment><comment><USER9> From all the stuff I've read about and from Persson, it looks like he has an inclination to depression. Billions of dollars are not a known effective anti- depressant.

</comment><comment><USER10> He and everyone here knows what he needs to do.

He just needs to do it.

Create.

<comment><USER11> Your comment seems little different to me then telling someone who is depressed that they just need to "get over it." I don't think it is at all that simple.

</comment></comment><comment><USER12> Oh poor him. There's a rather easy fix for this if he chooses.

<comment><USER13> and what would that be? I feel like people here are trivializing his situation without really trying to understand it.

<comment><USER8> Buy an annuity that pays out $1m a year, and donate the rest to the Gates Foundation.

Was that so hard?

</comment></comment></comment><comment><USER14> Seems illogical. Why did he buy a super-mansion in LA and go partying in Ibiza? Did he really want those things? If I got billions I would set up an enclave to withstand future societal collapse, like somewhere in Siberia.

<comment><USER5> You would be the uber doomsday prepper!</comment></comment>


Google Contributor - <AUTHOR> https://www.google.com/contributor/welcome/ <comment><USER2> Sounds like a variation on Tipjoy (YC S08):

[https://techcrunch.com/2009/08/20/tipjoy-heads-to-the- deadpo...](https://techcrunch.com/2009/08/20/tipjoy-heads-to-the-deadpool/)

Good luck, but 20 years of failed micropayment-for-content startups don't bode well for this.

<comment><USER3> It looks like this is a Google project. Controlling a somewhat popular ad network places it in a rather unique position in regard to creating a liquid market between readers and writers.</comment></comment>


Google Swift Style Guide - <AUTHOR> https://google.github.io/swift/ <comment><USER2> Is there any data on Swift adoption among the popular apps/companies? E.g. last I remember hearing, Facebook was still on ObjC/C++, but Uber has gone all in.

One use at Google is internal tools according to this post: [https://news.ycombinator.com/item?id=15701107](https://news.ycombinator.com/item?id=15701107)

<comment><USER3> We're medium sized and our iOS app is something like 200k+ LOC of Objective-C. We started our rewrite (where we replace each .m with a .swift) when 4.0 became available.

It's been nice because Obj-C is a terrible language, but the worst thing about Swift (so far) is value types for collections. Just a terrible idea with no real benefit as far as I can see (someone will say COW something something concurrency something. But nothing concurrent is provided and all the code out there is just giant locks on base collection types. java.util.concurrent.* is unmatched)

</comment></comment><comment><USER4> Someone made a comment and deleted it that I'll reply to here for them. One of their complaints was about spaces vs tabs and having to smash arrow keys.

I'm about to blow your mind (definitely blew my mind ages ago when I first learned about it):

Windows/Linux: Ctrl+arrow

Mac (rarely apps do ctrl but usually you can remap): Alt+arrow

This jumps words and will let you get around your lines much, much faster.

Of course vim or vim plug-ins would be useful to learn too, but you shouldn't need to learn a whole new paradigm to navigate more efficiently.

<comment><USER5> I share this at work every now and then and I'm always shocked people never tried it. Seems obvious to me.

</comment></comment><comment><USER6> [https://github.com/kciter/awesome-style- guide/blob/master/RE...](https://github.com/kciter/awesome-style- guide/blob/master/README.md#swift)

</comment><comment><USER7> The nice thing about style guides is that there are so many of them to choose from.

</comment><comment><USER8> I don't suppose there's an Xcode/AppCode plug-in that handles most of this automatically, or with warnings?

Personally, I think every language should include its over version of gofmt.

<comment><USER9> SwiftLint is a popular choice</comment></comment>


29% of Bay Area's particulate air pollution comes from across the Pacific (2010) - <AUTHOR> http://pubs.acs.org/cen/news/88/i46/8846news3.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+EnvironmentalScienceTechnologyOnlineNews+ES%26T+Online+News

<comment><USER2> This is an article from 2008 about dust storms from the Gobi travelling across the Pacific; this isn't the main pollution problem in China today.

The dust coming in from the Gobi was a result of deforestation and poor land management policies, which were pretty much cleaned up for the Olympics and have remained quite fixed. We haven't had a real dust storm in Beijing since early 2008, I think, and definitely not one in the last 4 years.

The PM2.5 today is not carried by dust from the Gobi, but it still exists, of course. Ironically, the overall effect today is much worse than it was in 2008 (maybe because it just stays in Asia now?). I'm not sure if the pollution can still travel across the pacific without the huge dust storms of the past.

Here is some more info:

[http://en.wikipedia.org/wiki/Asian_Dust](http://en.wikipedia.org/wiki/Asian_Dust)

All of the info in the article is out of date though. I wish I could find something more up to date. Edit: a recent dust storm in March 2013 that made its way to Japan:

* [http://www.scmp.com/news/china/article/1187348/dust-storms-a...](http://www.scmp.com/news/china/article/1187348/dust-storms-and-smog-revisit-streets-beijing)

* [http://www.japantimes.co.jp/news/2013/03/12/national/tokyo-d...](http://www.japantimes.co.jp/news/2013/03/12/national/tokyo-dust-storm-came-complete-with-china-sand/#.UhRoKpIwd8E)

I remember this, but I didn't think it was particularly bad, at least the sky didn't turn yellow. The air was definitely crappy though, but once it all blew out (well, to Japan), it was quite clean afterwards.

Perhaps the solution to China's pollution problems are giant fans (Japan can then build giant robots to destroy these fans).

<comment><USER3> That dust storm earlier this year certainly did turn the sky yellow at my place in Tokyo:

[http://www.flickr.com/photos/poswald/8544202652/](http://www.flickr.com/photos/poswald/8544202652/)

[http://www.flickr.com/photos/poswald/8544418994/](http://www.flickr.com/photos/poswald/8544418994/)

It was one of the strangest weather phenomenons: it came and went within a few hours.

<comment><USER2> That is quite typical of a dust storm actually. It is only on for an hour or so then it blows itself out. Anyways, I haven't seen one of those since 2008, though it was quite bad in March, maybe we just avoided the yellow skies while Tokyo didn't?

</comment></comment></comment><comment><USER4> If we want to do anything about CO2 and pollution in the atmosphere, the low hanging fruit is China.

Every country has stuff it can do, but China is on the 80% side of the 80/20 rule.

<comment><USER5> I wonder if there will ever be a war over something like this.

<comment><USER6> Probably not any time soon, because at present that would mean going to war with China.

I live in Tokyo, which is obviously a lot closer to China than the Bay Area is, and here we have PM 2.5 pollution reports on the news a lot like the regular weather report. On the worst days I throw on a 3M respirator[1] before I ride my bike across town, which makes me look like a character from some kind of post-apocalypse video game.

I am glad to see articles like this, because hopefully hard numbers will provide a concrete basis for diplomatic/economic pressure to make it better.

Even if the Chinese leaders are willing to pursue economic growth even at the tremendous cost of making the air in Beijing[2] so bad that (rich) kids go to preschool in pressurized tents, I don't want to have to keep my kid indoors all the way across the Sea of Japan in Tokyo -- but on the worst days, we do (on the advice of the pediatrician).

(In that sense, I am selfishly glad it is reaching the US west coast -- because the US has a lot more leverage to influence China's behavior than does Japan.)

[1]: [http://www.amazon.com/gp/product/B001NDN29O/ref=s9_qpp_gw_p6...](http://www.amazon.com/gp/product/B001NDN29O/ref=s9_qpp_gw_p60_d99_ir01?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=center-7&pf_rd_r=14A8GFPJBK6C2ESC1XQH&pf_rd_t=101&pf_rd_p=470938451&pf_rd_i=507846)

[2]: [https://www.google.com/search?q=beijing+air&client=safari&rl...](https://www.google.com/search?q=beijing+air&client=safari&rls=en&source=lnms&tbm=isch&sa=X&ei=NWIUUsuKLo2rkgW1wIDYBg&ved=0CAkQ_AUoAQ&biw=914&bih=778)

<comment><USER7> I wonder if this will raise the value of land in Western China (or west of China), out of the pollution stream.

<comment><USER2> Even Kunming has pollution that is considered bad (though much better than east China). I don't think the environment gets much better in Kazakhstan, they are still industrializing. Once you hit Iran, it is almost as bad as China.

</comment></comment></comment></comment></comment><comment><USER8> A lot of this pollution is just a remnant from when China's economy was still largely manufacturing-based. Now that this percentage is beginning to change, (mid 30s in mid 2000s down to high 20s now), the government seems earnest in their attempts to curb pollution.

See:

[http://www.businessinsider.com/china-pollution-business- oppo...](http://www.businessinsider.com/china-pollution-business- opportunity-2013-8)

[http://uk.reuters.com/article/2013/01/31/china-diesel- standa...](http://uk.reuters.com/article/2013/01/31/china-diesel-standards- idUKL4N0B04LE20130131)

<comment><USER2> Around Beijing, the problem is (1) use of coal as fuel with outdated poorly maintained energy producing equipment, (2) use of coal directly by peasants in the winter to keep warm (in Hebei), and (3) lots of cars with poor fuel quality (even if the emissions equipment is working, they aren't given the right quality of fuel). The solutions are quite simple: upgrade the equipment, get farmers to use natural gas for warming, and import the good black stuff from Saudi, not the cheap bad stuff (Sinopec is evil).

<comment><USER8> I prefer to blame 串儿 and excessive 中南海 smokers

<comment><USER2> Blaming the Chuan (outdoor BBQ) vendors is quite funny; I feel like the officials are trying to deflect blame for their black Audi's running on crappy fuel.

</comment></comment></comment></comment><comment><USER9> 2nd or 3rd order related :

        How much could a growing supply of airborne wildfire soot be contributing
        to the decline of Greenland's ice reflectivity? How important is soot
        to amplifying Greenland's melt?

[http://www.outsideonline.com/adventure-travel/adventure- ethi...](http://www.outsideonline.com/adventure-travel/adventure- ethics/Wildfires-and-Ice-Dark-Snow-Climate-Science-Expedition-Field-Book.html)

</comment><comment><USER10> If US companies stopped manufacturing their products in China, a part of this air pollution could be handled and prevented domestically. Ha!

</comment><comment><USER11> I'm not sure why this study is interesting compared to the much more informative and amazing animation that NASA put out a few years ago, [http://www.youtube.com/watch?v=YtJzn8A725w](http://www.youtube.com/watch?v=YtJzn8A725w)

</comment><comment><USER12> I would like to see some numbers which tell which places in US are least affected by this kind of external pollution. As pollution from Asia is going to increase, it might make sense to look at these places especially for ppl with breathing issues.

</comment><comment><USER13> Surprise! Pollution is a _global_ issue, too!

It's time to start "thinking humanity", not "my country".

</comment><comment><USER14> I truely hope a virus mutates the DNA of human sperm, or eggs; making the world population decline.

<comment><USER15> I'm getting a serious Poe's law vibe from this comment and username.

<comment><USER16> Benderism: save the world by killing all humans.

[http://humanities.philosophy.objectivism.narkive.com/SivGxJB...](http://humanities.philosophy.objectivism.narkive.com/SivGxJBl/benderism)</comment></comment></comment>


TIOBE Index for May 2016 - <AUTHOR> http://www.tiobe.com/tiobe_index <comment><USER2> I see Java has spiked this year. Is there any accounting for that other than the vagaries of how the index is calculated?</comment>