Hacker News new | past | comments | ask | show | jobs | submit login

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.)

The author seems a bit conflicted on whether he likes or dislikes types.

First, to say that "Types are not nearly as critical to front end development as some will have you believe" misses the point of types. Every programming language has types, even dynamically typed languages. As a programmer, embracing that types underly the code's meaning affords much more power to write clean, correct, and elegant code. This argument stands regardless of the type of programming; types underly code.

On the other hand, there's his remark, "TypeScript tries too hard to make JavaScript like C# or Java." (You claim that this is an unfair complaint against TypeScript. Would you care to elaborate what you think TypeScript's purpose is?) Personally, I feel similarly when working in TypeScript. Sure, the compiler can catch a few things, and it's certainly a step above only runtime type checks, but the type system itself is fundamentally flawed.

The type systems of Java and TypeScript are actually quite similar, so I'm going to refer to them both here. Neither language has a really good idea of what a sum or union type looks like. Consider doing math, but you can only multiply. Sure, it's possible to hack around some things so that you get the same results, you're doing a huge song-and-dance just to say that what you really want is this plus that.

Type systems like those present in Java or TypeScript (or, as it turns out, most mainstream languages) that lack unions end up leaving this weird aftertaste.

So my takeaway here is that we can do better. Certainly writing Java or TypeScript eliminates classes of bugs that Python or JavaScript are susceptible to, but let's keep pushing. We owe it to ourselves to strive for much better more expressivity in our type systems.

I'll use TypeScript over JavaScript for now, but I'm always keeping an eye out for technologies that raise the bar.

Although the article covers a lot of things and provides some arguments (credit where it's due), the fashion in which the choices are made suffers from a kind of tunnel-vision favoritism. Claims like, "Everyone should use React. Period. Now!" just make me question the merits of its proponents. The JavaScript community is really infamous for this...

React is a paradigm shift in UI development. If you've never tried it or a library inspired by it, that's why you're questioning the proponents. We're trying to spread the gospel that some folks found a better way to do things. Yes, I believe it is a mistake for any UI developer to delay learning React. It's fine to choose other tools later.

I come to HN regularly for advise. Should I be taking yours? I'm a web dev by proffession. React is a paradigm shift? Kind of like the paradigm shift 20 years ago where we said "separate your markup from your style, you'll be better off, promise"? Using css felt right, right from the start. I should really learn React? Mixing js and html in a react flavor does not give the the same sense of being on the right track.

You should learn React for one simple reason: It's quite definitely going to be huge. Well, that's what I was saying a year ago - it's fair to say now that it is already huge and it's likely to stick around for a long time (at least in JS years).

If you're involved in the JS scene, learning React will give you a big advantage. At which point you can decide whether you like it or not.

As for mixing JS and HTML, I went to a talk at last year's React Europe that beautifully explained why this isn't a concern. I had the same reservations at first, but I was convinced then. Suffice to say, give it a shot and see how you feel about it after (besides, jsx is optional).

Start here: http://jamesknelson.com/learn-raw-react-no-jsx-flux-es6-webp...

> Mixing js and html in a react flavor does not give the the same sense of being on the right track.

But you're not mixing js and html. JSX is not html, it's a DSL to express a tree-like structure. In that sense, it's like mixing js and...dom creation logic.

The reasons I'm aware of to avoid mixing html and js fall into roughly two categories - separation of concerns(don't mix business rules, state management, control flow etc with presentation) and concerns of encoding(building strings of html makes for poor development, debugging, brittle code, and so on).

Since React is just a view layer, it does not impose an entangling of concerns. You can do everything within React components, or separate things on your own or via some other framework.

Meanwhile, the gains from manipulating a DOM or a Virtual DOM are immediately obvious. Even the most popular libraries like jQuery advocate using a more structured approach than simply concatenating strings(e.g. jQuery's whole DOM creation and manipulation lib - although it does make tradeoffs and still allows plenty of html through). The (Virtual) DOM tree naturally allows for composition, compared to the complexities of composing strings of html together.

The paradigm shift from React isn't so much React itself, but the ecosystem it (subtly, or not so subtly) pushes alongside with it. Immutable state and pure rendering functions force you to think through the states and edge cases of your application that would otherwise remain as subtle bugs. Components with a clean life cycle(as opposed to angular 1 directives) allow for easy composition. The virtual dom allows you to divorce your framework from html and the browser, and transplant it to other devices.

By the way, the separation of markup and style was a fight for a semantic web. Web apps, which are React's primary use-case, generally sidestep that concern. The theoretical benefits of separating markup and style are still the same today, but the expectations placed on a web site have increased tremendously, and you must juggle those benefits with others.

> separate your markup from your style, you'll be better off, promise

I think the benefits of this were undeniable but not quite for the reasons everyone thought. At that point html was such a mess that imposing ANY structure on it would have been an improvement. CSS saved us from nested image-table-slicing hell.

Separating markup from style is one way to structure a complex document but it's not the only way. However it's better than 'no way'. But don't cargo-cult it.

One good (very good) thing about React is that you can learn it very quickly - at least all the basics. This is also because it only covers the "view" part of a framework.

In the past I tried many times to use some spare time to learn Angular, but it always felt too overengineered to me (also because it does much more than React) and I always stopped at the beginning. With React, just a few hours were enough to appreciate the concepts and get started.

Then of course you can add Redux and that will take more time, but you can almost just as well use React components with any state manager you like.

You should really watch pete hunts original talk: https://www.youtube.com/watch?v=DgVS-zXgMTk

dude, what are you talking about. I've used Backbone, Angular, and React extensively, and React is a significantly better paradigm for building stateful UI's than any of those other frameworks. It's not just a matter of stylistic preference, it's better in an objective way the same way git is better for source control than FTPing files to a server.

When things align, and the abstraction suddenly makes everything simpler, you start to see the wisdom of it. It's less about "proponents," more about people who understand it and how it affects the reality of frontend engineering.

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.

fragmented, yes, but also amazingly thriving.

There is no one standard choice for anything (except possibly React and Redux as the author says). You get to choose your own stack, how you like it.

Yes, it's more effort to get something you like. But you end up with something you like more.

It's not so bad. You just pick the most popular thing or use the recommendations in articles like this one. The ecosystem is harder to dive into than any other language I've used, but you only dive in fresh the first time (or after you've done something else for two years).

JavaScript is hardly the only language to have multiple test runners.

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.

I was kinda hoping it was satire

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact