Ignition: An Informal History of Liquid Rocket Propellants (1972) [pdf] - <AUTHOR> http://library.sciencemadness.org/library/books/ignition.pdf <comment><USER2> This is one of the best technical books ever written.

My review on amazon:

"Rocket books are often page turners. I reviewed Sutton's "Rocket Propulsion Systems" a few years back. I picked it up as a cure for insomnia, and ended up reading most of it in one night. The nice thing about rocket science; it's not really "rocket science." If you have a background in physics or chemistry, rocket science is a perfect level of semi-light reading. There is chemistry, neat, but conceptually simple thermodynamics, mechanical engineering and materials science. None of it is at a really high level: rocket science is the type of thing you could do on a slide rule. People did.

This book has a similar quality; it's pretty easy to read (though I confess I bogged down a bit in some of the chemistry sections). I didn't read it for the science, though. I don't really care about rocket fuels. I learned the basics about rocket propellants from Sutton. It's conceptually simple "look at the periodic table" stuff. This book is about the implementation details, and how they were discovered. I don't plan on building any rockets any time soon, so it's more or less irrelevant to me. I suppose this could be helpful to folks who might have some ambitions to make some fancy rockets, but are too precious to use LOX and Kerosene or dinitrogen tetroxide and hydrazine.

Mostly, I read it because it's uproariously funny. Research involving physical objects is funny. Why is it funny? Because at the end of the day, we're really just dumb monkeys playing around with forces we only partially understand. Rocket research has some of the highest comedic potential because it involves smelly things which explode. Had I only known this, I would have arranged to have been born in the 1920s, so I could do all the cool research that happened in the 1950s. Alas, the heroic age of rocket fuel research is now over.

Still, we have these anecdotes, which are unique, and possibly eternal. To quote the book, "if you, gentle reader, have never seen a nervous rocket mechanic, complete with monkey suit, being buzzed by nine thousand demented bats and trying to beat them off with a shovel, there is something missing from your experience. ""

<comment><USER3> > None of it is at a really high level: rocket science is the type of thing > you could do on a slide rule. People did.

Rockets have a very fine line between a successful mission and failure. That means you've got to understand the math, do the math correctly, and understand and account for the limitations of the mathematical models.

Otherwise your rocket will be too heavy to fly, or will explode/disintegrate when flying.

Some other good rocket reading: "V2" by Dornberger

<comment><USER4> Ironically a lot of Ignition is about experimentation rather than modeling - while they could predict the energy of a reaction, all sorts of other vital properties like detonation resistance had to be found out empirically.

</comment></comment></comment><comment><USER4> Almost certainly a repost, but it's a tremendous little book. Mix of dry chemistry lab notes with hair-raising anecdotes. The history of early NASA rocket fuel research by someone who was there.

See also [https://archive.org/details/gergel_isopropyl_bromide](https://archive.org/details/gergel_isopropyl_bromide)

<comment><USER5> I'll second your Gergel recommendation. Gergel's book is not quite as good as "Ignition" because he brags a little more and gets specific a little less, but it's still good. The place it's better than "Ignition" is in the descriptions of the insane risks which early chemists took - with their own lives, their neighbors' lives, and the lives of anyone living there afterwards. It's a fascinating piece of anthropology.

</comment></comment><comment><USER6> Hear, hear! this is fascinating book that anyone interested in rocketry will enjoy. Even if you are not interested in the engineering or chemistry the description of the professional community and process of invention is worth reading.

<comment><USER7> > this is fascinating book that anyone interested in rocketry will enjoy

It's criminal to limit it to people interested in rocketry. It's also fascinating to anyone interested in chemistry, engineering, history, and plain "stuff going boom", one of the Internet's most hilarious stories (Derek Lowe's "Sand won't save you this time") is essentially a straight excerpt from Ignition!, on Chlorine Trifluoride:

> It is, of course, extremely toxic, but that's the least of the problem. It > is hypergolic with every known fuel, and so rapidly hypergolic that no > ignition delay has ever been measured. It is also hypergolic with such > things as cloth, wood, and test engineers, not to mention asbestos, sand, > and water-with which it reacts explosively. It can be kept in some of the > ordinary structural metals-steel, copper, aluminium, etc.-because of the > formation of a thin film of insoluble metal fluoride which protects the bulk > of the metal, just as the invisible coat of oxide on aluminium keeps it from > burning up in the atmosphere. If, however, this coat is melted or scrubbed > off, and has no chance to reform, the operator is confronted with the > problem of coping with a metal-fluorine fire. For dealing with this > situation, I have always recommended a good pair of running shoes.

And frankly, just open the PDF and look at pages 2 and 3, if that doesn't convince you the book is worth reading I'm not sure you have a soul.

Plus it's a very short book, the body itself clocks in at under 190 pages.

<comment><USER6> and since you brought up Mr Lowe, here are his articles on "Things I won't work with":

[http://blogs.sciencemag.org/pipeline/archives/category/thing...](http://blogs.sciencemag.org/pipeline/archives/category/things- i-wont-work-with)

<comment><USER8> His "How Not to Do It" articles are also a good read. Some good advice on how not to deal with liquid nitrogen tanks: [http://blogs.sciencemag.org/pipeline/archives/2006/03/08/how...](http://blogs.sciencemag.org/pipeline/archives/2006/03/08/how_not_to_do_it_liquid_nitrogen_tanks)

</comment></comment></comment></comment><comment><USER9> > There are, after all, some chemicals that explode shatteringly, some that > flame ravenously, some that corrode hellishly, some that poison sneakily, > and some that stink stenchily. As far as I know, though, only liquid rocket > fuels have all these delightful properties combined into one delectable > whole

The intro by Asimov was a delight to read.

</comment><comment><USER10> What I wouldn't give for a dead tree version...

is the set of all things worth more than about £10.

</comment><comment><USER11> Great book. But hard to find a print copy and be prepared to pay a LOT. Last time I saw on Amazon - a print copy was going for over a thousand USD.

Luckily my university library had one so was able to read it. Worth it.

</comment><comment><USER12> Elon Musk frequently cites this one among his favorites and a key book that taught him rocketry.

</comment><comment><USER13> This book is great. I've read it twice.

</comment><comment><USER14> this is a fantastic book, anyone remotely interested in space should read it.

</comment><comment><USER15> Amazing! Thank You !</comment>


State of the Art JavaScript in 2016 - <AUTHOR> https://medium.com/javascript-and-opinions/state-of-the-art-javascript-in-2016-ab67fc68eb0b#.37u0xx9xi <comment><USER2> I strongly disagree about TypeScript-- I think it's a huge boon to productivity. TypeScript has has union types i.e. "number | string" which are similar to algebraic data types. TypeScript also has optional interface members and function parameters by putting ? at the end of the name, i.e. "foo?: number".

Static types allow for much, much better tooling, particularly autocomplete and the ability to check whether your code is valid on some basic levels. I consider avoiding it to be a big waste of time. I've had a good experience getting the definitions files going for the libraries I use.

I also disagree with the statement that TypeScript is making JavaScript "like C# or Java". TypeScript lets you opt out of type checking all you want with minimal difficulty. It also will by default always emit JavaScript even if it detects type errors.

<comment><USER3> > TypeScript has has union types i.e. "number | string" which are similar to > algebraic data types.

I understand that you said "similar", but there's actually a _big_ difference that should be mentioned explicitly, namely that algebraic data type (ADT) sums always have "constructors" which you can use to disambiguate with. That means that you can meaningfully do the equivalent of "int | int" whereas for union types that would just be "int". (I'm sure you already know this, I'm just pointing this out for those who may not know or appreciate the subtleties.) Example:

        data Maybe a = Nothing | Just a

In this example the "constructors" are Nothing and Just.

Of course, you _can_ emulate first-order ADT sums using union types by just introducing artifical container classes and doing a union on those. While this works for simple cases, I believe (but cannot prove) that it's impossible to emulate GADTs using union types -- my intuition is that the presence of constructors to match on is an essential part of being able to "narrow" the types sufficiently to actually act upon what they "contain" (for each case).

 _However_ , and notwithstanding all of that... the use of union types in TypeScript is absolutely _the_ best way to align with JavaScript since there's so much JS that just takes/returns values of type "whatever" (string | number | ...).

Btw, also agreed on the productivity boost. In the short term, it may not appear that you're getting faster, but once your application starts to grow beyond "trivial" you really start to notice the fact that you can refactor without fear.

<comment><USER4> Flow has pretty good support for tagged unions like this which act like ADTs:

[http://flowtype.org/blog/2015/07/03/Disjoint- Unions.html](http://flowtype.org/blog/2015/07/03/Disjoint-Unions.html)

<comment><USER2> This is great. Seems less cumbersome than TypeScript's user defined type guards for distinguishing cases of a union. The sentinel value concept is something you could at least steal when creating user defined type guards to make them simpler, at least.

<comment><USER5> TypeScript union types and Flow tagged unions are nice to have, but to make them really useful you also have to provide a good way to pattern match on them. And there they both are still way behind Haskell.

</comment></comment></comment></comment></comment><comment><USER6> Disappointing that after months of moaning about the paralysis of choice, few of the comments are positive about a genuine and fairly defensible attempt to cut through that.

He proposes a fairly simple stack (and for the sake of argument he assumes you're needs are beyond the 'static html and a touch of jQuery' stage). He spends time explaining them and makes a fairly good attempt to avoid the overly-new or overly-complex.

We've had all the obvious reactions:

1\. This isn't my stack of choice

2\. React is flawed

3\. Don't use frameworks at all

4\. I hate dynamic typing

5\. Javascript is broken beyond repair

6\. It will have changed by next week

All of these are valid discussions to have but they get wheeled out every time and - maybe with the exception of point 1 - they are only indirectly related to the topic of this post.

So every js discussion becomes a meta-discussion. Same thing with Google posts ('oh they'll close that down next week'), ORMs ('they suck'), Python ('Python 3 was a mistake') etc.

HN comments needs an on-topic vs off-topic filter. Or a "yes we already know that" filter...

(The irony of the above statements when this is also a meta-post is duly noted)

My own feeling is that everyone should avoid jumping on complex frameworks until they are really needed. jQuery, Pjax or intercooler.js can take you a long way and save a lot of headaches. But when you do need a proper MVC-like framework then this article is a valuable guide of the sort that people have been asking for for months.

<comment><USER7> "HN comments needs an on-topic vs off-topic filter. Or a "yes we already know that" filter..."

They already do; if something doesn't positively contribute to the discussion, downvote it.

<comment><USER6> I wasn't entirely serious about the filters but that's a fair point.

I suppose what I'm actually saying is "Can we all downvote the more worn-out type of comments a bit more actively?".

Which now I'm come out and said it sounds overly optimistic. ;-)

<comment><USER8> Yes we can and I started by yours. Sorry not adding to the discussion.

<comment><USER6> I actually edited my top level comment immediately after writing it to try and engage more directly with the topic at hand and tone down the 'meta-ness' of my post.

Even so I'm slightly embarrassed that it's the top voted comment. I'd prefer it if a more strictly on-topic comment was above me.

</comment></comment></comment></comment></comment><comment><USER9> Ok, I've had enough. I'm making a prediction that the entire JavaScript ecosystem will collapse.

This just doesn't make any sense. None of this is nice. It's all ugly and complicated. There's no beauty to these tools. There are no fundamental tools either. Everything is evolving too quickly. You've a choice of 25 frameworks, libraries, tools that change every day and break between versions. The complexity is growing and the ecosystem is getting extremely fragmented.

Instead of just writing your application, you're in despair trying to choose the right tools, panicking about not being able to understand them, and then then you spend weeks learning them. You end up writing application that is glitching and you've no idea how to fix it because you depend on a dozen different tools. Worst part is that you don't even need them. You've been tricked by peer pressure into using them.

When you've a complex, fragmented ecosystem, and developers are in stress because they can't understand and learn tools quickly enough, then the only logical conclusion that it will collapse, and only a few technologies will survive that will get mass adoption, and everything else will be forgotten.

<comment><USER10> > You've a choice of 25 frameworks, libraries, tools that change every day and > break between versions.

And this is what the author has said too, and then presented a list of tools for different purposes to one doesn't fall into analysis-paralysis.

Since past few months, JS community and settling down and tools are getting stable and long lasting. Surely, new ones are being developed everyday, but a standard is being set with React-Redux-Webpack family.

Maybe a new generation of JS tools will come up when Web Assembly becomes mainstream, but until then, I think React is here to stay.

<comment><USER11> It is extremely hard to believe that anything in the JavaScript ecosystem will be a standard or 'here to stay' for any timeframe greater than a year or so.

<comment><USER12> Both React and Angular has existed for more than a year. Angular is a couple of years old and still works although they have new version.

</comment></comment></comment></comment><comment><USER13> I agree with 90% of this. React, Redux, ESLint with airbnb config, npm, webpack, lodash, ramda, fetch, css modules...absolutely.

I disagree with the breezy assertion that types don't matter, and the offhand dismisal of TypeScript. And saying that "TypeScript tries too hard to make JavaScript like C# or Java" reveals, in my view, a fundamental failure to understand what TypeScript does.

I also think the author is a bit too strongly in favour of `mocha`; I don't think `ava` should have been some easily dismissed, and I've recently run across a pretty nice framework called `painless`. And even if you do use `mocha`, I find `expect` to be a better assertion library than `chai`. I think a better answer here might be "use whatever works for you, so long as its not Jest". (The shoutout to `enzyme` was on point though; great library if you need to test React components.)

<comment><USER14> mocha, ava, expect, chai, painless... honestly what the fuck is this. I'm not a javascript developer - is the ecosystem really so fragmented? What a nightmare.

<comment><USER15> JavaScript is hardly the only language to have multiple test runners.

<comment><USER16> chai and expect aren't test runners, just libraries with assert helpers. I personnally stick to jasmine. Chai is what happens when Rubyists try to write some JS like they write some ruby.

</comment></comment></comment></comment><comment><USER17> Why not mithril? [https://lhorie.github.io/mithril/](https://lhorie.github.io/mithril/)

Seems to be way faster, and easier to learn than any of those other framework/libs.

For example: How is Mithril Different from Other React: Source: [https://lhorie.github.io/mithril/comparison.html](https://lhorie.github.io/mithril/comparison.html)

"The most visible difference between React and Mithril is that React's JSX syntax does not run natively in the browser, whereas Mithril's uncompiled templates do. Both can be compiled, but React's compiled code still has function calls for each virtual DOM element; Mithril templates compile into static Javascript data structures.

Another difference is that Mithril, being an MVC framework, rather than a templating engine, provides an auto-redrawing system that is aware of network asynchrony and that can render views efficiently without cluttering application code with redraw calls, and without letting the developer unintentionally bleed out of the MVC pattern.

Note also that, despite having a bigger scope, Mithril has a smaller file size than React."

<comment><USER18> I'm really interested in mithril from a technology stand point. The thing that holds me back from using it is the ecosphere around it. You look at powerhouses like react and angular and you can find a whole gamut of reusable components that you can just plug and play from the community.

For instance: the twitter bootstrap framework we have options for both react ([https://react-bootstrap.github.io/](https://react-bootstrap.github.io/)) and angular ([https://angular-ui.github.io/bootstrap/](https://angular- ui.github.io/bootstrap/)).

But with mithril, the only bootstrap library I have found has not been updated in 2 years ([https://github.com/eddyystop/mithril-components- bootstrap](https://github.com/eddyystop/mithril-components-bootstrap)).

I really wish mithril had a bigger community around it, as when I used it for a few prototypes it was a pleasure to work with and fast as hell.

<comment><USER19> I've been using Mithril a bit, and I like how it's just a library, not a big framework pushing you to use a particular set of components. It's very light and very well documented.

There are these "Mithril" libraries for Bootstrap and Material with 1 contributor and not updated for years, not appearing official at all. In my experience they don't really work.

I'd say it's more in line with Mithril's design to use UI components that are also loosely coupled, like these: [http://topcoat.io/](http://topcoat.io/) [http://purecss.io/](http://purecss.io/)

</comment></comment></comment><comment><USER20> The problem with React is its patent rider. React.js comes with a BSD license, but has a patent rider that gives you a license to React's patents. This sounds like a good thing, right? But this rider has a "strong retaliation clause" which says that if you make any sort of patent claim against Facebook this patent license automatically terminates. Which means Facebook can now sue you for patent infringement for using React. You may think this is no worse than not having a patent rider at all. But that's not the case. If there is no patent rider then there is an implicit grant which cannot be revoked.

If you work for a software company and your company has patents then keep in mind that by using React you are giving Facebook a free license to your entire patent portfolio.

More info on weak vs strong retaliation clauses: [http://www.rosenlaw.com/lj9.htm](http://www.rosenlaw.com/lj9.htm)

<comment><USER21> _if you make any sort of patent claim against Facebook_

My understanding (and I'm asking for correction, if I'm wrong) is that last year FB changed this provision to only cover patents on technologies within React itself, not "any sort of patent claim against Facebook", which WAS the situation before they changed it.

So, the current state is a grant of "you are licensed to use our React patents at no cost as long as you don't try to make a legal claim that any of our React patents are not legally ours."

<comment><USER13> Not exactly. The diff is here: [https://github.com/facebook/react/commit/b8ba8c83f318b84e429...](https://github.com/facebook/react/commit/b8ba8c83f318b84e42933f6928f231dc0918f864)

The old grant terminated if, among other things, you argued that any Facebook patent was invalid or unenforcable. This meant that if Facebook sued you over an unrelated patent, you couldn't defend yourself without the React patent grant terminating.

The new grant specifically exempts any counterclaims; you can't lose your patent grant just because you defend yourself. You _can_ still lose it if you sue Facebook over unrelated patents.

</comment></comment></comment><comment><USER22> At work we've turned an ember-cli ember app into a react redux app in place using immutable.js and ramda for everything. It's been a huge boon.

PS Ramda it eats lo-dash and its imperative API for lunch. It's for power users, everything curried, higher levels of abstractions. Pick it up and learn it, it'll make you a better programmer.

Next stop Clojurescript. Om next is a library where you can get a feel for a Falcor + Relay stack in like 70 lines of code all without the specific tech bloat. David Nolen is a UI profit, just follow him.

<comment><USER23> Lodash v4 has its FP module included with it: require('lodash/fp') for immutable, auto-curried, iteratee-first, data-last method modules.

</comment></comment><comment><USER24> Every post that lists a set of tools is eventually going to be completely wrong.

1) This is the author's favorite setup in 2016. With all due respect, what is the lasting value of this information?

2) There is no "best" architecture. _It depends on what problem one is solving_. The author does not specify that, making their conclusions likely completely wrong in most cases. Yet, the language they use is in absolute terms.

3) 99% of JavaScript simply enhances static HTML pages. Yes, even in 2016. You probably don't even need jQuery, although it's likely to be available already.

4) It curiously evangelizes the "latest and greatest" frameworks, thus incurring in novelty bias -- new frameworks have less apparent problems because many side effects become apparent years later, once the codebase is mature.

<comment><USER25> Redux is the only "new" thing in that list, and I could code it from scratch during a hackathon. It's also essentially a javascript port of what other framework and languages have been doing since before a lot of people reading this were born.

Ironically, a lot of the comments in the article are complaining why some newer thing that just came out didn't make the list. Most of these tools are 2-3+ years old.

</comment></comment><comment><USER26> Ember barely gets mentioned and includes each "piece of modern web applications" OUT OF THE BOX with a great support community. I love not making all of those decisions and doing all the integration BS work. Ember feels like the worst kept secret.

<comment><USER27> Come on, Ember is so 2015 ...

<comment><USER28> Not sure if sarcasm or serious, but this sums up everything that is wrong with the Javascript community succinctly

<comment><USER29> I'd place a small bet on the former, but I wouldn't go all in. I agree with you - those javascript folks are more ADHD than me. And that's saying a lot.

<comment><USER28> Good point

</comment></comment></comment></comment></comment><comment><USER30> A huge amount of this stuff is bloat, to me. It seems like this is a collection of libraries that largely were picked out of the problem that is javascript bloat today.

Use typescript and just write it to do whatever you want it to do. You don't need React, or any of this stuff. Chai is good for testing. But as far as deploying a production application, there should be literally no dependencies. You don't need them.

There is nothing today that typescript or even just raw javascript can't do perfectly fine on its own.

<comment><USER31> I disagree. I think React is a no brainer for any SPA. Try doing a full fledged SPA admin panel in pure javascript. It's madness. But with React you can separate everything else into components and it becomes clean and beautiful.

<comment><USER32> That's just considered good practice. React brings nothing new to separation of concerns. In fact, it works against it.

</comment></comment></comment><comment><USER27> Measuring time intervals in years for everything JS related is to imprecise. "State of the Art in 3/2016" or at least quarterly would make more sense.

<comment><USER33> Sadly, I had the same thought. By the time you + your team get on that latest greatest, it's now been usurped. I really hope that the JS communities can come together for some common needs and have just a couple of "paved road" solutions. I can only imagine how confusing the current state of affairs is for someone who "[just] wants to get started building modern JavaScript apps"

<comment><USER34> I think a good mindset for building modern javascript apps is that they are full featured desktop / mobile apps, just like a windows / mac / ios / android native app. By definition these types of apps are complex, and always have been, but they are highly valuable!

Looking at it from the lens of "web apps are just some html and css with a little jquery" is a mindset that can make building very ambitious web applications seem disproportionately difficult.

</comment></comment></comment><comment><USER35> I'm not a fan of these discussions at all. We're all supposed to have been using X framework at X time period. In the enterprise we can't just keep rewriting all the god damn applications.

For us contractors, we have to answer to clients we had 2 years ago about why their app is in Backbone.

I mean, damn; we have to build software here and we aren't all Facebook. You might get warm and fuzzies from constantly starting over and feeling like you've chosen the right framework, but it's immature.

Oh, we got it right this time! React is a paradigm shift! We've quickly forgotten we were saying this with Angular bindings. Oh your model based stuff is crap, this has TWO WAY BINDING, it's a paradigm shift!

Now, I'm using Angular. I could recite the Backbone source code, we had a few small libraries and we built huge apps and they worked (and they were built with Grunt and it worked fine, but hey, move it all to Gulp! now! Paradigm shift!). In this case I was expecting it. I waited six months and Web Pack came along.

We're going to go ahead and build our app in Angular 1.x with TypeScript and Web Pack and test it with Jasmine.

This article is NOT correct. This hasn't been 'decided', there is no clear winner. You can't simply list the features of something as "amazing" and "where it's at". You are arguing finality here and you main data point is "coolness factor". It's not correct, it's not objective, and it isn't high quality, long term; well thought out software development practice.

<comment><USER36> The good news is that Angular 1.x will work fine. It'll get the job done, there's a huge pool of talent to pull from, and it's proven to work at scale. However there are newer, better technologies now, and in 2 years time, there will be better ones still. It's a tradeoff like any other.

And while certain fads do come and go, there are also larger shifts and it's pretty clear by now that React's declarative-reactive style is the direction the industry as a whole is going.

The aggregate community is always searching for better solutions, it just so happens that this aggregate community is now huge and that means lots of people thinking about the same problems, meaning we make faster progress.

Old things don't stop working, but new things can be made better! What's the harm? Why so angry?

<comment><USER37> I think there are frustrations borne from two main places:

\- Code is fashion; for some (especially on HN) there is inherent value in using technologies that are bleeding-edge and in vogue. Additionally, the _necessity_ to use things that are bleeding-edge and/or in vogue is amplified when you're on HN or similar communities, much in the same way that the quality of your raw denim is amplified when you're on a fashion forum or with a bunch of stylish people.

\- Fashion fades; building something when it's in vogue in 2015 for the sole reason that its in vogue in 2015 feels a lot worse when its in 2016 and suddenly the underlying technologies are not so shiny.

I think it can be easy to muddle 'progress' in the sense of "how do we move web technologies forward?" and 'progress' in the sense of "how do we deliver value to clients and customers?" As someone who is fairly shy of the current fashion (namely the React + Redux stack, which I've had the pleasure of working with the past couple weeks and whoa is it cool!) -- I'm not entirely convinced that the value delivered by using these technologies always outweighs the risk that they'll be obviated in less than a years' time. And so, there _is_ a risk inherent in rapid progress, if rapid progress necessitates (as it seems to) the abandonment of anything that isn't pushing forward.

Choosing your technologies is a value proposition: every choice has positives and negatives. It can be frustrating to realize in retrospect that the positives weren't that positive and that there were negatives you didn't even imagine.

</comment></comment></comment><comment><USER38> We all have our opinions and I would say take this article with a huge grain of salt (as well as my comment). State of the art javascript should still be considered a browser + editor + files. There is no need to overcomplicate things, and unfortunately Webpack and Babel do. It is terrifying to see javascript turn into the new Java - build steps and compile steps and configuration and everything you don't need except for distraction from getting real work done.

Build your app first. Then when you are unhappy, see if these tools make your life easier. But play with them first, don't make upfront commitments.

<comment><USER39> You're downvoted but I for one agree. KISS. If you really NEED all that stuff, fine, but it's quite clear why modern web pages are so bloated and slow on anything but current-gen hardware and fast networks.

<comment><USER40> I doubt this article offers any explanation of the bloat observed in many modern web pages. I suspect most web pages built using stacks like this will actually tend to be fairly economical on the client.

</comment></comment></comment><comment><USER41> This article echoes my experience this year and last, moving from a Backbone app into React + Fluxxor, and eventually into ES6 with Babel + Flow + Webpack.

It's a huge pain to configure and understand all this tooling, but man is it nice once it's all working. It definitely gives me hope for the web as an application platform.

Re: Flow, it's good but nowhere near as developed as TypeScript, but it's getting better. 0.22 of Flow (released just a week ago) brought massive speed improvements that bring it decently on par with any other linter. I found I could finally re-enable it in Sublime Text after this release. It catches all kinds of things linters won't, and the upstart cost is relatively low. On the other hand, TS has the benefit of years of type files available for almost any library; don't underestimate how great that is.

Using React has been great as well. It's what I wish Backbone views had been from the beginning.

We certainly aren't wanting for choice. Between the dozens of Flux implementations, React alternatives like Mithril, interesting languages like ClojureScript (with Om if you want to keep using React) or Elm, multiple typing systems, and even WASM on the horizon - web development is an exciting field. It's also overwhelming, and I say that as someone who keeps his head in it over 12 hours a day.

\---

Re: CSS, the story still feels incomplete. I want a way to write a library that will effortlessly import its own styles, so consumers can simply import the component and go to town. Most solutions are severely limited, slow, or both, mostly because they rely on inline styles. Nothing's wrong with inline styles, until you want to do :hover, :active, pseudo elements or the like.

See the React material-ui project for a very real example of how this can go wrong - note how every component has a dozen or more extension points for styles. I built a project with this recently and it was intensely frustrating that I couldn't simply add some CSS to the app to fix styles across the board - I needed to keep a giant file of extensions and be sure to apply them every time I used a component. And, of course, component authors can't possibly anticipate every possible use, so some of my selectors were ugly "div > div > ul > li:first-child" monstrosities.

CSJS ([https://github.com/rtsao/csjs](https://github.com/rtsao/csjs)) is one of the few solutions I like. I would be very happy to see it, or something like it, go mainstream.

<comment><USER42> Polymer ([https://www.polymer-project.org](https://www.polymer-project.org)) is a solution for the styles problem. You can pack each component with its own styles, complete with all its functionality. This allows for a very clean separation of concerns among components. Better than all other libraries that I have tried. I hope that web components take off, because it is a great way to build apps. Currently they are only supported in Chrome.

Moving data between components in Polymer, can be done with data binding. The bad thing is that it could get messy for complex applications. Is not terribly bad, but it could be better. What Polymer needs is a better way to move data between components. If that problem is solved, Polymer would be an excellent alternative to create any kind of apps.

<comment><USER43> Note that style scoping comes with Shadow DOM, so once browsers support that (it's happening now), you can get scoping with no libraries.

Polymer also adds a CSS custom properties polyfill and a CSS mixins (@apply) polyfill. Custom properties are implemented in FF and Chrome already, @apply is being worked on in Chrome.

Polymer always tries to be forward compatible with actual web standards, one of it's main benefits :) Eventually Polymer will mostly be just templating and convenience helpers on top of native standards.

</comment></comment></comment><comment><USER44> Mainly used angular and node. Someone was telling me about ember.js, I wondered why I would use broccoli over browserify. 6 months later. Was comparing browserify vs webpack. 1 month later.

Go to terminal

ember new app

ember server

start writing code.

</comment><comment><USER45> > Unless you're working on a legacy application or have 3rd party libraries > that depend on it, there's no reason to include it. That means you need to > replace $.ajax.

> I like to keep it simple and just use fetch. It's promise based, it's built > in Firefox and Chrome, and it Just Works (tm). For other browsers, you'll > need to include a polyfill.

I laughed. Is this satire? There's no reason to have X, therefore you need Y _and_ Z to replace X. It just works.

<comment><USER46> Have you ever started a js app thinking you don't need jQuery? It usually goes great until you need to make a request. One look at `XMLHttpRequest` and suddenly including a 92kb (unminified) library starts to sound appealing.

I'd happily include a 9kb (unminified) polyfill and work off the assumption that I can remove it a few years down the road.

<comment><USER47> It's not so bad honestly. Just a little awkward. For my little JavaScript library I wrote a small utility that lets me do Ajax calls that work in node and the browser. It's limited but it's all I need and it's pretty well tested (msngr if you're board).

$.Ajax is awesome and while XMLHttpRequest is awkward it's pretty straight forward.

<comment><USER33> If that's all you're after, I'd suggest something like Zepto win only the Ajax module: [http://zeptojs.com](http://zeptojs.com)

</comment></comment></comment></comment><comment><USER48> > Avoid CoffeeScript. Most of its better features are now in ES6, a standard.

This argument against CoffeeScript isn't very objective. One of CoffeeScript's best features is the minimalistic and expressive syntax.

"CoffeeScript (#6) appears dramatically more expressive than JavaScript (#51), in fact among the best of all languages."[1]

"CoffeeScript is #1 for consistency, with an IQR spread of only 23 LOC/commit compared to even #4 Clojure at 51 LOC/commit. By the time we've gotten to #8 Groovy, we've dropped to an IQR of 68 LOC/commit. In other words, CoffeeScript is incredibly consistent across domains and developers in its expressiveness."[1]

Using the author's train of thought I could state: "Avoid Bluebird[2]. Most of its better features are now in ES6 promises, a standard."

Yes promises are in the ES6 standard, but that's not the best feature of bluebird. There were and are many promise based libraries, but bluebird was built for unmatched performance. One will use it if performance matters.

Even today it's faster than the native implementations of promises [3].

> Tooling (such as CoffeeLint) is very weak.

Maybe because, as it turns out, in CoffeeScript you don't need a lot of tooling. Why would that be a bad thing?

> Electron is the foundation of the great Atom editor and can be used to make > your own applications.

Atom is written in CoffeeScript [4].

[1] [http://redmonk.com/dberkholz/2013/03/25/programming- language...](http://redmonk.com/dberkholz/2013/03/25/programming-languages- ranked-by-expressiveness/)

[2] [https://github.com/petkaantonov/bluebird](https://github.com/petkaantonov/bluebird)

[3] [http://programmers.stackexchange.com/questions/278778/why- ar...](http://programmers.stackexchange.com/questions/278778/why-are-native- es6-promises-slower-and-more-memory-intensive-than-bluebird)

[4] [https://github.com/atom/atom](https://github.com/atom/atom)

<comment><USER49> I'm using LiveScript for private stuff and ES6/JSX in production. LS is a pleasure to write. But the tooling on ES6 is nicer I must admit :/

<comment><USER48> Out of curiosity, what tools are you referring to that are nicer on ES6 and not applicable to LS? Could you give examples?

<comment><USER49> all the auto-complete stuff in atom.

</comment></comment></comment></comment><comment><USER50> I use all those tools daily, but this article feel patronising to me, I would feel inconfortable to say that whatever I use is the state of the art. Also the author is totally ignorant and bigoted about typescript.

</comment><comment><AUTHOR> Can we all agree that State of the Art JavaScript in 2016 is a mess?

<comment><USER47> It's always been a mess and the trend will likely continue :)

Every few months there is a new, up and coming framework everyone is saying that's better than the last popular one. And it's written in a dialect of JavaScript that isn't supported in most places so it has to be transpired first.

Good times /s

Honestly when I'm going into a new project I use a handful of utility type libraries and that's it. You can still develop very quickly this way. The DOM is awkward but very easy to use. I'm not convinced you need a framework.

</comment></comment><comment><USER51> Whenever these kinds of JS commentaries pop up on HN nowadays, I notice two distinct camps of commenters emerge: Those who are obviously steeped in the JS scene and are delighted to argue the finer, more sophisticated points of it, and those who take their best look, step back, and criticize this convoluted house of cards - and of course proceed to be downvoted into the Stone Age as the latest casualty of HN censorship.

My only observation of note I guess is the sheer marvel that all of this is nearly entirely supported by the Open Source community, and the amount of engineering effort being poured into the JS ecosystem at this point in time is nothing short of astounding. I can't wait to see where it goes in the next few years.

<comment><USER25> We had a discussion about this in my last team. It really comes down to the JS community being divided in 2.

You have the first group, of which most of us were part of at least at some point: developing in our language of choice and being "forced" to use JavaScript for some frontend stuff, in the same way we kind of have to use SQL in some form when hitting a database.

That group generally wants to touch JS has little as possible then forget about it. Ideally making it as close to their language of choice as possible (similar to ORMs for database).

Then there's the other side, people who are running away with it and pushing it as far as possible. That also comes with some problems (JS fatigue, millions of frameworks, etc).

But generally, most comments will fall in one of the 2 categories.

<comment><USER52> > _That group generally wants to touch JS has little as possible then forget > about it._

WebAssembly will be the thing which grants that wish. Once there's a compiler for your language of choice that can compile to WebAssembly the need to use JavaScript will be kept to a minimum.

<comment><USER53> Y but you will have to support JS for 10+ years regardless

<comment><USER52> Maybe not. There's a WebAssembly polyfill for browsers which don't yet (or never will) support WebAssembly: [https://github.com/WebAssembly/polyfill- prototype-1](https://github.com/WebAssembly/polyfill-prototype-1)

And the load times are still good: [https://github.com/WebAssembly/design/blob/master/FAQ.md#can...](https://github.com/WebAssembly/design/blob/master/FAQ.md#can- the-polyfill-really-be-efficient)

</comment></comment></comment></comment></comment><comment><USER54> In a development world that is already rife with planned obsolescence, the Javascript world is the shining jewel. Reminds me of trying to construct the killer Yu Gi Oh deck. By the time you get all the cool cards, paying a small fortune for them of course, a new ban list comes out, new decks come out, and you have to start all over again. Is the game improved through all of this? Maybe it is, maybe it isn't, but I would say that this question becomes beside the point for many players...

</comment><comment><USER55> I'm in the process of learning a JS stack at the moment, and I've come to almost an identical conclusion to this article about the packages and tools to use.

One difference though is that I've read Relay and GraphQL will eventually win out over Redux. Thoughts?

<comment><USER56> That Relay/GraphQL will "win" is very uncertain at this point. The solution is very interesting but only time and real world usage of it will tell in the long run. But you might be interested in this thread where the creator of Redux muses on a future convergence of Relay and Redux[1].

[1]: [https://mobile.twitter.com/dan_abramov/status/69755646131300...](https://mobile.twitter.com/dan_abramov/status/697556461313007616)

</comment></comment><comment><USER57> Meteor isn't even being mentioned anymore in most of these posts, but it really does reduce the need for so much tooling. Plus, it can use React as the view layer.

<comment><USER58> Meteor is so February 2016

</comment></comment><comment><USER59> I'm a little bit bummed that the author seems to think there's "No API solution." Nodal [1] was released in early January to a great response, and I'd hope that more people are paying attention. Our most recent announcement was that we're focusing on being API-first [2]. We also have out-of-the-box GraphQL support [3].

[1] [http://nodaljs.com/](http://nodaljs.com/)

[2] [https://medium.com/@keithwhor/realtime-doesn-t-belong- everyw...](https://medium.com/@keithwhor/realtime-doesn-t-belong-everywhere- build-scalable-api-services-in-node-js-with-nodal-10d0adfb66d)

[3] [http://graphql.nodaljs.com/](http://graphql.nodaljs.com/)

<comment><USER25> Don't be bummed :) The point was that there's no "obvious" solution. Something released in January needs a bit more time to become an obvious go-to. Doesn't mean it's not great or that it won't.

<comment><USER60> I think something released as long ago as January at this point is probably obsolete. :)

</comment></comment></comment><comment><USER61> I agree that React, Webpack, et al. are great improvements compared to their predecessors. But do I really want to start an app in 2016 knowing that there may be even better tools in 2017? Most likely I would use these but what ails me is the thought that I might have to learn yet another tool and migrate. Why does the JavaScript ecosystem move so quickly? I get that browser technology is exciting and constantly improving. But why can't we settle on some well designed concepts and keep them well maintained? I hope React is it because I like it but it really depends on Facebook's commitment.

</comment><comment><USER62> Wow, this is nearly our teams exact stack. One addition would be superagent instead of fetch. I really like Fetch, especially for react-native but superagent is just so simple and easy to use

<comment><USER63> Superagent has flaws. It doesn't support promises out of the box unfortunately :(

<comment><USER64> I don't think this is a problem, I expect to wrap my HTTP calls inside of promise factories anyways. Promises solve the issue of callback piramids, there's no issue with a single rogue, well contained callback.

</comment></comment></comment><comment><USER65> >> "You'll be able to package your application and distribute it like any other desktop application, complete with an installer and auto-updates."

Yep, Electron is excellent. However, Electron is built on top of V8 and V8 does not provide a way to protect the JS source. More than the technical problem this becomes legal issue for businesses that want to develop applications/tools rapidly with electron.

refer: [https://github.com/atom/electron/issues/2570](https://github.com/atom/electron/issues/2570)

Cons of other options that I know: 1\. Obfuscation is not ideal to hide the source from competitors.

2\. Writing nodejs modules in C++ is not so easy way. Once could prefer to develop entire app with C++ than the learning curve associated with node modules in C++.

3\. V8 snapshots maybe a way to go with nw.js. But doesn't work great and it is hard to isolate issues while packaging.

4\. EncloseJS looks promising. There is no company behind it and no guarantee it will be supported. (I personally have been following up with issues in packaging an open source app with encloseJS. No luck so far with support.

5\. nexe is interesting. But not easy and no clear way to work with it.

What are your opinions? Any alternatives?

P.S: I'm framing a base with Java (most likely C++ too) to develop an app that runs on client machine but on browsers. Performance and source protection are my goals. Might open source its architecture eventually.

</comment><comment><USER66> Because of all this chaos i heavily lean towards Angular 2 and TypeScript. It's a good common ground for larger apps imo and has good best practices.

<comment><USER56> Angular 2 is as good of a bet as any except for maybe React. Angular has enough name recognition in the enterprise space that it almost certainly won't be going anywhere anytime soon.

That said, Angular 2 has no answer today for React Native, and to my view, React Native style solutions may well be a requirement for any serious front end solution in the coming years. React also has the benefit of a huge corporation with massive scale dogfooding it, so you can be reasonably confident that the core library is high quality.

<comment><USER66> ng2 will work with native script: [http://angularjs.blogspot.de/2015/12/building-mobile-apps- wi...](http://angularjs.blogspot.de/2015/12/building-mobile-apps-with- angular-2-and.html)

<comment><USER56> Thank you, I will check this out! I hadn't considered a NativeScript route.

</comment></comment></comment></comment><comment><USER67> Sigh. Types are very important for the front-end. Have you ever tried to validate the data going to the backend? Well then you're using types except you've implemented your own bug-ridden and gimped version of typechecking that already exists in flow and typescript. So just annotate your code. Both typescript and flow work with mixed code bases where some parts are annotated and some parts are not and there is clear benefit to even a half annotated code base. Typescript even has support for JSX.

Not to mention that any front-end code will invariably have a domain model and interactions that are much better expressed with typescript than vanilla modern javascript. The refactoring and basic validations you get by even a few annotation is just too good to pass up. I no longer write any javascript that doesn't pass through the typescript compiler/typechecker.

</comment><comment><USER68> > The learning curve is very flat

So if the graph's x axis is time and y axis is the amount of stuff you learn, then a flat learning curve means that you gain very little added knowledge as time goes by. And a steep learning curve means that you learn a lot in a small amount of time.

It always confused me why is it backwards.

</comment><comment><USER69> Not even a mention of ClojureScript? :(

<comment><USER25> ClojureScript is pretty fantastic, and Om had a lot of the ideas behind Redux before Redux (a bit like Elm). It's still a bit early to build a team revolving around FP though (it can be done, but you need a big company commitment in term of hiring practices, training people, etc). Consider React/Redux a gateway drug. Sprinkle in some Ramda, maybe even some Folktale...and then you're in a better spot to go. But starting with ClojureScript if you have a team not too familiar with the JS world is really rough.

I do really wish JS had native immutables with structural sharing, though.

<comment><USER56> I don't feel like the barrier to entry in ClojureScript is that deep. I think you will find it is awfully easy to pick up if you fall into one of the following categories:

\- You have experience with Lisp dialects (even better, Clojure specifically).

In this case, you know the language semantics but not the application of in this domain. The core concepts are so simple, and there is so much material out there covering it, that picking this up should be easy.

\- You have experience with modern reactive architectures in any language and an understanding to structure application state atoms.

In this case the concepts you learned will largely prevail and you will be left learning the language semantics. While Clojure has an enormous core library, you can do a lot with only a very rudimentary knowledge of the language.

Also, what you aim for will probably make a difference. Reagent and the hiccup style is incredibly easy to pick up, and re-frame supplies a very nice state manager. Om and Om/Next are probably more difficult to pick up, and at least in the case of Om, probably not worth it now. Om/Next seems to be an attempt at replicating an entire React/Relay or Falcor/GraphQL stack in Clojure/ClojureScript, and at this point it is dubious what size of an application you need to develop to break even on the architecture and complexity costs.

</comment></comment></comment><comment><USER70> I'm making web apps/clients in the browser, servers using node.js and desktop "native" apps using nw.js. All in vanilla JavaScript, and I love it. If you need additional functionality, there's always a module for it (npmjs.com)

The interesting part is maybe that most apps look like this:

      <html><body><canvas id="canvas"></body></html>

And the rest is JavaScript!

It does seem a bit stupid to load the browser just for the canvas element though, so if someone know a better solution, please post!

<comment><USER71> How does it look on retina/hiDPI displays?

<comment><USER70> I've never had the chance to use a hiDPI display. But it will probably be upscaled and look the same as on a normal screen. It would be an easy fix to increase the canvas context scale though.

</comment></comment></comment><comment><USER72> To me the best compromise between using regular javascript and having type safety is to use closure compiler. With closure compiler, you can write a 'header file' which defines the functions of the libraries that you use. Then you can write all you own code with type annotations and even check that you have 100% type coverage (--jscomp_error reportUnknownTypes).

Anywhere in your code where you are using identifiers, there should be a method to check for typos. That holds for css classes and qnames too.

</comment><comment><USER73> Ember.js is already proved, the best framework out there nowadays. Corporate ready, production ready, future proof. I'm really looking forward, that Type Script support will be landing soon in the framework, so it will be a concrete solid environment. The whole addon ecosystem, with Ember Data and Ember CLI is just top-notch.

You can check here with this tutorial, how easy to write a complex application with Ember.js: [http://yoember.com](http://yoember.com)

<comment><USER34> From my experience, the most important aspect of a single page app framework is the component api.

Here's the doc for ember's: [http://emberjs.com/api/classes/Ember.Component.html](http://emberjs.com/api/classes/Ember.Component.html)

Versus react's: [https://facebook.github.io/react/docs/multiple- components.ht...](https://facebook.github.io/react/docs/multiple- components.html)

Versus angular's: [https://docs.angularjs.org/guide/component](https://docs.angularjs.org/guide/component)

If you compare them, you can see that react and angular focus heavily on component oriented architecture, while with ember, not so much.

Edit: wrong link.

<comment><USER73> Ember implemented React and Redux concept a year ago, the component layer is based on Virtual DOM. You can see here all the hooks what you can find in React, maybe with a little bit different function names... a modern Ember app is full of components. ;) [http://emberjs.com/api/classes/Ember.Component.html](http://emberjs.com/api/classes/Ember.Component.html) (Tick the check-boxes, Ember.js is nicely object oriented, so you can get a lot from parent classes.)

</comment></comment></comment><comment><USER74> Do I bet on the wrong horse if I use Angular 2 instead of React+other tools?

I don't get the whole React love? I always learnt not to mix view and business logic? React does this?

</comment><comment><USER75> Can anyone tell me where to start on all of this as a self-taught beginner? I feel like I follow tutorials well and get basic apps up and running via tutorials. I've even built some basic tools in use by a handful of people at my job with Node and Meteor. But the minute I try to dive into React and some of these more professional tools in the ecosystem, I find myself totally lost.

<comment><USER25> The article mentions [https://github.com/petehunt/react- howto](https://github.com/petehunt/react-howto). Its a damn good place to start.

<comment><USER76> I just took a look, really good article.

</comment></comment></comment><comment><USER77> Just wanted to mention VueJS as an option on the front-end for those looking for a simple JS library with components.

<comment><USER56> I was enjoying lurking, reading some of the freak out around what amounts to spending a day or a week learning a new framework. Whether you believe that this JS theatre is good or bad, learning new concepts and solutions is never a waste of time, even if only to internally validate some other method. But if you thought that being a competent software engineer only required a one-time, upfront educational cost you probably got into the wrong field.

But throughout all this I was wondering who would come out and mention Vue.js. While my own current preference is CLJS and reagent/re-frame, I feel like this largely unknown framework should get some representation.

(Disclaimer: I am not claiming this is the best framework out there, but it is very nice and I believe a great alternative for many of the commenters here who are coming from Angular, trying to figure out where to turn next, but not wanting to toss years of experience.)

If you come from Angular and like it's declarative markup but don't care for the outdated architecture, Vue.js[1] is worth looking at. It's beautifully clean and blazingly fast (v-dom under the hood). If you are willing to use a Webpack or Browserify loader you get a very straightforward single file component style[2], similar to a web component, where you can easily mix and match style (scoped or not), script, and markup language of choice. The script side of the component looks remarkably similar to React if the render function was replaced with an external HTML template in the style of Angular.

For the Angular developers out there who "like things the way they are" (mostly), do yourself a favor and check it out.

[1]: [http://vuejs.org/](http://vuejs.org/) [2]: [http://blog.evanyou.me/2015/10/25/vuejs-re- introduction/](http://blog.evanyou.me/2015/10/25/vuejs-re-introduction/)

</comment></comment><comment><USER78> A summary, for convenience, of the state-of-the-art libraries for front end development in Q1 2016:

\- Core: React

\- State container: Redux

\- Language: ES6 with Babel

\- Linting: ESLint

\- Style guide (ES6): Airbnb JavaScript Style Guide() {

\- Dependency management: NPM, CommonJS, and ES6 modules

\- Build tool: Webpack

\- Testing: Mocha and Chai

\- Utilities: Lodash

\- Fetching: Use what-wg or isomorphic fetch rather than jQuery

\- Styling: Sass, PostCSS, Autoprefixer, CSS Modules

</comment><comment><USER79> Why is eslint considered better than jshint+jscs? jscs also supports auto- fixing, which is pretty dope.

<comment><USER80> ESLint is extremely configurable and thus has a vibrant plugin ecosystem so I think that's why it has picked up a lot of hype.

</comment></comment><comment><USER81> I would like to add that I've had an excellent experience with the Radium library for styles. Sass was a little better than CSS because you sort of get variables but being able to define styles in JS has fixed pretty much all of the remaining problems.

</comment><comment><USER82> No mention of SystemJS/JSPM?

<comment><USER83> I found a mention in the comment section (I believe by the author of the article), which said it didn't work all that well for them.

</comment></comment><comment><USER84> I find lots of modules that won't build with Webpack and a very solid chunk of my available development time is spent trying to diagnose and fix problems caused by modules that won't build under Webpack. I recommend against it.

<comment><USER13> I've _never_ run across this, or indeed, heard of anyone have experienced this before. More details? I'm honestly curious.

<comment><USER25> It happens all the time because most UMD implementations are broken and make incorrect assumptions, so you often have to follow the "Fix broken modules" steps on [https://webpack.github.io/docs/shimming- modules.html](https://webpack.github.io/docs/shimming-modules.html)

And if your package depends on a broken module, you're essentially SoL unless you make assumptions about the path NPM will install stuff and configure webpack to fix -that- one.

That's more a problem with the state of broken UMD modules than Webpack itself though, but I've considered configuring webpack to ignore all AMD syntax quite a few times...

<comment><USER84> Yeah the line of thinking seems to be that everything else is broken, not webpack. And the module maintainers say "well it works with everything else except Webpack so webpack is broken, they should fix it." Seriously crap situation.

<comment><USER16> But people should code for Webpack or JSPM or require JS or whatever. A good solution should just work no matter how the lib was coded, if it doesn't then the solution isn't worth the investment.

</comment></comment></comment></comment></comment><comment><USER85> JavaScript for medium-size SPAs, that is. For just enhanced content, this still seems overkill and for true desktop replacement apps, there's a lot of missing gaps (unless you ditch everything and settle with ExtJS).

</comment><comment><USER86> I feel dumb for not using React. Damn, I even feel I'm living in sin.

</comment><comment><USER87> What's the current thinking on React? Is it primarily indicated for SPAs? Or should one us it throughout a web app (even for pages that don't qualify as their own SPA)?

</comment><comment><USER88> Is there a boilerplate repo somewhere with all these frameworks and tools combined? Would love to dig more into this but configuring them all together would take me days.

<comment> house9-2 My co-workers put together [https://github.com/CodingZeal/react- boilerplate](https://github.com/CodingZeal/react-boilerplate) but the documentation is a bit lacking at the moment, you really need to know a lot about redux to use it.

Recommend: [https://egghead.io/series/getting-started-with- redux](https://egghead.io/series/getting-started-with-redux)

</comment></comment><comment><USER49> I would use something linke cyclejs with LiveScript, if I start something new.

the whole function composition has a clean feeling and LS removes a lot of cruft

</comment><comment><USER89> Regarding CSS I recommend tachyons [0] over css-modules.

[0] [http://tachyons.io/](http://tachyons.io/)

</comment><comment><USER90> I tried to like typescript however so far failed, don't feel like it though everyone else seems are applauding it.

</comment><comment><USER91> It's not so bad. You just pick the most popular thing or use the recommendations in articles like this one.

</comment><comment><USER92> Here's a short story.

I used to do a little bit of JavaScript. Initially it was easy. Functions! Easy enough. Vars! Cool. I get all of that. I wrote some code, worked. Wrote some more and it started not working as expected. I was curious why. I started reading into it and discovered interesting concepts like "hoisting".

Then a friend of mine told me about Clojure/ClojureScript. I never understood hoisting.

</comment><comment><USER93> I wrote an app generator (actively maintained) that actually follows many of these recommendations if anyone is interested: [https://www.npmjs.com/package/generator- enigma](https://www.npmjs.com/package/generator-enigma)

</comment><comment><USER94> No mention of WebSockets...

<comment><USER6> What percentage of projects need them? Surely it's not a core requirement outside of actual real-time apps (and not 'lets play with realtime on my shiny blog').

<comment><USER34> I think any app requiring multiple user seeing the same screens could benefit from them. Compare an open websocket versus polling every 30 seconds for the use case of changes made by other users of your system. Instant notifications and changes of your ui in real time versus a delay that could lead to users trying to perform operations on outdated state.

</comment></comment></comment><comment><USER95> I have found using Elm a real joy, albeit for hobby projects. I do hope pure functional languages become state of the art by 2026.

<comment><USER56> Elm has a lot of beauty to it. I would definitely promote anyone interested in learning FRP in web development to look here first. They really nailed the essence of the architecture, and getting some experience with ML-family languages is bonus, as they are likely more approachable than Lisp-family languages for many. I'm really hoping Evan and the community can make this a more viable solution in the coming years.

That said, Elm can be difficult to use today. The foreign function interface is not all that great of an experience. There is a lot of friction in just defining, serializing and deserializing JSON objects. You wind up writing a lot of code you wish you didn't have too. Their great time traveling, hot reloading debugger doesn't actually hot reload anymore. And there is no real back end language synergy to speak of at the moment. Many are looking toward Elixir and Phoenix for support instead of more language-similar Haskell options like Yesod and Snap.

The competing PureScript, GHCJS, Websharper and FunScript alternatives also complicate the landscape that Elm plays in greatly.

<comment><USER95> I agree I am learning Elm mainly to learn FRP and do some 'haskell with my hands tied behind my back' because I believe you can get a lot done without resorting to the advanced language features of Haskell.

So for me it's a kata for learning how to be a better functional programmer. Once I feel I 'get' the FRP model used I may just go and do the same stuff in another language, see how it plays out in Haskell or Purescript.

I feel FP will remain a hobby though and the best I can hope for is to convince .NET colleagues to make immutable classes, use code contracts to avoid null problems, and generally try to minimize state and maybe use Rx. Even F# would be too much of a push for most .NET shops. I have a mortgage and fixing bugs caused by ridiculous state and null references in .NET code pays it and then some :-)

<comment><USER56> If I may make a recommendation: check out ClojureScript with reagent and re- frame when you feel you've achieved what you set out to in Elm. While Elm nailed the essence of FRP, ClojureScript really nails the experience I was looking for in ways Elm can not.

While it doesn't have the gradual typing and _fantastic_ compiler messages, it is also functional and immutable. But to my view it has all around better tooling, very simple FFI (either reference JS already on the page transparently or pull in JS formally via extern definition files similar to TypeScript typings), optional typing via core.typed, sourcemaps with a native debugger, and a node-like full stack synergy through Clojure but with all the power of the JVM.

You definitely lose some confidence at run time due to the dynamic typing, but on the whole I think the gains far exceed that. At least for me it's a package that is very hard to beat.

</comment></comment></comment></comment><comment><USER96> Relay beats Redux any day

[https://gist.github.com/idibidiart/49a095b6bc528638f34f](https://gist.github.com/idibidiart/49a095b6bc528638f34f)

<comment><USER25> Until there's no 1:1 relationship between the client and the server APIs, or you don't control all parts of the server... Relay is amazing, but it makes assumptions about the server (its kind of the point).

</comment></comment><comment><USER97> Who are all these people that need all these tools to write stuff in js? Go back to coder school!

Is this what it means to look for a job in the startup scene in 2016? It seems overwhelmingly likely that you'll be dropped into some unholy, frankenstein- esque work of "art"

While JS has a few pain points that should be addressed by tooling, I'd draw the line at React and jQuery and a bespoke, well-kept utility library

<comment><USER25> Redux is 100~ lines of code without all the sanity check. Thunk is -4-.

You kind of need to settle on some kind of design pattern on how your data exists, flows, etc. You'll want to be reasonably DRY doing it. Whatever you code will probably be around the same scope. May as well use something that's already documented and done. Same some time.

Then if you want to roll up your own bundler, minifier, manage your script tags on your own, spend more time testing, etc...well, that's up to you :)

<comment><USER34> Couldn't agree more. Having a central data model is so important to scaling an application to many engineers versus the alternative of state being all over the place or even worse stored in the dom, and also opens up some really simple ways to implement quite advanced functionality.</comment></comment></comment>


Bitcoin plunges again. Now the only currency worse than Bitcoin is Venezuela's - <AUTHOR> https://www.latimes.com/business/la-fi-bitcoin-venezuela-20181126-story.html <comment><USER3> > The reason bitcoin miners are willing to do the very real work of processing > transactions is that they think the bitcoin they're getting paid with will > keep rising in value. And what would make them do that? Well, the finite > supply certainly helps, but at some point there has to be more demand for > them too. Which means that people have to actually start using them.

I can't help but feel some similarities to housing bubbles here.

<comment><USER4> And demand will only return when the price stabilizes. And because the price isn't stabilizing, demand isn't coming back.

<comment> Spartan-S63 Not to mention that Bitcoin has a very low value proposition outside of being a store of value. I can see a crypto economy where Bitcoin backs the value of other cryptocurrencies, but it's not a good first-party currency. It's a mere store of values nd people don't really agree that it's useful to exchange for services. They just see it as useful to hold value.

Something like Ethereum, with a real value-proposition, is a more worthwhile cryptocurrency.

Basically, I see crypto evolving into pseudo-fiat currencies with some large financial institution (that isn't a nation-state) ensuring it's a valuable commodity. I'm just not convinced we can (or should) escape a fiat-like economic system.

<comment><USER4> I would argue it's not even a store of value anymore with the price tumbling.

When you buy bitcoin or ethereum, you get what? A number. I can sell you a number. Better yet, I can sell you a cryptographically signed number if you want. But that itself is just a number.

At some point, even something like gold has a certain amount of scarcity. But with crypto, there's no scarcity, even if you can artificially limit the number of coins. One can always just create a new bitcoin alternative...

The point is, there is nothing, absolutely nothing, that underpins the price of a BTC to anything in the real world.

<comment><USER5> Yes, but how many of those numbers can you sell at cost? (There is crypto scarcity, who values the random newcoin at the same as some "established coin" Bitcoin or close, older friend coin? I can see that BCH, LTC, BAB, BSV, etc have all not come close to the price of the original BTC. So, "store of value" is obviously wrong, but...)

<comment><USER4> That's a marketing problem. :)

"Each one will be a unique and priceless number using the largest of prime numbers. Each number comes with a genuine certificate of authenticity hand signed with the author's private key..."

<comment><USER5> Only the best numbers... I hear you, one must back their best issued numbers with actual software to ensure their value ;) BSV has handcash, honestly that seemed like a great wallet until I realized it wasn't supported by any of my held coins!

<comment><USER4> My point is that one way to look at bitcoin is that it's nothing more than a marketing scheme. And the "scarcity" in bitcoin is just artificial at best. Yes BTC has scarcity, but cryptocurrency itself has no scarcity, proven by the fact that there are over 1,000 alt coins. And all of those coins are just number generators.

Here's another way to illustrate the issue:

I have two numbers.

1\. The first takes your user id "yebyen" and appends a number to it so that the SHA-256 hash is exactly 0x0. It will take 20 years of processing power on the NSA computers, so it should be worth something to you.

2\. The second number is an encrypted location somewhere in the US where I've buried $1000. It will cost you $1010 to acquire it from me. I'll decrypt it for free but it will be worth exactly $0 afterwards. But until then it's worth $1000 and you can give the number to whoever you want to.

Which number has a bigger intrinsic value?

<comment><USER5> Ok, now do traditional fiat money...

This is a good metaphor, but it's not perfect. You haven't explained how or why you'll be burying $1000 exactly 21 million times, every 10 minutes until 2140. Or why it becomes worthless immediately upon decryption... nobody can unbury the cash value of an individual Bitcoin, rendering it worthless, but they can be transferred instantly from party to party, which partially funds the ongoing operations of the network.

Even Satoshi himself cannot end Bitcoin at this point.

Even if he still lives, and has the keys to the large stash of Bitcoin he mined in the beginning, it could be a major market-altering event if he dumped them all at once, but it would likely not be the end of Bitcoin.

Sure, it's great marketing, with an extremely long con...

<comment><USER4> > This is a good metaphor, but it's not perfect. You haven't explained how or > why you'll be burying $1000 exactly 21 million times, every 10 minutes until > 2140.

That's an engineering problem. ;)

And it's also beside the point. One has intrinsic value, one doesn't.

> Or why it becomes worthless immediately upon decryption...

The reason the number is worth something is because there's real money tied to it. Once the guarantee of value disappears, the value of the number also does.

<comment><USER5> > The reason the number is worth something is because there's real money tied > to it.

That's the reason why Tether and stablecoins like it ostensibly have value. Bitcoin and friends have value because they are fungible and because people assign a value to it. (Much like fiat money.)

There was never any guaranteed value, but many people saw Bitcoin transacting at $0.05 and put it through the paces, understood what they were observing, and saw that it was massively undervalued as a new technology. Since then it's been proven to work on a repeatable basis, with some caveats like the issues that come with increasing popularity scaling up the volume and value per coin, like $50 transaction fees, but that's another engineering problem.

If you told me for some reason that you thought Bitcoin and every cryptocurrency will simultaneously become worth less than that $0.05, overnight, I would assume that you are either a kook, or again, perhaps, that you've discovered another engineering problem... demands further explanation.

We're not talking about Tether though, we're talking about fungible instruments. You wouldn't say that a stock is valueless because its value fluctuates.

<comment><USER4> > Bitcoin and friends have value because they are fungible and because people > assign a value to it. (Much like fiat money.)

The dollar is the official currency of the US, and all transactions the government makes is required to be in the US dollar.

Bitcoin is an optional currency, made fashionable by the likes of Aston Kutchner, and appears to be more akin to a polyester leisure suit of the 1970's than the US Dollar.

Both Bitcoin and a polyester leisure suit at one point had value, and they both got their value based upon fashion and celebrity.

> We're not talking about Tether though, we're talking about fungible > instruments.

I can make 1 fashionable number worth $1M. Or, I can also make 1 million fashionable numbers worth $1 each. It doesn't matter that the price is fixed, if I have infinite supply.

From wikipedia:

[https://en.wikipedia.org/wiki/Tether_(cryptocurrency)](https://en.wikipedia.org/wiki/Tether_\(cryptocurrency\))

Tether claims that it intends to hold all United States dollars in reserve so that it can meet customer withdrawals upon demand, though it was unable to meet all withdrawal requests in 2017.[33] Tether purports to make reserve account holdings transparent via external audit; however, no such audits exist.[8] In January 2018 Tether announced that they no longer had a relationship with their auditor.[34]

<comment><USER5> You say Polyester leisure suit, I say auditable distributed ledger, let's call the whole thing off...

I really am not an advocate of Tether, or Bitcoin anymore at this point to be honest (it's proven to have on-chain scaling issues, and I still have doubts about lightning network)

I am not a "maximalist" for any one coin, I'm just saying you have to be an absolute luddite to not see the value of the innovation. I'm not one of those who says "all money will be on the blockchain by X date"

But if you honestly think that the technological advancement of cryptographically secured distributed mobile currency is on the level or same plane of value as a 1970's leisure suit, sponsored by Aston Kutcher, then I'm not sure there's anything I can do to help you...

Bitcoin can fail, Bitcoin can go to $0, but Bitcoin was only the first. The ones that follow may not make anyone rich (directly, in the sense of "to the moon"), but I think it's no exaggeration to say they have changed and will continue to change the way we do money forever.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> Am I wrong in believing that if not for Silk Road, BTC would have never gotten above $10 at Most?

</comment><comment><USER5> Real talk, you have to plan your bitcoin hodling around tax season, with the worst possible outcomes always in mind. Wait until next March, when US taxes are due, or until next May after the timely returns have been paid off already...

"The market can remain irrational for longer than you will remain solvent." I certainly am not one who has made out, inasmuch, like a bandit as many Bitcoin investors may have, but I've been following Bitcoin for a long time (as long as it's been around) and the best, most outlasting advice, true in most markets and not unique or special at all in any way is still "don't put all your eggs in one basket."

If taxes come to be accepted in Bitcoin across the nation, this might turn out to be a game-changer. Or it might mean nothing. I don't know what the state taxes are like in Ohio[1], but this is an interesting development to be sure. Regardless, you should continue to plan around the uncertainty that comes on either side of "tax season." Bitcoin or not.

[1]: [https://techcrunch.com/2018/11/25/ohio-becomes-the-first- sta...](https://techcrunch.com/2018/11/25/ohio-becomes-the-first-state-to- accept-bitcoin-for-tax-payments/)

<comment><USER7> > Wait until next March, when US taxes are due

April 15 is usually not in March.

<comment><USER5> I was basically assuming you're ahead of the game, since your paperwork must be in at March to be on-time, unless you file for yourself or if your accountant really likes you, I guess... you're right, the deadline is in April, and I assume similarly, charitably, that taxes paid in May as I said are mostly on-time, while that's not strictly true.

YMMV IANAL this is not legal advice, if your tax budget is not already ready to be paid off in March, then I wish good luck to you.

</comment></comment></comment><comment><USER8> BCH-ABC vs BCH-SV was a online flame war that only really involved the 4th largest coin (BCH). But why would it be the cause of this latest downward slide?

There's a theory that the BCH-ABC vs BCH-SV war brought to light: that "trustless" doesn't really mean trustless. It means "trustless, as long as you trust the coin". Innately, the BCH-ABC vs BCH-SV flamewar destroyed the notion of trustless and decentralized.

Anyway, I don't really know why BTC has done so poorly here. And the correlation to the BCH-ABC vs BCH-SV war may have just been coincidence. But its worth thinking about and discussing... maybe we can learn something from the past few weeks.

\</comment><comment>--

Alternatively: "Store of Value" was a self-defeating prophesy. BTC was a "good" store of value, until it lost 50%+ in just a week or two. So as BTC fell, it just fell harder and harder, as the "store of value" argument was defeated.

<comment><AUTHOR> The pretty obvious explanation as to why it is doing poorly is that it was a bubble. People bought it because it was going up, which caused it to go up further. Now that it's going down, nobody wants to buy it and a lot of people want to sell it.

As far as I can see, there's no particular reason to expect the slide to end here. Stocks have a valuation floor based on income and assets. Commodities have floors based on the people who use those commodities to create economic value. Most currencies have a floor for many reasons, but partly because a central bank will stand behind it and defend its price. Bitcoin has none of those.

<comment><USER4> > As far as I can see, there's no particular reason to expect the slide to end > here.

The real bottom is underpinned by the "True Blue Bitcoin Believers", who will most likely die than sell their bitcoin shares.

In a few years we'll realize the true value of Bitcoin wasn't the blockchain, but it's existence as a curiosity of sorts, where people were buying and selling purely imaginary things -- numbers -- which had no real value in the real world.

<comment><AUTHOR> Yes indeed. Although I'm not sure the TBBBs will provide much of a floor. Holding doesn't prop up the price; they have to keep buying.

I heard somebody refer to Bitcoins as "math beanie babies", which certainly fits your model.

</comment></comment></comment></comment><comment><USER9> Who could have seen this coming? Heh

</comment><comment><USER10> This is when you buy.

<comment><AUTHOR> By that theory, you should be putting your money in the Venezuelan Bolivar. If a big fall means a big buying opportunity, then the Bolivar's the clear winner, as it has fallen farther.

</comment></comment><comment><USER11> That's really cherry picking dates. Use 12 months instead of Dec 31st and it's only down 50%, not 80%. Use 18 months and it's actually in the green.

Bitcoin is volatile. No one disputes that.

<comment><AUTHOR> Anybody who ever called it a store of value was disputing that.

<comment><USER11> If you zoom out the graph it has been a pretty good store of value. It just has many boom-bust cycles overlaid on top.

Would you say equities or housing are a poor store of value, comparing early 2007 to late 2008?

<comment><USER3> Equities and housing have some floor from the value of scrap materials - <USER2> value floor for a failed idea is 0.

<comment><USER11> The value floor of a trust minimized machine arbitration system is not zero. It is the aggregate cost of displaced legal and financial services, which can be substantial.

<comment><USER4> Yes, yes it is 0.

Why I don't have to use your trust minimized machine arbitration system, when I can build my own, just like the 1,000 or so other alt-coins.

<comment><USER11> Which would also be included in that valuation, the total value of which would be equal to or greater than the alternative costs.

<comment><AUTHOR> Not at all. At least not in any realizable way.

Even if a "trust minimized machine arbitration system" (which Bitcoin isn't) had much practical use and so displaced existing non-automated services, your notion of value still doesn't make sense.

As an consider email. People used to spend a lot of money preparing and shipping/mailing physical documents. Much of that has been replaced by email. But what's the price of sending an email? Zero, or as close to it as makes no difference

Is email valuable? Surely. Does that translate into a high price? Definitely not, because supply is approximately infinite.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> The only currency worse than Bitcoin is Venezuela's _over the last 12 months_

Every national currency is far, far worse than Bitcoin _over the last 24 months, 36 months, 48 months, 60 months, 72 months, and so on back to its inception_</comment>


Quiet Epidemic of Suicide Claims France's Farmers - <AUTHOR> https://www.nytimes.com/2017/08/20/world/europe/france-farm-suicide.html?_r=0 <comment><USER2> it is a sad story. It recalls me the discussion about Portugal and Angola. I was born in this part of France (Morbihan) 60 years ago. Young people of my generation, flighted away from the work in farms. Their parents were just forced to retire early, by state decision. The folks that stayed at home became exploited by the "coopératives", a nice word for a hugly reality. "Coopératives" took all the easy gros profit, while letting to farmers the hard work, the business and health risks and the cost of investments. Banks like "Le crédit Agricole" were really happy to lend money to farmers. As said in the article, farmers debts are huge but they earn much less money than the minimum revenue. However nowadays a subsidiary of "Crédit Agricole" called "Amundi" is enough rich to buy France (the whole France) if it wants!</comment>


Flexport (YC W14) had $225M revenue in 2017 - <AUTHOR> https://twitter.com/jasonlk/status/1029751645410754560 <comment><AUTHOR> I know it's HN policy to submit the original source. But the accounting remark of @jasonlk is a worthwile addition.</comment>


Ask HN: What are your hacks for apartment/housing searches? - <AUTHOR> There seem to be a few startups out there focusing on apartments and rentals but all of the listings generally just look the same. I was wondering if there we any good hacks HN can recommend.<p>I'm specifically looking around Oakland / San Francisco and need to commute to SOMA, but any general hacks or sites would be awesome. <comment><USER2> Whenever I'm apartment hunting on Craigslist, I use a thowaway email account for SPAM\scam\phish resiliency. I use BCC' addressing to respond to 50+ ads simultaneously. Each sees themselves as the sole recipient and all replies are managed in one thread.</comment>