React.js Introduction for People Who Know Just Enough JQuery - <AUTHOR> http://reactfordesigners.com/labs/reactjs-introduction-for-people-who-know-just-enough-jquery-to-get-by/ <comment><USER2> I haven't gone through this page yet, but thank you for at least the attempt at reaching somebody in my state of affairs. Front End work is very hard. The front end design & what I would call the back-end front-end disciplines are supposed to meld together according to job postings and over-zealous recruiters, but it's a good deal more complex than I have been willing to put up with, mostly because of the materials to get started and the unintuitive tools that people who know what they are doing swear by.

Imagine being solid at design, pushing pixels, using HTML, CSS. Then suddenly these program frameworks which are created by back-end programmers not visual designers appear and the ramp up for the average technical person is immense. For me it's been enough to turn me off them all together and make it a talking point that "my javascript skills fall off at X,Y or Z" so recruiters and employers know that despite being able to do a lot, I can't suddenly become everything UI and everything back end just because the title of anything "front end" is so versatile.

<comment><USER3> What do you mean? This:

        var createItem = function(itemText) {
          return (

{itemText}

          );
        };
        return (

{this.props.items.map(createItem)}

        );

...is clearly so much more logical than:

{{item}}

Source: [https://www.airpair.com/angularjs/posts/angular-vs-react- the...](https://www.airpair.com/angularjs/posts/angular-vs-react-the-tie- breaker#1-9-templating)

<comment><USER4> That named helper function isn't necessary, so this might be more appropriate:

      return

        {this.props.items.map(item =>
{item}
)}

;

vs. the Angular version:

{{ item }}

The Angular template is more readable at the expense of ngRepeat's complexity. Neither example includes Component/directive boilerplate. The directive boilerplate is generally worse, because it requires a separate template file or an ugly template string, knowledge of the directives API itself which is baroque in the extreme, and $scope-wrestling (whereas JSX' scope is the same as JS').

In my opinion reuse of the React component is more straightforward, you explicitly import/require it while in Angular you specify its providing module as an angular.module dependency, which has implications for config block ordering.

<comment><USER5> I used to struggle to answer this when talking to Angular folks about React. Then I came across a situation where I needed to recursively build a DOM tree based on complicated calculations on a per-node basis and also calculated values at the top level. If I'd been doing it with ng-repeat, the logic would be split confusingly (and unnecessarily) between the template and the controller, and I'd need to pass down any information from the top-level ancestor manually.

In React, I just create a renderNode method that's called by render at the top level, and renderNode on non-terminal nodes returns
{children}
 where children is a map whose mapping function returns this.renderNode. The entire algorithm is grokkable at a single glance, and there's no need to create Directives to add any fancy features or special cases in the future. No need to read pages of documentation about ng-repeat and its intricacies; it's all just Javascript.

Yes, Angular "just works." But React "just works" the first time you try it.

</comment></comment></comment></comment><comment> vezzy-fnord Speaking as someone not intimately involved in the web development community, React looks decent but absolutely not worthy of the obscene amounts of hype it received... unless what web devs had before was really that horrible, because that's the impression I got. Though from what I can tell, jQuery and React are somewhat orthogonal tools, as I have used the former and it goes beyond rendering views.

What I cannot figure out is all the harping on about "functional style". The React examples all felt more Smalltalk-ish to me than anything else (I suppose unsurprising given JavaScript's vague influences from Self). The use of closures doesn't really change the conceptual patterns much. Is it because the tutorial can only cover so much ground, or is it that since some of the primary buzz around FP was the management of mutable state, to the point that people now instinctively associate the idea with FP?

<comment><USER6> Before React: to make a transition, let's change this, this and then that, mutating state on every step. After React: have one pure function, which takes as input the current state and produces the desired output.

This is the main shift. It's very similar to how imperative programming is done in Java vs Haskell.

<comment><USER7> Can you dumb this down slightly for an "early" developer with a real world example by any chance?

I'm not grokking the significance of why changing everything and having mutations is bad.

<comment><USER8> It's just nicer to use if you have complex UI. OP's response was poor IMO, just because something follows some abstract principles doesn't necessarily give it value for us. I'll give you examples of things I've worked on where React made sense & where it didn't:

-E.g. use React (or Backbone, Angular, etc.): A real-time document editor, with many interacting components, with lots of real time updating of the UI. Definitely needed a framework like that, and it was great.

-E.g. don't use React, because in these cases it's a total Rube Goldberg machine (extra steps to achieve the exact same outcome): Basic web app with some ajax submissions, adding results to DOM type of stuff. Maybe small html fragments cloned, inserted by jQuery. No extra fancy client interactivity.

^If people claim you should use React for the latter (undoubtedly some will), they are very likely just people who follow trends to follow trends, or maybe don't have a ton of web experience and it's one of the few things they've learned and are sticking to. It's just so unnecessary (not to mention 100kb+ of overhead, & in my experience comes out to about x3 the amount of code). But yeah, absolutely use React if it's anything like the first use case.

<comment><USER6> 1) React does not make simple apps overly complex. It might feel like more work if you are more used to jQuery. If you are used to React instead, it really won't have a huge negative impact on a small app. 2) React will scale. It will be a much better vehicle for future development (as you admit, it is more suited for more complex cases than jQuery).

I was not making a judgement on the value of the approach, although I personally believe that this paradigm shift has a huge positive impact and is applicable in lots of cases. If I can choose between lots of computation intertwined with state mutation and a declarative approach where the mutation happens on the smallest scale, up the call stack, I will always choose the latter (of course, unless you have to mutate to gain performance).

<comment><USER8> I didn't say it's more complex, I just said more steps.

Yes, if app is planning on being more complex, sure use Angular or Backbone or Ember or React. Otherwise, don't. Your pet projects sure, use it; if my team is billing clients, I've learned from experience, you're screwing them if you're not just using basic jQuery or even raw JavaScript which is a lot better to work with these days. If your reasons are only rooted in your abstract preference of design ideals w/o looking pragmatically at the situations, you're likely doubly screwing them.

Fyi this "paradigm shift" is like 8 years old, React is not disruptive, it's just another variation.

</comment></comment></comment></comment></comment></comment><comment><USER9> Shameless plug: I wrote my own React introduction—geared more for people that know some JS and HTML, but not necessarily any other JS libraries. More specifically, it very gradually builds up from rendering a single JSX tag to enough components, state, and props to build React's to-do example. I found React has an unusually gradual learning curve—you can really build up concepts bit-by-bit.

EDIT: As per usual, I forgot the link: [https://github.com/dahjelle/Programming- Worksheets/blob/mast...](https://github.com/dahjelle/Programming- Worksheets/blob/master/React.js/IntroductoryReact.markdown)

<comment><USER10> Thanks. I was very much in need of this, especially with so many companies expecting React expertise of new hires these days.

<comment><USER9> Glad to hear it! Very open to contributions/suggestions!

</comment></comment></comment><comment><USER11> As someone who knows Angular and Knockout. I found this great. Because react is a different way of thinking IMO that most tutorials I read were not easy to get up and running so I just threw in the towel and forgot about react. Most people make too many assumptions on the skill level of the reader (myself included when I blog) and it can be frustrating.

Thanks.

<comment><USER12> Knockout.js is my favorite because it doesn't make me hack my HTML documents into pieces if I don't want to, but if I want to, it lets me make web components that work all the way back to IE6.

I also like that it doesn't require anything beyond normal HTML to make templates and it doesn't require learning some huge framework just to bind a simple data-set into the page. You can also read through the entire code-base in an afternoon.

<comment><USER13> I worked on a project with around 20 developers using knockout (with two lead developers essentially writing their own framework as we went) and it was a ridiculous mess. I think it can be a good tool for prototyping, but it is horrible on a large app. You're always changing some observable and having something far far away break completely. React with immutable.js is much better because you really can focus on one component at a time in complete isolation.

<comment><USER14> Knockout on it's own is just data-binding, we ended up using this as the SPA framework around Knockout: [http://durandaljs.com/](http://durandaljs.com/)

</comment></comment></comment></comment><comment><USER15> Maybe slightly off-topic, but the tutorial page adds entries to my (Firefox) back button as I scroll down. So when I tried to "back" to HN, nothing happened. Second, third back, nothing happened. Opening the back list, a dozen or so entries and they all do nothing.

I think this kind of design should really be avoided, it breaks my user experience.

<comment><USER16> Yeah, I'm really getting tired of this "You just changed pages and didn't know it" pattern I'm seeing more and more. I'm not sure why people want to have this single page app at all costs, but if you want the single page app, than a single click of "back" should work.

<comment><USER17> I think there is value in doing single page apps but mostly for web applications not really for just a website. Still I completely agree that breaking the back button needs to be avoided.

<comment><USER18> I think a more useful distinction is - mess with back-button history if and only if the user perceives a page transition regardless of if the location bar changed it there was a page load.

</comment></comment></comment></comment><comment><USER19> Consumable content aside, I absolutely _love_ the format of the tutorial. It's _significantly_ more pleasant to dig into compared to what seems to be the more common tutorial format (e.g. [1]).

Good work.

[1]: [https://tour.golang.org/welcome/1](https://tour.golang.org/welcome/1)

<comment><AUTHOR> Thank you so much! :) I also found that a blog format is much easier to consume than a REPL/in-browser editor based one.

<comment><USER20> It is, but the tutorial could have made good use of pagination or anchors, so one could bookmark where one has left off.

Also: What's the deal with "the cow above"?

<comment><USER21> I think thats a joke on the cow printed on the ORielly book (also about React)

</comment></comment></comment></comment><comment><USER22> Is React meant to replace Ember/Angular type of frameworks? Can React also connect with backend APIs to fetch JSON and present them on the frontend? I've been waiting to nosedive into Angular2 (when its out), is React a better alternative to get started with?

<comment><USER3> Yes, it's pretty much unnecessary to include React and a framework like Angular, Ember, or Knockout in the same project. And of course React works well with REST and GraphQL APIs for communicating with a backend. React is definitely a better alternative to a heavyweight framework like Angular for new projects.

<comment><USER23> As a relative newcomer jo JS frontend development, is there a canonical JS REST client library that works well with React / Flux, or do I have to write that myself?

<comment><USER13> Fetch is really easy to use, and is native in modern browsers. There are several polyfills as well. It eliminates the need for any libraries.

<comment><USER24> Fetch looks interesting but as far as I can tell, it's an in-progress standard with no support on any version of Safari or IE or any mobile browser whatsoever. Seems like it has a bit to go before it being 'native in modern browsers'

<comment><USER25> You can polyfill it in those browsers. Just use polyfill.io, or if you prefer, manually feature-detect it and if necessary load Github's fetch polyfill, which is good: [https://github.com/github/fetch](https://github.com/github/fetch)

</comment></comment></comment></comment></comment></comment><comment><USER26> Sorry but nowadays I feel that jQuery is like php for the frontend: people get results fast but the average code quality is so shitty. Why on earth is jQuery used for things that normal js can do instantly? There are so many libs out there based on jQuery even though this dependency is absolutely unnecessary. I might sound arrogant but people should get an understanding for JavaScript and learn how to use it before stacking layers of abstraction. Ajax with normal JS for example is not so hard. One doesn't need all the fancy angular/jQuery/whatsoever helpers. If one knows the basics it's okay to use some convenience stuff from time to time but I feel that so many low quality devs are solely relying on their precious xxx kb libs just to display a simple hello world.

<comment><USER27> I have a friend with a web publishing business. She uses guess and check with text edit copy/paste to build websites for clients. I've shown her the console log countless times and she always rolls her eyes when I extoll its value.

She makes 50% more than me, has cash in the bank, and loves her life.

All I have is picking on her javascript. And I'm not even really any good at it.

I think there's no reason to be correct when your goal is to buy food and pay rent.

<comment><USER28> No offense, but what do you do where a guess-and-check person makes 50% more than you? Is she just hustling for clients who have no idea what they're doing re: web design and using marginal technical knowledge to make pages for them?

</comment></comment></comment><comment><USER29> I have looked at react.js a couple times after reading more and more buzz about how fantastic it is. However I'm instantly turned off of switching to it when I read that HTML (which isn't HTML and is actually something called JSX) goes in your js files.

With angular I can keep all my HTML in my HTML files. Is this normal or am I completely missing something?

<comment><USER30> Ask yourself why that bothers you and boil down your objections to a practical point. You can then evaluate whether there is a real cost and whether it's outweighed by other things.

A lot of these issues turn out to be things we learnt were bad ages ago and have forgotten why. The original context you learnt in might be sufficiently different or other factors might mitigate the underlying issue.

In the case of JSX - we were all told that to keep css, js and html separate - that inlines js and styles are bad. These things are all partially true but in a react.js project your components are usually tiny and there is always an inescapable dependence between js and html. It is therefore very different from when we used to see long html documents littered with onclick.

<comment><USER31> Except that there _are_ use cases where you want to use boilerplate HTML in more than one component (i.e. bootstrap). Also, I've never quite understood the argument that everything that goes into defining a component should live in one file. By that logic we should be putting our data stores in the component, any translations required to internationalize the component, the database queries - heck - why not put the tests in the component while your at it.

The real reason we keep "technologies" separate is so that we understand what realm we're working at any given moment. Furthermore, we can distribute responsibilities across multiple team members focused on different disciplines. Facebook has the kind of clout internally to force their designers to use JSX and inline styles, but many organizations do not have that kind of alignment.

<comment><USER32> Actually, with GraphQL and now Om Next, you _do_ put your data store "queries" in the component. It's a great idea.

<comment><USER31> I think it's all fine and dandy, and I like the idea of isolated components, but I'm not sold on shoving everything into one file. It just smacks of preference.

<comment><USER33> One file per one component sounds like a better representation of one real world concept using code. It translates 1 to 1.

<comment><USER31> Then just put all the files for a component into a single folder, which translates 1 to 1. Again, this is all just a matter of preference, and with pre-compilers you could glob all your js/css/html into one file using _any_ framework if you really wanted to. Seems silly to me, but to each their own.

</comment></comment></comment></comment></comment></comment></comment><comment><USER34> I see the point but noone in their right mind would write the javascript like that. When written better it's a good amount shorter than the React solution.

[http://pastebin.com/wbGZZs7U](http://pastebin.com/wbGZZs7U)

<comment><AUTHOR> I totally agree, in fact I'm going to link this :) The point I wanted to make is that every feature requires a bit of refactoring like this, whereas React puts some structure.

</comment></comment><comment><USER35> Thank you, great intro to react. Easy for me as a backend dev to follow and get a grasp of React.

One thing, the page loaded constantly itself, after reading half through the tutorial (3-4 minutes), I had about a hundred entries for the same page in the tab history. This makes the website aweful.

<comment><AUTHOR> Thanks and oh no, do you know which browser/OS you're using? Not sure if it's the JSBin thing...

Edit: I think it has to do with JSBin. I reported the issue here: [https://github.com/jsbin/jsbin/issues/2464](https://github.com/jsbin/jsbin/issues/2464)

<comment><USER36> Same here [1].

        $ lsb_release -a
        No LSB modules are available.
        Distributor ID:	Ubuntu
        Description:	Ubuntu 14.10
        Release:	14.10
        Codename:	utopic

        $ google-chrome --version
        Google Chrome 43.0.2357.132

[1] [https://imgur.com/JN5PlqN](https://imgur.com/JN5PlqN)

<comment><AUTHOR> Thanks! Looks like the issue is with JSBin embed. I reported it here:

[https://github.com/jsbin/jsbin/issues/2464](https://github.com/jsbin/jsbin/issues/2464)

</comment></comment></comment></comment><comment><USER37> Can React use separate HTML templates? I find this style of mixing markup and Javascript super-ugly.

<comment> jon-wood Done right you don't really do a lot of mixing markup and Javascript - you'll have a render method which takes your components current state and turns it into markup, with everything else being straight Javascript.

There are ways to avoid it, but I'd encourage you to give it a while before looking for a way out, because almost everyone I know who had that initial reaction has come round to it.

</comment></comment><comment><USER38> OK I may be off point here - but why do people who know just enough JQuery need to know about React ?

Wasn't React developed as a tool to manage complex data flow patterns inside of a big web app like Facebook ? Why does your average JQuery developer need to know or care about this whole new abstraction layer ?

Even though I've seen it a 100 times by now I'm still amazed by how fad driven programming culture is and I feel like this is a perfect example : React - come learn this complex peace of technology to solve problems you never had (and probably never will).

<comment><USER39> Its aimed at JS beginners, a lot of us started with simple web development picked up some JQuery and are looking for something more powerful. This looks like a great segue to building rich front-ends.

In fact if you look at the URL the site is called reactfordesigners.com.

<comment><USER38> >In fact if you look at the URL the site is called reactfordesigners.com.

You would want your designers to write frontend code that is complex enough to require React ?

The way I've worked with designers is they create sketches and prototypes just to demonstrate the concepts with whatever they are familiar with and then developers turn that in to actual maintainable code with feedback.

<comment><USER40> The title says > React.js Introduction for People Who Know Just Enough JQuery to Get By

Unless you're working at a really big shop, designer these days is almost synonymous with UI/UX engineer or front-end engineer. Considering the target audience is JQuery users, React is not too far of a jump and doesn't have to be restricted to "complex" websites.

<comment><USER38> In order for benefits of React to outweigh the costs you need to have a web application with complex data flow. jQuery is proven to work and there is no problem with it in anything less.

At the point where you actually need React you also need to understand software engineer or you're going to get a mess no matter what the framework is.

</comment></comment></comment></comment></comment><comment><USER41> Can somebody explain to me what is so bad about jquery? I use jquery every single day to make web pages do the things that I want them to do.

But my javascript hipster friends all claim that this is wrong and stupid and that I shouldn't use jquery because of some abstract reason that nobody ever seems to be able to articulate to me.

<comment><USER42> My $0.02 ...

There's nothing wrong with just using jQuery. For many, many applications/projects it's a great tool and does everything you need.

What happens as a project/app/site grows is that you add more and more and more jQuery to a single file and it starts to get hard to maintain (hard to find what you want, hard to change something without something else blowing up, hard to navigate the files you're using). Frameworks like React, Backbone, Angular, etc were made to drive large, complicated, often single-page applications where you have massive amounts of interacting code and want to generally simplify what you're writing and how it's architected.

So, in the end, these are meant to help you organize code, be more productive, and have a more coherent architecture. That's the idea, at least. The tweetbot example here is simple because you're just learning so, if this is the only thing you're building on a page, it probably makes more sense to just use jQuery.

I think the typical road from jQuery-only to using a framework is your apps get bigger and you start to think "this is hard to maintain." Then you see an example of a framework doing something that would really help your process and see how it could improve the code you're writing. You try it out, it makes the process easier/more enjoyable, and you continue learning more. Or it doesn't and you swear it off.

AFAICT, these frameworks grow out of a person or team that figures out a more productive way to write code for what they're working on. That becomes a boilerplate they use, then grows into something they think would help others out. Then it gets a name and we all argue about it. In the end, it's just one person's/team's/company's idea of how to write code better, which may or may not work for other people/teams/companies.

</comment></comment><comment><USER43> Also interesting to see the pitch on "ClojureScript is a Product Design Tool"[0], written by Precursor's designer. A lot of this stuff can be made more accessible for designers and FE developers who don't _want_ to have to deep dive into all the new-fangled frameworks.

[0] [https://precursorapp.com/blog/clojure-is-a-product-design- to...](https://precursorapp.com/blog/clojure-is-a-product-design-tool)

</comment><comment><USER44> I'm excited for ReactJS catching fire. I've been using a lot of it lately, and most recently I had to go back to a set of components I built to add functionality. In total, the front-end took maybe 20 minutes: no fishing around for the right selector or clashing functions. Just "here's a new button, attach this event"

</comment><comment><USER45> If you must compare Angular with React, then at least compare it to ReactJs+Flux+more or Angular-Templates with React-Templates.

React is more like the view-lib of a framework. I like them both (also ember, knockout, backbone) and unfortunately think the battle isn't decided yet. Will take some time if ever...

Complain to Steve Jobs(1), for killing Flash/Flex, as you could to client-side apps with desktop performance, without the hassle of Cross-Browser testing and so on... In my opinion the concepts of Angular and React+Flux are heavily based on the features this platform provided.

(1) IMHO the Only good thing he ever did (for the web), as it forced the proprietary software out... but led to the great Framework-War :)

P.S.: Also Actionscript 3 was ECMAScript(Javascript) plus Classes, Types and more... ( I wondered about which Version that was latly and found out they implemented ECMAScript and extended it with features requested by users.)

<comment><USER46> BTW, if you use Backbone you can simply use React as a View.

</comment></comment><comment><USER47> Really well written, as a backend developer who has been playing a little bit with frontend lately this hits the sweet spot :)

Cheers

<comment><AUTHOR> Awesome :) Glad to hear that!

</comment></comment><comment><USER48> This tutorial is awesome! I love the tone and how it knows EXACTLY who it is written for.

This may be a bit late, but I would LOVE for someone to do this for JS in a Rails App (or even CoffeeScript). I am desparately searching for good tutorials for people that are "borderline-decent" at jQuery but are Rails devs. I can't find any.

I understand, in theory, how to render some JS on a view and all this good stuff - but once you go into creating a UI that feels like a modern UI with lots of lil AJAXy elements...it can become a pain REAL quick with a bunch of `...js.erb`s all over the place with no seeming pattern to them.

So I would love if someone had a tutorial just like this, for how to create a simple and sexy app that looks like an Angular/Ember app but just using CoffeeScript/jQuery/vanilla JS.

Anyone know of any such thing?

<comment><USER49> I think the problem lies in the '.js.erb'. Write javascript in separate javascript files (in app/assets/javascripts/) and use JSON to get data from the rails backend.

Have you seen this? [http://todomvc.com/](http://todomvc.com/) You can try implementing a backend in Rails for the jquery example. [https://github.com/tastejs/todomvc/tree/gh- pages/examples/jq...](https://github.com/tastejs/todomvc/tree/gh- pages/examples/jquery).

The JS file shows how to organize javascript code - [https://github.com/tastejs/todomvc/blob/gh- pages/examples/jq...](https://github.com/tastejs/todomvc/blob/gh- pages/examples/jquery/js/app.js)

Also unless you really like coffeescript, stick with javascript. If the syntax is bothering you, you can write in ES6 (next version of javascript) which has nicer syntax and use babel to convert to ES5

1\. [https://gist.github.com/danielgtaylor/0b60c2ed1f069f118562](https://gist.github.com/danielgtaylor/0b60c2ed1f069f118562)

2\. [http://justicen.com/#/posts/74046fea9a4c61477db9](http://justicen.com/#/posts/74046fea9a4c61477db9)

<comment><USER48> I hadn't seen todomvc but it doesn't quite address my issues. It still feels too disconnected from where I am.

Also, I do write JS in separate JS files - but my understanding is that when you want a response to be in JS, don't you have to use a corresponding `...js.erb` file to handle the action/response?

How else would you update the DOM after the action has been completed?

<comment><USER49> You send the response as json and act upon it. Have a look at this - [http://jsbin.com/depuvelixu/edit?html,js,output](http://jsbin.com/depuvelixu/edit?html,js,output)

The json the code fetches is static but it can be served by a rails app. The DOM manipulation gets painful which is the reason people adopt JS frameworks.

</comment></comment></comment></comment><comment><USER50> Really great tutorial - would be good in the next steps to talk about getting webpack setup etc..

<comment><AUTHOR> Thanks! I definitely should put more in the next steps, like examples/talks/etc. I wanted to ship this asap :)

<comment><USER50> Shipping - for some reason in my day job I can ship to almost any deadline. Side projects - one day I'll finally finish one...

</comment></comment></comment><comment><USER51> Good article. Needed it two weeks ago :D

I did 4 years ExtJS and 1 year Ember. React was totally different but rather nice to work with. The API surface is so much smaller.

</comment><comment><USER52> Great job, man! You make some strong points here that clearly reflect the important differences of these two approaches! Well done!

<comment><AUTHOR> Thank you :) !

</comment></comment><comment><USER53> Comparing jquery to React (or Angular/Aurelia/etc) is obvious but the article is great for beginners though.

</comment><comment><USER54> Great concept (tutorials for people who know just enough JQuery). Would love more tutorials (for Angular, e.g.) for such people.

TodoMVC was a great effort. But unfortunately, the actual Todo creations are not well documented (for beginners to figure out how and why certain things were done).

</comment><comment><USER55> This is really neat.. one thing though: there is nothing magic about 'the "magic" state'; it would IMHO be better to just call it state (or inner state, or so), and to explain that once the state is changed react rerenders the component automatically.

<comment><AUTHOR> Yup, I agree... will fix! Thank you!

</comment></comment><comment><USER56> I think this article demonstrates very well why I think React should be the first choice for any new web projects... what to go with it (ember, flux (and related), or other) is open to more debate.

Of course there are great alternatives with similar workflows (mercury, etc).

<comment><USER57> I think this sums up React.js perfectly. Easy to learn and build something with, but the discussion around Flux and what libraries to use to implement it can complicate and deter newbies. The official explanation of Flux on Facebook's own site I think does a poor job explaining it in a way most developers (new and senior alike) can understand.

<comment><USER56> That's very fair, it gets even more complicated when trying to do server/client mixed rendering with it. It's all very hard to grasp in a deeper level.

This tutorial is absolutely awesome.. and I think the deep dive is worth it for larger apps too.

</comment></comment></comment><comment><USER58> This is the first React article I read where it actually compares and contrasts the jQuery approach and the React approach. I feel like React makes sense now, even though writing my HTML inside JS still feels off.

</comment><comment><USER22> That is a truly impressive tutorial. Just curious, how much time did you spend on putting it together? Additional props for doing it being a dad!

<comment><AUTHOR> A few hours every night for a week :) But I'm not a dad, haha.

</comment></comment><comment><USER59> My web experience is mostly custom in-house web frameworks, JSP, JSF, WebForms, jQuery and basic Angular.

It was a nice overview of React to me.

</comment><comment><USER60> Would you be open to the idea of writing something similar for React Native if you are interested and/or find the time?

</comment><comment><USER61> This is neat! Thanks for sharing.

<comment><AUTHOR> Thank you for reading!

</comment></comment><comment><USER62> Wow, this is exactly what I needed.

</comment><comment><USER60> Beautiful article man.

</comment><comment><USER63> am I the only one fine with using just jQuery and ajax? I've written a chrome extension with 4k lines of code and I never had any problems. Instead of breaking things into separate classes and components, I just put them in separate files or in logical sequence. I'm sure this can get a lot messy with more than one developer but so far my projects, I almost always just use some jQuery library or plugin that does 80% of what I want to do and hack the rest.

<comment><USER17> There are dozens of us! Dozens!

In all seriousness I typically work with a lot of designers; asking them to update markup in JSX versus HTML is simply not possible. It's not because they can't figure it out but it makes it more difficult for them to quickly test and they typically break JavaScript in many, unexpected ways. While I'm fine with the UI and business logic separation where UI can contain markup _and_ scripting, I don't think the answer is this awkward solution of shoving HTML into the scripting.

<comment><USER64> This is what worries me. We are using Angular, and my non-technical co-founder knows just enough HTML and CSS that she makes a very useful contribution to our front-end development. Sometimes the contribution is in the form of HTML mockups produced outside of our app that are easy for me to port over, and sometimes it's direct contributions to the codebase. I worry that if I went the React JSX route that it would be much harder for her, or pure designers that we might hire, to meaningfully pitch in.

<comment><USER65> A fine thing to do in that case is just to use React but without the JSX.

<comment><USER64> My understanding was that forgoing JSX would make the situation worse by falling back to imperatively manipulating the (virtual) DOM within your component. If there is a way to have an external, declarative HTML document using React I would be very interested.</comment></comment></comment></comment></comment>


Doom 3 Open Sourced - <AUTHOR> http://github.com/TTimo/doom3.gpl

<comment><USER2> Let the forks begin! (And maybe new versions of popular Linux Open Source FPS games, rebased on Doom 3?)

<comment><USER3> There is going to be some cool stuff to come of this!! (rubs hands together)</comment></comment>


Driving Down Memory Lane in the Original Minivan - <AUTHOR> http://www.nytimes.com/2016/12/15/business/driving-down-memory-lane-in-the-original-minivan.html <comment><USER2> > But the upright shape and boxy proportions of minivans make it easy to > transport plenty of people and lots of luggage. In fact, they tend to > perform the job better than most other types of passenger cars — even their > upscale descendant, the sport utility vehicle.

I'm convinced that most people that gets small trucks would do better with minivans. The number of things we hauled in the back of our 1987 Ford Aerostar after pulling out the second and third row seats was staggering (and unsafe). It was a better solution for just about everything except for loose earth.

My own Honda Odyssey is a dream to drive, and having taken many 7+ hour road trips over the years in multiple types of vehicles, it's by _bar_ the most comfortable.

The only downside is how you are sometimes perceived, and thus treated, when on the highway. People seem to not like to be behind a minivan, whether because of some preconceived idea that it's slow, or because they don't like the view obstruction, or some other reason. It's annoying to be passed just so the person that passed you can decide to go slower than you were in the first place, and it seems to happen more frequently when driving the minivan.

<comment><USER3> > I'm convinced that most people that gets small trucks would do better with > minivans.

Agree. I would add that most in an SUV would be better off in a minivan. The minivan is the perfect way to quickly cover long distances in comfort for 3+ people.

Speaking of cargo space, the latest Chrysler minivan products have lie-flat rear seating that disappears into the floor and provides a huge flat area for sleeping/transport.

My family fleet consists of a Chrysler minivan, two Honda Accords, Toyota Tacoma 4x4, diesel VW beetle and diesel VW Westfalia Camper Van. The minivan is by far the most practical car and the easiest and most comfortable to travel in.

> downside is how you are sometimes perceived, and thus treated, when on the > highway..

Also my experience. No one wants to be behind a mom van and no one wants to be passed by a mom van. Often get passed while going 10+ over the speed limit only to have the person pull in front and slow back down the the posted speed. Ironically, the 3.6 Pentastar engine in the Chrysler minivan is the most powerful engine by far in my fleet at almost 300HP. Fuel mileage is close to 25mpg when cruise is set at 70mph.

Minivan is rational purchase but we are not rational beings, especially when it comes to car purchases. Choice of vehicle represents our aspirations, self- image, etc.

</comment></comment><comment><USER4> This article ends so abruptly. It could be summed up as, Chrysler invented the minivan in the 80s, some family kept on in mint condition, I drove it while Twisted Sister played on the radio.

<comment><USER5> I wonder if nostalgia articles get as many clickthroughs from GenXers as they do from older generations?

</comment></comment><comment><USER6> > even their upscale descendant, the sport utility vehicle.

The Chevrolet Suburban has been in continuous production (excluding WW2 when nothing civilian was in production) since 1935. It's a stretch to call your great-great-great grandfather your descendant.

<comment><USER7> They were referring to the lineage of the prototypical "family" car of its generation.

The station wagon once ruled the driveways of families but as the next generation grew up viewing wagons as "something my boring/lame/uncool parents drove" they were primed to buy whatever alternative arose. The minivan was that alternative an inherited the throne, ruling over the family market for another generation. Then the SUV, a slightly more refined take on the traditional body-on-frame 4x4 burst onto the scene in the form of the Ford Explorer and Jeep Grand Cherokee. It's plainly obvious that the SUV was handed the "family" crown somewhere around 2000-2003 by comparing the sales charts of minivans and SUVs. The dowager queen called the station wagon was effectively dead by that time.

Now we're reaching the point in time when the children of the 90's, those raised in the backseat of a Ford Explorer or Honda Pilot. SUVs have softened over time as they've gone unibody and ditched any pretense of off-roading prowess but they are still a distinct category, one that is about to be ousted by the rise of the "crossover". While it's easy to argue that crossovers are still SUVs, especially when companies like Ford have relabeled SUV stalwarts as "crossovers", there are distinct differences between the SUV and the modern crossover. The crossover takes the best qualities of the SUV, the high seating position and the 5 door hatchback bodystyle and merges it with the best traits of the compact sedan. The prototypical crossovers, the Mazda CX-5, Honda CR-V, and Ford Escape are about the same size as the Ford Explorer of the 90's and early 00's. However, they share more in common with the Mazda 3, Honda Civic, and Ford Focus than they do with any larger SUV. THey bring the wise use of interior space (a CX-5 feels roomier in the backseat than a damn Tahoe), 30mpg+ efficiency, and pure FWD layout (with hacked on AWD systems hardly do anything at all, see: CR-V) which represents a sea change from the SUV in terms of design and marketing intentions.

The minivan was the first "new" form factor to overthrow a design that traces its way back to vehicles like your 1935 Chevrolet Suburban. While the Suburban may have held the same market niche for 64 years, even it changed significantly in the face of the growing demand for "family" focused SUVs with the release of the GMT800 generation.

</comment></comment><comment><USER8> I recently saw a [https://en.wikipedia.org/wiki/Stout_Scarab](https://en.wikipedia.org/wiki/Stout_Scarab) on display at the NC Museum of Art. Way ahead of its time.

If you have a couple minutes, watch "The Stout Scarab: The World's First Minivan?" \- [https://www.youtube.com/watch?v=pjvy-n2TM9U](https://www.youtube.com/watch?v=pjvy-n2TM9U)

(Apparently the Scarab on display at the museum is the one in the video.)

</comment><comment><USER9> It's so weird that the Dodge Caravan is considered the first minivan. I remember the Dodge Colt Vista pre-dating it by a year. I guess the Vista wasn't called a minivan, though.

<comment><USER10> That was called a 'Tall Wagon' in its day: [http://oppositelock.kinja.com/tall-wagons- ranked-1690577814](http://oppositelock.kinja.com/tall-wagons- ranked-1690577814)

Convergent evolution has replaced many SUVs with 'crossovers', which are basically the same thing, without the word cursed word 'wagon', tainted in many Baby Boomers' minds as a symbol of stodgy parenthood.

<comment><USER11> SUVs and crossovers differ in the platform they are based on. SUVs are built on a truck platform using "body of frame" construction. Crossovers are built on car platforms and are typically unibody in construction. SUVs tend to have better ground clearance and are more commonly rear wheel drive.

<comment><USER7> The "body on frame" requirement isn't exactly definitive in my opinion. I consider the Honda Pilot and Nissan Pathfinder (latest gen) to be SUVs, at least as far as their intended market is concerned. They're as capable as a non-Z71 Tahoe is offroad (enormous and fragile airdams) and they are all within the same ballpark when it comes to towing capacity (5,000lbs for the Pilot/Pathfinder, 6,400lbs for the Tahoe) as there's nothing I'd tow with one that I wouldn't feel safe towing with the other (hardly anyone will put a Class IV hitch on a Tahoe).

The difference between the hottest selling crossovers like the CX-5/Forester/Escape/CR-V/Rav4 and the "soft-road" SUVs like the Pilot/Pathfinder/Traverse/Explorer is that they have redefined crossover to mean a vehicle based off a compact sized platform, with compact sized engines (all 4 cylinders), delivering compact-sized fuel economy (30mpg+), with absolutely 0 consideration given to off-roading (all FWD with AWD being a complete afterthought). The "soft-road" SUV is based off a mid-size platform, if not it's own and still gives credence to things like towing, real AWD, and imposing size without significantly larger interior room (the CX-5 in particular feels as roomy as most full-size SUVs) The modern crossover is in every way a "tall wagon", just with a better name.

<comment><USER2> > real AWD

You mean 4WD, right? They aren't really the same thing, or at least, a decade ago they were still considered separate, if often confused by the public. Are the current SUVs offering AWD or 4WD (or do they offer both on select variations/models)?

<comment><USER7> No, I mean real AWD. The systems used in smaller crossovers are such afterthoughts that they are only able to handle a tiny fraction of the drivetrain's torque continuously. They may be able to handle up to 50% for a period of time but the tiny little clutches would fry themselves if they weren't protected, thus neutered, by software. They exist to fill out the highly marketable checkbox of "AWD" and to provide some assistance once the vehicle is in motion but they cannot be depended on to deliver the performance of a more traditional AWD system.

See the Honda CR-V for an example: [https://www.youtube.com/watch?v=jkiv- bWbLIo](https://www.youtube.com/watch?v=jkiv-bWbLIo)

The same "trick" has been applied to the Focus RS. It's "AWD" but the system is so weak that it can never live up to the expectations of those who think the AWD system will perform like that of a Subaru WRX or a Mitsubishi Evo. Source: [http://www.vorshlag.com/forums/showthread.php?p=58372](http://www.vorshlag.com/forums/showthread.php?p=58372)

<comment><USER2> I was referring more to the "soft-road" segment, as you termed it. Ford Explorer, etc.

I had a 2004 Explorer Sportrac (which is actually on the ranger chassis instead of the F150 chassis like regular Explorers IIRC), and it definitely had real, wheel locking 4WD in low and high gear, and as such it was dangerous (illegal?) to drive on pavement with it.

<comment><USER7> Your generation of Explorer was from the era where it was still a true SUV. Ford introduced the Freestyle in 2005 which was among the first attempts to reach the modern "crossover" market. It was based off a modified Volvo sedan platform with unibody construction and a FWD focused layout. Unfortunately, it was a product ahead of its time as consumers had yet to warm up to the "tall wagon" approach to crossovers.

My point in mentioning the Freestyle is that when it came time to release the 2nd generation, Ford elected to merge the fundamentally sound "crossover/soft- road" concept with the power of the Explorer name. The 5th generation Explorer is a 2nd generation Freestyle/Taurus X in all but the name. The auto industry press was extremely skeptical of such an extreme change in the design philosophy of a truly iconic vehicle. However, despite concerns over the large reduction in "truck" capabilities (massive reduction in approach, departure, and breakover angles as well as towing capacity), the market had stopped caring about such features. Sales are roughly double or even triple those of the 4th gen Explorer in its last years and are an order of magnitude greater than the worst years of the Freestyle/Taurus X.

Source: [https://en.wikipedia.org/wiki/Ford_Explorer#Fifth_generation...](https://en.wikipedia.org/wiki/Ford_Explorer#Fifth_generation_.282011_.E2.80.93_present.29)

<comment><USER2> Ah, that's a shame. That said, I have been noting how good the new Explorers look. To my eyes they look somewhat comparable to the Range Rover Sport. I imagine the new form has quite a bit to do with the sales.

From your link:

> The development of the fifth generation Explorer was led by chief engineer > Jim Holland, who was also a chief engineer for Land Rover; heading > development of the Land Rover Range Rover (L322) 2005 face-lift.

Ah. That explains it.

From the "capability" section under the link you provided, it looks like the AWD system has some interesting 4WD simulation modes, so it's not a complete departure, but I have no idea how well those perform in practice.

<comment><USER7> >(T)he AWD system has some interesting 4WD simulation modes, so it's not a complete departure, but I have no idea how well those perform in practice.

The Explorer is still solid enough to get you through most winter conditions but it's no longer an offroader if that's what you're looking for. Just look at the approach/breakover/departure angles and you'll see that the most off- roading it's designed for is parking on the grass next to the lacrosse field. I'm not saying that to disparage the concept of crossovers and soft-roaders, I think they're brilliantly designed to match the way they'll actually be used which makes them far more efficient. However, it you're looking for an actual truck, they are no longer for you.

<comment><USER2> Ah, well since the only thing I ever used the 4WD for was snow/ice on the way to Tahoe and to pull a boat up a slippery launch, it's probably totally sufficient for what I was using the 4WD in my Explorer for. I agree it's probably a better match for the actual expected use for most other people as well. I'm not sure the explorer was ever the platform of choice for people looking to make a rock crawler...

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> So the vw bus? The 60's cabover vans? Those don't count?

<comment><USER11> The drive train has a lot to do with the classification. VWs were rear wheel drive, same as many of the cab over vans. Most minivans are front wheel or all wheel drive.

<comment><USER12> My old ford areostar, very much the accepted minivan, was rwd, as are many safari, etc. That argument doesn't stand up to data. The fwd swich came primarily to reuse drivetrains cheaply from fwd sedans as they became popular and efficient.

<comment><USER13> I'd say that the "minivan == unit-body/transverse engine/FWD" taxonomy is the correct one.

I mean, what are the counterexamples?

-the body-on-frame/rwd/solid axle Aerostar/Safari/Expo were...slightly smaller than the domestic quarter ton vans. not really mini, plus all the drawbacks of high floor height, bad fuel economy, truck handling etc. of the full size vans.

...which is why they aren't sold anymore.

-the VW Type 2/Vanagon:

Customers didn't like rear-engine handling. Or two-digit hp in a 5000lb gvw vehicle. Plus it's hard to make forward control layouts pass front-impact tests. So, a design dead-end.

-Mid-engined Japan-vans

High floor height, weird service position, once again, crash safety became an issue.

Of course, I'm happy that all these vehicles existed, and surely many customers felt their advantages outweighed their deficiencies...but on the whole, the Chrysler model ended up defining the market as it exists today, in the same way the Mercedes W124 defined "luxury car".

<comment><USER14> Not that you're generally wrong otherwise, but the Vanagon was around 3000 lbs curb weight (and a bit more for campers). 5k was the GVWR, i.e. max safe loaded weight.

(Edit: missed gvw when I wrote this, but it's unusual to typify a vehicles P/W ratio by GVWR. That's more a comment on its structure and suspension.)

<comment><USER13> Yeah, I couldn't remember the curb weight off the top of my head, but I did remember the 5k gross. It still describes a very sturdy, solid one and a half ton truck with a one ton capacity frame and suspension...powered by a 80-90 hp gas (or 52 hp!!) diesel motor. :-)

Had there been the Oettinger flat-six available in US-market transporters from the beginning, perhaps the minivan market would've turned out a little different....

<comment><USER3> I've got the 52hp diesel Vanagon camper weighing over 4,500 in my garage. Freeway performance is..... underwhelming.

<comment><USER15> 67bhp in our '81 Westy. I view keeping the speed limit on any incline to be a victory. You diesel owners I view as masochists. :-)</comment></comment></comment></comment></comment></comment></comment></comment>


The Financial Crisis in simpler terms...drinkbonds, alkbonds, and pukebonds - <AUTHOR>

via e-mail:
The financial crisis explained in simple terms.......
Heidi is the proprietor of a bar in Berlin. In order to increase sales, she decides to allow her loyal customers - most of whom are unemployed alcoholics - to drink now but pay later. She keeps track of the drinks consumed on a ledger (thereby granting the customers loans). Word gets around and as a result increasing numbers of customers flood into Heidi's bar.  Taking advantage of her customers' freedom from immediate payment constraints, Heidi increases her prices for wine and beer, the most-consumed beverages. Her sales volume increases massively.
A young and dynamic customer service consultant at the local bank recognizes these customer debts as valuable future assets and increases Heidi's borrowing limit. He sees no reason for undue concern since he has the debts of the alcoholics as collateral.  At the bank's corporate headquarters, expert bankers transform these customer assets into DRINKBONDS, ALKBONDS and PUKEBONDS. These securities are then traded on markets worldwide. No one really understands what these abbreviations mean and how the securities are guaranteed. Nevertheless, as their prices continuously climb, the securities become top-selling items.
One day, although the prices are still climbing, a risk manager (subsequently of course fired due his negativity) of the bank decides that slowly the time has come to demand payment of the debts incurred by the drinkers at Heidi's bar.  However they cannot pay back the debts. Heidi cannot fulfill her loan obligations and claims bankruptcy.  DRINKBOND and ALKBOND drop in price by 95 %. PUKEBOND performs better, stabilizing in price after dropping by 80 %.
The suppliers of Heidi's bar, having granted her generous payment due dates and having invested in the securities are faced with a new situation. Her wine supplier claims bankruptcy, her beer supplier is taken over by a competitor.  The bank is saved by the Government following dramatic round-the-clock consultations by leaders from the governing political parties.  The funds required for this purpose are obtained by a tax levied on the non-drinkers.
Finally an explanation I understand... <comment> andrewl-hn For me the reasons are not really interesting anymore. The world economy is f*cked up.

Now what?

<comment><USER2> Now it is useful to identify the human behaviors that led to this and insure we do not make the same mistakes again.</comment></comment>


Show HN: GiveHongBao – Raise Ethereum for any cause, anywhere in the world - <AUTHOR> https://givehongbao.com/campaigns/support-jimmy-wales-of-wikipedia-and-net-neutrality-this-holiday-season <comment><USER2> You're raising money on behalf of other people and, presumably, pocketing some of it (even if you're say you're not, how do we know for sure?) Brave is doing this sort of thing too with their attention tokens and it strikes me as super shady. "I'll totally give it to them, honest!" doesn't seem good enough. You wouldn't get a fraction of the money you asked for if you didn't have the Wikipedia and EFF logos on that page.

<comment><USER3> That's what Ethereum is for.

It's completely public and can't be tampered with, so you can check exactly where the money is going.

Btw. most people people who don't know Chinese will think "Hong Bao" is some guy. Bad branding for what it's trying to do. Gives the wrong impression that we're giving away money to some guy named "Hong Bao" who's promising to give it to Wikipedia and EFF

<comment><USER4> So what does it mean actually?

<comment><USER5> They're red envelopes of money that are handed out during Lunar New Year in some Asian countries: [https://en.wikipedia.org/wiki/Red_envelope](https://en.wikipedia.org/wiki/Red_envelope)

</comment></comment></comment></comment><comment><USER6> This should be free and GiveHongBao should have their own donation page within the system. Charging a fee (even if flat) for donations doesn't feel right. They aren't offering enough value (they basically give you an HTML page) on top of Ethereum to justify a fee.

<comment><USER3> Unless I missed something, isn't that "fee" part just Ethereum transaction fee?

<comment><USER6> "We don't charge a percentage of what people give. Instead, we charge a flat amount for any amount donated. Keep more of what people give."

I don't think is the Ethereum gas (transaction fee). I think they take a cut as well. Perhaps someone can check the transaction being generated and see the recipients/gas? This whole thing looks very shady and probably shouldn't be getting HN-like exposure.

<comment><AUTHOR> Hi all. The contract that distributes donations also transfers a fixed fee to my account. For instance, see: [https://etherscan.io/tx/0xc27a96a1ed705b03604b91287d0e2cf76f...](https://etherscan.io/tx/0xc27a96a1ed705b03604b91287d0e2cf76fc8a463cfc2a07d7a3d0cd8138a988d)

The fee is flat and priced around a buck, mostly to help recoup some server costs, hosting costs, etc.. which I thnk is fair.

My main motivation was to make a cheaper version of GoFundMe or Patreon. Both of those sites charge a percentage on top of whatever credit card fees.

<comment><USER6> Please make the mechanics and fees clearer on the website. Linking to and explaining the contract would be great for transparency. With that done, I think your service can be useful.

</comment></comment></comment></comment></comment><comment><USER7> I realise that you would probably won't do this, but it'd be awesome to see some of this open sourced. Despite being reasonably experienced, the idea of building an API that talks to a smart contract is completely alien to me.

I also wouldn't have any idea on how to build up the actual smart contract "system" that your API talks to, so any insights on where or how you learnt all of this would be pretty awesome.

Most of the examples I've seen are not that beginner friendly.

</comment><comment><USER8> [https://givehongbao.com/campaigns](https://givehongbao.com/campaigns) 404?

<comment><AUTHOR> That page will 404 since there's no campaign (campaigns are at addresses like: [https://givehongbao.com/campaigns/support-jimmy-wales-of- wik...](https://givehongbao.com/campaigns/support-jimmy-wales-of-wikipedia- and-net-neutrality-this-holiday-season)

If you want to create a campaign (free of charge) visit: [https://givehongbao.com/create](https://givehongbao.com/create)

<comment><USER9> [https://givehongbao.com/campaigns](https://givehongbao.com/campaigns) might be a good place to list the campaigns that are currently live.

<comment><AUTHOR> Indeed! That's a great suggestion ...

<comment><USER8> Yeah, when home page only has "Login" and "Create Campaign" and /campaigns 404s, it makes me skeptical the site is legit

</comment></comment></comment></comment></comment><comment><USER10> Great idea! I created this campaign [https://givehongbao.com/campaigns/drink- beer](https://givehongbao.com/campaigns/drink-beer) and wait for a day that I can drink beers for the rest of life.

</comment><comment><USER11> Refreshingly simple, this is one of the better display of what an MVP is. Congrats!

<comment><USER11> @op How long did this take? Was it all just you?

<comment><AUTHOR> OP here. I started this project a few months ago, around early October. I wrote the meat of the solidity contract in a weekend or so, but the hardest part (of course) was writing all of the UI. That took another few weeks of intermittent nights and weekends.

Since then, I've just mostly been putting polish on it (testing, more refinements) mostly around making the app more responsive.

Happy to talk more about it-- it was a fun project that pulled together a lot of threads (Solidity, React, Web3, Infura, etc..)

</comment></comment></comment><comment><USER12> Why people can't just send cryptocurrency from their wallet to any address they want to donate instantly?

</comment><comment><USER13> I'm curious about the name.

<comment><USER14> HongBao means "red envelope" in mandarin. It's usually filled with cash, and is something we give to other people as gifts in festive occasions.

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

<comment><USER15> It's odd because, for me, Red envelopes are associated with personal, discretionary, Holiday gift, not charity, evergetic or common good.</comment></comment></comment>


Debian 9 "Stretch" released - <AUTHOR> https://lists.debian.org/debian-announce/2017/msg00003.html <comment><USER2> No fglrx support... I wonder why. ( Not that the radeon driver isn't good enough, it just surprised me a bit at reboot. )</comment>


Is a resume relevant in the age of online courses and open source projects? - <AUTHOR> http://arstechnica.com/information-technology/2012/09/is-a-resume-relevant-in-the-age-of-online-courses-and-open-source-projects/ <comment><USER2> _"The problem is that I have no idea how to tell employers that those (SO, GH, etc) are the places to look if they want an accurate description of what I can do."_

So you are looking for a concise and centralized resource for listing your qualifications for a job. And you are asking if a resume is still relevant? It seems like the way to tell employers about your github, SO, udacity, etc, profiles is to list them on your resume.

</comment><comment><USER3> I am actually a fan of well written resumes. The problem is that a resume is not a CV or even a listing of all skills/qualifications of an applicant. A resume should be a highlight reel of the skills/experience/qualifications of the applicant THAT PERTAIN TO THE JOB BEING APPLIED FOR. The cover letter then explains how those skills go together and what the applicant is looking for. Github, open source projects, web sites, examples, etc. are supporting evidence once they've gone from an unqualified lead to a qualified lead. But that's the difference that people seem to forget, a large majority of job positions are filled from unqualified leads and spending 20 minutes per applicant with nothing indicating they even have the minimal skills necessary.

</comment><comment><USER4> A resume is a listing of what you have done in your life that could be relevant to the job you are applying for. If that is an online course and a couple of open source projects, then this can be just as helpful to your future employer as a list of companies you have worked for.

To resume means to summarize. Your GitHub profile is not a summary, it is a raw dump of everything that you have done without weighting.

So, of course a resume is still relevant today. And it is still up to the applicant to present himself to the employer, because most of the time the applicant is looking for a specific job when the company is not looking for a specific employee.

</comment><comment><USER5> For what its worth, one of the last hardware devs we hired happened exclusively online. We were adding some biometric hardware to our current software stack and came across a small project online of someone who wrote a java library for the hardware in question.

After a series of emails, we proposed that we should pay him a few months consulting fee - to help us integrate. As a bonus of course, he could take the improvements and fold them back into his his open-source project.

Things continued like this and eventually he proved useful in other ways, so he is permanent hire now.

In this day and age, there really is no excuse for having "no experience" (in the software world at least). Moreover, who really cares about what university you went to if you can prove your immediate usefulness in other ways?

</comment><comment><USER6> I work for a company that makes recruiting products to fortune 500 companies. They don't offer online courses to cashiers working for big retailers, or to truck drivers working for transportation companies.

Jobs at technology companies might be what ArsTechnica and Hacker News readers go for, but those jobs are such a small percentage of the jobs filled every day in the US.

</comment><comment><USER7> As one data point: a resume has never been relevant to my career. I've never gotten a job or a contract through a resume.

Completed live projects instantly visible on any browser or smartphone with a quick technical explanation have always been far more valuable for me.

You don't need to ask anyone's permission to build amazing software.

(Unfortunately, you continue to need permission to build many other things.)

</comment><comment><USER8> As someone who screens a lot of resumes; it's a good short overview and it's relevant. Github/open source projects/online qualifications don't show all there is to experience. Sure if someone started a bunch of projects to try to right the wrongs in the software world then this is a good sign. But if that person doesn't have or believes he/she doesn't need a resume then that's not a good sign. A resume is often a first line of defense; there will be a stack of them and those are screened pretty quickly at most companies. Something needs to attract enough attention to even _check out_ your github and online qualifications. Your github account right there in your list mobile/email/skype/github is a pre, even if it's empty though :)

</comment><comment><USER9> GitHub et al only provide a very small part of what I'm looking for on a CV/Resume. It's an vital small part - but a small part nevertheless.

The biggest unanswered questions I'm trying to figure out are:

* what value are you going to bring to the organisation (from the value you demonstrate bringing to your previous positions)

* how well you're going to fit into the team (from how you talk about your previous roles)

* how well you understand the position and the organisation (from how you target the information you present)

GitHub et al don't really help with these much.

What GitHub et al do is make fact checking / reference chasing easier. You include some links to github and lanyrd and your background looks more credible - but by themselves they're not going to get you the job.

</comment><comment><USER10> Some of the most interesting developers can't talk about what they've done.

You'll never see the flight computer system of an F-16, but it's probably a much cooler project to work on than an iPhone app. Or nuclear reactor engineering.

Is a resume relevant in this day and age? As a device to portray the best of what you've accomplished yes. For a few people, the answer will be no, that's best done through portfolios like github and open source projects.

In the end, everything old will be new again but with a twist.

</comment><comment><USER11> A London-based start-up is working on future-facing CVs. The premise is you say what you're going to do, and then do it. Over time you build up something stronger, with social proof. It's called WikiCV: <http://WikiCV.me>

</comment><comment><USER12> This is exactly why we started Entelo. We felt that online sources are quickly becoming the "new resume" and that if you draw the trend lines on the data, if it's not obvious now, it will be very soon. Remember, none of the sites referenced in the post (Github, Stack, Coursera, etc.) existed five years ago. What will exist five years from now?

Also, an emerging trend is "Github for X". You have sites like Grabcad (Github for Mechanical Engineers), Dribbble and Behance (Github for Designers), Benchling (Github for Biology), Proformative (Github for Accountants), etc. As these professional communities grow they'll increasingly be looking at by employers.

It's early for this trend but we believe deeply in it.

</comment><comment><USER13> How many people can look at a github project and tell how good a coder you are, how well you work with others, what sort of team you mesh well with, what industries you've worked in and so on?

And how many of those people are the ones making hiring choices?

<comment><USER14> And how does a resume do any of those things?

</comment></comment><comment><USER15> Employers will not retire resumes because they know better than anyone else that online activity is classified as marketing rather than individual achievement. If you generate this kind of online activity, good for you, it makes it _easier_ to find a job or to sell a product. It may even replace a traditional job. But having a degree from a top university, having a position in a well know company, receiving a prize recognized in the industry, these are things that really count as achievement. Unless you're talking about internet marketing positions, these are the things that really matter to an employer.

<comment><USER16> "having a degree from a top university"

If you're applying for a position at a company that has HR minions guarding the gates to the hiring manager, then yeah this is great. If you're being hired by an individual with development experience this isn't likely to cut a lot of ice.

Here's why: several of the best developers I've ever met do not have degrees. Some didn't even bother graduating from highschool. I've worked with many developers that had degrees from name brand schools that couldn't find their ass with both hands and a map. Everyone I know in industry has had similar experiences.

"having a position in a well known company"

This at least gets you some name recognition and opens the doors to quality networking opportunities, but there's no guarantee that Name Brand Corp. didn't make a hiring mistake when they brought you on in the first place, so again, time for some healthy skepticism from the hiring manager.

"receiving a prize recognized in the industry"

Either this kind of opportunity is so rare that it's effectively out of reach for the overwhelming majority of developers in $industry_segment OR it's a valueless rubber stamp (see also: MS certifications).

"Unless you're talking about internet marketing positions, these are the things that really matter to an employer."

Your talking points imply that you define "employer" as medium to large corporation with a formal HR department and it's hiring practices stuck in the 90's. Typically a great gig if you're into grinding B2B middleware code for industry median pay and two weeks vacation. If that's what you're into that's cool I guess.

Compare/contrast an experienced FOSS contributor for a well-known project. Fending off recruiter calls and getting cold called for consulting gigs three or four times a week is the norm. Tech interviews are typically pared down to seeing if your personality will fit with the rest of the team because they already know you can code.

Resume? No thanks. Show me your code and then let's have a beverage and chat.

<comment><USER17> >> Resume? No thanks. Show me your code and then let's have a beverage and chat.

What is this hipster hiring? Give it 10 or 20 years bud you'll be singing a different tune or afraid to try to get hired as a coder and just pulling manager duty 3 or 4 levels up in the middle quietly re-assuring yourself that you could code and get a job in that new language eebbityfribitz ... if you really wanted to.

<comment><USER16> So you assert a couple pieces of paper that contain a view of someone's career from 30,000 ft (assuming it's even accurate) is some how preferable to being able to download, run, debug and in general interact with a potential hire's code? If you say so.

2nd assertion, that at some point in the next 10 to 20 years I'm going to run into some unspecified difficulties with the hiring process, resulting in me shifting career tracks to management? Would you mind unpacking the thought process behind all of this?

</comment></comment></comment></comment><comment><USER18> All my work is on code I don't own and isn't public facing. I can't take our proprietary code, wrap it up, and put it on GitHub. I also can't provide logins to our proprietary systems for employers to look at.

I certainly hope a resume remains relevant for people in my position, because it's really all I have.

<comment><USER19> Yes, "show me the github" is one of the worst trends for software developers' careers.

I'll always ask for live code from people at interviews, if only to filter out the total posers.

<comment><USER20> > Yes, "show me the github" is one of the worst trends for software > developers' careers.

On the other hand, there are benefits to posting code online that they can review. Instead of spending hours writing code for each company that you're interviewing with, you can just write code that you're actually interested in and throw it online.

Say you're talking with 20 companies. Each of those 20 interviews have an associated overhead of 3 hours (if you're lucky): 1 hour screening call, 1 hour technical call, 1 hour live coding call. So 60 hours of screening, versus writing some code that might actually be usable by others in the future.

Don't be afraid to say no to live coding interviews. Unless you have nothing to show :-).

<comment><USER19> Some people are completely useless. Remember, there are people out there who can't write Fizz Buzz yet still apply for jobs. They can easily fake a GitHub.

Someone who won't write code upon request is an instant no-hire.

<comment><USER20> > Some people are completely useless. Remember, there are people out there who > can't write Fizz Buzz yet still apply for jobs. They can easily fake a > GitHub.

So you're saying they can use git-filter-branch, but not write Fizz Buzz? Sounds fishy to me.

</comment></comment></comment></comment></comment><comment><USER21> These arguments that the only worthy developers have tons of public facing open source projects are tiresome.

Probably less than 1% of developers have GitHub repos and there's no correlation between skill level and having a GitHub repo.

If you have extensive and current open source contributions, for most people it means you're unemployed, or you're violating your employer's contract terms.

Evaluating a GitHub repo for a summary of skills in not a trivial task, as scanning a resume is.

When all of your work is online, it suggests you are not spending much time contributing value to whoever is employing you.

Companies that can't find developers often have bizarre and useless criteria such as "must have GitHub repository" or "must have LinkedIn" or "must have FaceBook", none of which is correlated with ability.

We hire lots of capable people without GitHub repositories.

<comment><USER22> Depends on what stack you're working with, and the associated broad engineering culture. I haven't hired anyone who didn't have a Github repo in 2 years, out of 18+ FTEs and contractors - but we're a Rails/Scala/node shop building fancy web apps for startups. Not having a huge OSS track record is fine, but not having a Github account at all would be kinda weird these days. If we were doing embedded systems stuff or financial modeling software or game development, probably a lot less relevant. The "show us your Github, not your resume" line in a lot of job posts is more about the specific engineering culture in a particular kind of startup development, not a hard and fast rule for every software firm everywhere.

That said, if you're a Rails developer and you don't have a Github account, I'm still probably not going to read your resume.

<comment><USER23> Do you expect Rails developers to have their own pet projects that they put a lot of time into? I agree it would be strange if no one had any forks, had never done a pull-request etc.

<comment><USER22> Pet projects? Absolutely not, although never a minus. ;) More: are you engaged with the community enough to be aware of the current ecosystem, (handwaving) "best practices", libraries/gems, etc. If someone claims to have been building Rails apps for 5 years, but has never heard of Devise and Carrierwave, it's definitely a red flag for me. If you're trying to get a job on the Google search team and can't whiteboard a quicksort it's going to be an equivalent red flag for them. I'm trying to attract a specific type of developers for a specific kind of programming work where caring about this kind of stuff is useful as a signaling factor to me.

It's not about requiring everyone who works for us to be a 23 year old with no family or life who spends every night hacking on shit, just about a baseline standard for community engagement. Lack of Github account with some level of activity (even if that's just starred repos, forks, etc) is a pretty strong indication someone wouldn't meet that level of engagement, and so wouldn't be a good match.</comment></comment></comment></comment>


Britain's first floating solar panel project installed - <AUTHOR> http://www.telegraph.co.uk/earth/energy/solarpower/11110547/Britains-first-floating-solar-panel-project-installed.html

<comment><USER2> This seems like such an inexpensive way to install solar. I don't understand why it's not more popular?</comment>


Widgy: Open Source Python/Django CMS Framework - <AUTHOR> http://wid.gy/ <comment><USER2> Holy god, this is awful.

I'm not sure why developers continue to believe that "tree of widgets!" is a good design for a CMS. It's horrendous.

First, most CMS users are end-clients who will have absolutely no clue to handle a drag-and-drop dependent UI, let alone a nested tree of UIs.

Second, it encourages a site structure where the content is stored hierarchically according to display requirements, instead of the actual semantic relationship between elements.

While I'm sure this is very well coded, it continues the long tradition of content management systems built by developers for developers and in such a way only other developers will like or understand.

<comment><USER3> You make two very good points, but I think this tool still has some important use cases.

I agree that this is a poor way to structure a whole site, but there's still a need for a way to produce _ad hoc_ pages.

I also take your point about the tree of widgets thing, but there is always a trade off between conceptual-ease-of-use and power. There are plenty of users who will do just fine with this interface.

<comment><USER4> I work on widgy, so I admit that I'm very biased, but I'd like to expand on this a little bit.

I think there are some use cases where the tree structure really shines, where I haven't really seen anything that could really match the power that we give the user. For example, the Form Widget -- users can create their own forms just by dragging and dropping the form input widgets. Now this would be possible without the tree structure, but since we have it in widgy, users are able to intersperse non-form related widgets like text or images and also they can add structure widgets like the Tabs or Accordion widget.

> I also take your point about the tree of widgets thing, but there is always > a trade off between conceptual-ease-of-use and power.

We do find that our clients are willing to take a little time to learn the interface in exchange for the ability to have more power.

</comment></comment></comment><comment><USER5> This seems to be built on top of Mezzanine--in fact, the word "Mezzanine" appears in the upper left-hand corner in the admin in the demo.

Is this some kind of fork of Mezzanine, or is there something else going on here? Is this meant to run on top of Mezzanine? In spite of similarity in the admin, reading through the code quickly doesn't seem to reveal any clues (or much of any similarity at all with the other project).

<comment><USER4> If you were curious as to how it is integrated with Mezzanine, here are some links:

* [https://github.com/fusionbox/django-widgy/blob/master/widgy/...](https://github.com/fusionbox/django-widgy/blob/master/widgy/contrib/widgy_mezzanine) \- the widgy_mezzanine "contrib" app. It provides a Page subclass that has a WidgyField on it.

* [http://docs.wid.gy/en/latest/tutorials/widgy-mezzanine-tutor...](http://docs.wid.gy/en/latest/tutorials/widgy-mezzanine-tutorial.html) \- a tutorial for getting started with Mezzanine and widgy.

[edit -- formatting]

</comment></comment><comment><USER6> This is a PMS (Page Management System), not a CMS. With this, you can only build _pages_ , not _reusable content_.

A CMS must be able to display the same content in different ways, display content filtered according to relationships, and so on. Not to mention render in other content types than just HTML.

I'm sure this is fine and fun to build pages with though!

Also: the demo is broken… so this is based on what seems to be their main selling points.

<comment><USER7> > A CMS must be able to display the same content in different ways, display > content filtered according to relationships, and so on. Not to mention > render in other content types than just HTML.

That's quite rigid. Good to ask the question: what is a CMS? It's pretty ambiguous.

</comment></comment><comment><USER7> +1 for having a usable demo to play with off the bat.

I tried to publish a simple page from the demo. But I did have problems:

I created a callout, and then created a page. I then tried to add the callout to the page. And save as published. But I was hit with a message: need to commit first? I didn't get that.

I then saved as a draft, and then hit commit. Not sure what was happening.

I then tried to view the page, but got a 'No content' message.

I then added something to the main content of the page. And saved. No change.

I then commited again. But still had the 'no content' message.

I then tried the commit and approve, which seemed to finally publish the page.

Confusion lies in the commit part, or in the publishing process, order of process. Some buttons looked deactivated, but actually you can click on them, like the 'Commit and approve' button. I was a little perplexed.

The demo then reset itself before I could test a form!

All feels slow to me. But then again most online CMSs feel a little like that to me.

It was also quite difficult dumping widgets into areas. A little practice got there, but it wasn't the easiest of things for me to do.

<comment><USER4> Thanks for the great feedback, I'm so sorry that you got hit by the cron job.

> +1 for having a usable demo to play with off the bat.

Thanks.

The idea behind the versioning system is that for a lot of our clients, the people who are editing the pages are not actually allowed to publish them. Those users will not see a Commit and Approve button, they only have the Commit button. Later, somebody who has full privileges will review the commits (either in the History or in the Review Queue) and decide whether or not to approve those pages.

If you wanted to see the version that you were editing (we call it the working copy), you can click on the preview button located next to the Commit and History buttons. You can even test the form from the preview page and it will still work.

> Confusion lies in the commit part, or in the publishing process, order of > process.

I think you are absolutely right that this flow is confusing. We will talk about how to make this flow better and more obvious.

> Some buttons looked deactivated

I opened an issue for that <[https://github.com/fusionbox/django- widgy/issues/205>](https://github.com/fusionbox/django-widgy/issues/205>).

<comment><USER7> I totally get 'workflow': draft, unpublished, approved, published etc, and 'roles': creators, editors, moderators, publishers etc. I also appreciate the idea of having some version control.

With the demo it wasn't intuitive how the above applied to the post, or the creation process. Order mattered, but it wasn't straight forward figuring out the required process. Resulting in frustration.

You speak of a staging area, or some such. But how is the user to know about your version control system, or how it works?

Surely hitting save should be as good a commit? Or the save implies or triggers a commit? If the commit is that important to the publishing process, emblazen it across the bottom with the Save button.

I really just wanted to see how my page looked as early as possible. And be able to see the page before it was published. You should be able to preview content, but make it clear that the status/workflow of the page you are viewing: You could add a banner across an unpublished page with the page status displayed.

</comment></comment></comment><comment><USER8> Very well done! The best part of Widgy is the ability to create custom pages and forms with drag and drop widgets.

I had been working on figuring out a solution such as this. The ability to use this and extend the widgets is really powerful.

</comment><comment><USER3> _[deleted]_

Forget what I said earlier. I thought Widgy was a CMS, but it isn't. It's a page editor for a CMS.

In combination with Django CMS 3, this could be awesome. The Django CMS team have put a lot of effort into moving as much of the administration as possible into the front end. Widgy complements this with a slick drag-and-drop interface for adding and rearranging page content.

<comment><USER9> django CMS 3 has drag-and-drop for re-arranging pages and the contents on the pages themselves. Could you expand on what Widgy does better here?

<comment><USER3> Django CMS has a content view and a structural view, and they clearly want you to spend most of your time in the content view. The structural drag-and-drop interface is barebones and, to the naive user, it's far from obvious how the nested lists of grey blobs relates to the actual content on the website.

In contrast, Widgy's interface attempts to be more like a WYSIWYM structural editor. New widgets are created by dragging them from a widget palette. Draggable objects represent their content in some way, and the physical layout of the widgets and dropzones matches the layout of the webpage being designed.

</comment></comment></comment><comment><USER10> My main problem with Django CMS frameworks is that they all use the django admin which quickly becomes a PITA when you want to modify it. I'm really starting to prefer rolling my own easy to use admin interfaces to trying to override the django admin.

<comment><USER11> I strongly feel the exact opposite. I've worked with the Django Admin extensively since 0.98 and it gets more flexible and easier to customize with every release.

There's an astonishingly large ecosystem of widgets, extensions and additions and having a single point of integration that (mostly) everyone agrees on allows them all to work fairly well together.

There are things that I wish could be improved about the admin - mainly to do with the slightly old-school HTML and CSS behind it - but there are so many points where you can override, replace and extend that the good outweights the bad.

<comment><USER12> >There are things that I wish could be improved about the admin - mainly to do with the slightly old-school HTML and CSS behind it - but there are so many points where you can override, replace and extend that the good outweights the bad.

I use this: [https://github.com/django-admin-bootstrapped/django-admin- bo...](https://github.com/django-admin-bootstrapped/django-admin-bootstrapped)

It seems to work pretty well.

<comment><USER11> Except all the HTML is now different to the standard admin and lots of 3rd party apps break.

Unfortunately - there is a limit to how much you can alter the admin HTML without this problem. My own admin skins have been CSS only precisely to avoid this.

</comment></comment></comment></comment><comment><USER13> Their tagline reads like the "future proof" or "never obsolete" stickers on 90s mid-tower PCs.

<comment><USER14> But is obviously tongue in cheek.

</comment></comment><comment><USER15> My first expectation was to be able to click and edit content, Instead I got pushed into a horrible tree structure of pages that got me to a tree structure of editable widgets. Yuck.

</comment><comment><USER16> Seems the admin interface is publicly accessible, which I assume is intentional for demonstration. This can only end badly.

<comment><USER3> But the _Commit change_ button is deactivated.

</comment></comment><comment><USER17> nicely done! But the drag and drop editor feels slow and unresponsive,maybe something like ckeditor would have been better.

</comment><comment><USER18> I'm a serious Drupal expert, but Python was my first love, I know Django and I'm all for a usurper that can do it.

That being said, with an arrogant shitty attitude like this page shows, it will never actually get there.

The most important facet of a CMS's success (or most software) isn't clean dependency injection and scaffolding, it is a strong community and humility.

<comment><USER19> Was that written by a script? The words make sense individually but not as a whole.

</comment></comment><comment><USER20> Just about everything is 404'ing right now (2014-05-13T09:23:00+02:00)</comment>


Ask HN: Does the windows format command securely wipe a drive? - vanilla-almond I have an external hard drive (not an SSD) that I want to wipe. Windows 10 has a format command with the option to specify the number of passes over the hard drive. If I set the number of passes to 3, will that result in a secure wipe of the drive? I don't want to physically destroy the drive, so am looking for a software-only solution for securely wiping the  drive. <comment><AUTHOR> [https://docs.microsoft.com/en- us/sysinternals/downloads/sdel...](https://docs.microsoft.com/en- us/sysinternals/downloads/sdelete)</comment>


Hog Bay Software: "while I really like new customers that's not really my goal right now" - <AUTHOR> http://groups.google.com/group/hogbaysoftware/browse_thread/thread/80cbd144a4a8d1c4?hl=en

<comment><USER2> I always prioritize existing customers over new customers. Unless your lock-in is very strong, and your marketing is stronger than word-of-mouth, it's the only way.</comment>


Ask HN: When to create a legal disclaimer for side project - <AUTHOR> Hi all,
I was just wondering how soon should someone create a legal disclaimer for their side-project while trying to validate an idea?
Is there a quick/easy way to perhaps generate a "standard" legal disclaimer that covers early usage until the project has progressed enough to warrant a proper legal notice form an attorney/lawyer?
Thanks <comment><USER2> IANAL, but I don't think there is a specific time to do this. On the other hand, if you have users I would err on the side of caution and at least put something simple up. A good resource for a privacy policy and terms of use is CooleyGo:

Terms of Use: [https://www.cooleygo.com/documents/terms- use/](https://www.cooleygo.com/documents/terms-use/)

Privacy Policy: [https://www.cooleygo.com/documents/privacy- policy/](https://www.cooleygo.com/documents/privacy-policy/)

</comment><comment><USER3> Wordpress has their pretty complex one under share-a-like license [https://en.wordpress.com/tos/](https://en.wordpress.com/tos/)

There's many "terms of service generator" type websites. Some free, some charge per section ([https://termsfeed.com/wizard/terms- service](https://termsfeed.com/wizard/terms-service)).

Personally I think we didn't have one for the first year, no user or paying customer minded or ask us about that. (not legal advise)

<comment><AUTHOR> Thanks for this!</comment></comment>


Mozilla showed me what the interwebs look like and now I have mad CoW disease - <AUTHOR> https://12bytes.org/15518/mozilla-showed-me-what-the-interwebs-look-like-and-now-i-have-mad-cow-disease <comment><USER2> when I read something like this it makes me happy that I don't use any addons, because evidently the removal of them is highly traumatic.

</comment><comment><USER3> Unfortunate for this poor person that he had to join the rest of the plebes (for a day) in helping to pay for the pristine Internet he holds so dear.

<comment><USER4> 'Helping to pay' stands for 'eating shit from websites and ad publishers'? Visual garbage, hostile presentation, unwarranted tracking and security vulnerabilities.</comment></comment>


What are the main benefits of Elixir compared to Clojure? - <AUTHOR> https://elixirforum.com/t/what-are-the-main-benefits-of-elixir-compared-to-clojure/29959 <comment><USER14> The main benefits of Clojure compared to Elixir?

I can create

      - Desktop apps
      - Server-side apps
      - Mobile apps
      - Unity games
      - Live coding music performance
      - AI apps
      - C libraries
      - Native apps

I can use libraries with low friction from the following ecosystems:

      - <USER5>
      - <USER3>
      - .NET
      - <USER4>

Runtimes include but limited to:

      - <USER5>
      - <USER6>
      - <USER7>
      - <USER8>
      - <USER9>

Clojure specific advantages:

      - <USER10>
      - <USER11>
      - <USER12>
      - <USER13>

Most "functional" languages bottom out into some highly mutable SQL thing and it's gross

Then there are the cultural things, so as you grew as a programmer you probably went imperative, OO to FP, well with Clojure you go another step: imperative, OO, FP, Data-driven: [https://youtu.be/vK1DazRK_a0](https://youtu.be/vK1DazRK_a0)

Technologies like this: [https://unity.com/dots](https://unity.com/dots), machine learning etc are showing that data and data processing is likely to yield the next frontiers in computer programming

The next things on the near horizon are data-driven declarative layers to raise the bar of abstraction like [https://youtu.be/jkx9F-RIFiY](https://youtu.be/jkx9F-RIFiY)

</comment><comment><USER15> Seems like the main takeaways from this are that concurrency on BEAM is amazing and the JVM can't match that. So it feels like it boils down to whether you like Ruby syntax versus Lisp syntax. For me that is a no brainer, I love Ruby but always worried about the limitations of the runtime. Is there anything else I'm missing? BEAM plus Ruby seems like an absolute winner here.

<comment><USER16> Yeah, that's what I miss about Beam's actors vs. actor implementations in the JVM - the design pattern was to write actors that blocked, which dramatically simplifies your code - on Akka actors, for example, you very much should not block the actor, because it blocks the JVM thread that is being used to run the pseudo-green threads, which makes it harder to write straightforward code.

<comment><USER17> loom ( [https://jdk.java.net/loom/](https://jdk.java.net/loom/) ) is well on its way :)</comment></comment></comment>