State of the Art JavaScript in 2016

https://medium.com/javascript-and-opinions/state-of-the-art-javascript-in-2016-ab67fc68eb0b#.37u0xx9xi

by achairapart • 10 years ago

550 297 10 years ago

hoodoof5• 10 years ago

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.

bryanrasmussen• 10 years ago

can you give some examples, this article made me consider if I should rewrite my pretty developed gulp setup as webpack

hoodoof5• 10 years ago

Before you do that, just try to build all the modules you use with webpack into a simple barebones app and see if your app works.

williamstein• 10 years ago

In contrast, I have had extremely good experience using Webpack, and my app uses dozens and dozens of modules.

Lazare6• 10 years ago

I've never run across this, or indeed, heard of anyone have experienced this before. More details? I'm honestly curious.

hoodoof5• 10 years ago

One of many examples

http://andrewhfarmer.com/aws-sdk-with-webpack/

Search google for webpack incompatible

shados18• 10 years ago

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

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

cnp• 10 years ago

If you mean old jQuery plugins or libraries that aren't CommonJS compatable, Webpack even has your back on that via its various plugins.

I was able to take an extremely large node-incompatible app and "webpackify" it through the tooling in a way that would have been impossible any other way.

Highly disagree.

hoodoof5• 10 years ago

I'm trying to program an application, not Webpack. If there are plugins that solve some problems then why aren't they part of the default config of webpack?

I'm not programming for the fun of programming build tools, I just want the damn thing to work. Zero interest in working out how to make webpack work. This is the problem with javascript build tools - they think I care enbough to want to work out how to configure them. I just want the module that I need to function.

choward• 10 years ago

No mention of SystemJS/JSPM?

finishingmove3• 10 years ago

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.

fleshweasel3• 10 years ago

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.

finishingmove3• 10 years ago

Thanks for posting your thoughts. I was leaning towards TypeScript myself (as opposed to ES6) for an Angular project that will be migrated to version 2.0. Angular 2 was actually written in TypeScript if I am not mistaken, and it's one of the three say, "supported" ways of writing A2 apps (along with ES5 and Dart).

wozer• 10 years ago

Agree.

Typescript doesn't have real algebraic data types becauses at the end of the day, Typescript is just a statically-typed version of Javascript. And Javascript doesn't have adts.

For me, the biggest advantage of static typing is that code is much more self-documenting. Also, refactoring becomes much easier.

spicyj3• 10 years ago

For comparison, Flow supports tagged unions like this:

http://flowtype.org/blog/2015/07/03/Disjoint-Unions.html

Too• 10 years ago

Refactoring type safe code vs non type safe code is like night and day. We had a code base in js where even minor refactoring meant frenetic greping and manually replacing things a whole day, fixing problems for a week and occasionally getting a remaining bug on the production site a month after that. We rewrote the whole thing to typescript and after that you could do major refactoring in just minutes and be quite sure that nothing else would break. Also during the rewrite, the compiler always pointed out at least one potential bug in each file, this was quite funny to see because we already considered our old js-code to have quite high quality.

The whole code browsing experience is just different, you can actually read partial sections of the code base and understand them, use code completion, "go to definition" and "find all usages" and it works reliably. Not using types is in my book professional misconduct.

His comparison with C#/Java is also very weird and shows he hasn't given it a proper try. The ducktyping nature of interfaces makes the code much less rigid than in java but still maintains most of the safety you need.

hockeybias• 10 years ago

Strongly agree. Surprised the author felt this way...

lomnakkus7• 10 years ago

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.

spicyj3• 10 years ago

Flow has pretty good support for tagged unions like this which act like ADTs:

http://flowtype.org/blog/2015/07/03/Disjoint-Unions.html

fleshweasel3• 10 years ago

Thanks for elaborating on the distinction. User defined type guards can get you some of the way there to distinguishing "int | int", but you don't get it for free-- the reality of being a superset of JavaScript. https://gist.github.com/RikkiGibson/74fa3dbfdb1b2d7ab86d

jesseschalken• 10 years ago

ADTs can be very easily replaced with visitors.

  type Maybe<T> = <V>(v:{just(x:T):V, nothing():V}) => V
  
  let just = <T>(x:T):Maybe<T> => <V>(v:{just(x:T):V}) => v.just(x)
  let nothing = <T>():Maybe<T> => <V>(v:{nothing():V}) => v.nothing()
  
  let values:Maybe<number>[] = [just(6), nothing()]
  
  values.forEach(maybe => {
    alert(maybe({
      just: x => 'got: ' + x,
      nothing: () => 'nothing'
    }))
  })

CuriousSkeptic2• 10 years ago

The article isn't clear on this, but eslint and Babel works together to provide just enough typing to get you by, even checking symbol references across modules.

I was planning in giving TypeScript a go after having some problems a type system should be able to fix, but after having used just eslint for a while I don't really feel the need any more. Maybe something to reduce the syntax tax of Reacts propTypes would be nice, but then I'm set.

After all, ES is a heavily late bound, dynamically dispatched kind of thing. Which means a truly useful static type system supporting things like statically dispatched type classes and such, would force a completely different semantic on the language. I can't imagine that would be fun to debug in a live browser session.

Actually going back to C# now is a frustrating experience compared to ES6 in just how the type system limits you. Granted that has more to do with nominal typing vs structural, then static vs dynamic. I'm guessing TypeScript don't have the same issues.

shados18• 10 years ago

Flow's way of handling classes nominally and interfaces structurally is really nice.

By the way, can you extrapolate on eslint and babel working to check symbols across modules? I don't think I ever noticed that feature.

hokkos• 10 years ago

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.

Lazare6• 10 years ago

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

finishingmove3• 10 years ago

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

calinet6• 10 years ago

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.

natrius2• 10 years ago

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.

z1mm32m4n• 10 years ago

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.

bottled_poe• 10 years ago

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.

yread• 10 years ago

I was kinda hoping it was satire

natrius2• 10 years ago

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

untog2• 10 years ago

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

marcus_holmes3• 10 years ago

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.

interlocutor4• 10 years ago

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

jwingy• 10 years ago

Wow never knew. That's a pretty huge barrier that more people should know about.....

dsp1234• 10 years ago

you are giving Facebook a free license to your entire patent portfolio.

It's bad, but it's not quite that bad. Theoretically, you could stop using React, then start the patent litigation. Then Facebook could not sue you for React because at the time litigation started you were not using the license. But that's definitely a high barrier to jump if you've built up react as a core part of web and/or native applications.

Lazare6• 10 years ago

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.

I believe a couple of lawyers have suggested that this could, maybe, arguably be true. However, no court has ever ruled as such, and the consensus among IP lawyers is that it's an unlikely outcome.

If you're worried about potential patent lawsuits, I would NOT suggest relying on the vague hope that someday a court might read an implicit patent grant into the BSD license, especially when you'll be facing off with Facebook's lawyers.

Or do you have some citation for the "implicit patent grant"? In particular, a court decision finding one?

SiVal• 10 years ago

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

Lazare6• 10 years ago

Not exactly. The diff is here: https://github.com/facebook/react/commit/b8ba8c83f318b84e429...

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.

interlocutor4• 10 years ago

No, that's incorrect. It is any patent assertion against Facebook. Read it for yourself: https://github.com/facebook/react/blob/master/PATENTS

Silhouette3• 10 years ago

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.

The obvious next question is: what patents are necessarily infringed in the first place, just because you used React? It's a useful tool, but even if Facebook have successfully acquired relevant US software patents, it's hard to believe there's anything significant in there that had no prior art. GUI programmers have been specifying presentation details declaratively, using templates, and bundling updates for performance since long before the existence of React (or Facebook, for that matter).

tobltobs5• 10 years ago

The obvious problem with this interpretation is that it doesn't matter if a patent contains anything significant. How much cash you have and how long you can endure the uncertaintities which come with a legal confrontation with facebooks lawyers are what matters.

matthewmacleod• 10 years ago

I'm not completely on board with this argument. In particular, there may not be any patents on React in the first place, and the 'implicit grant' included in the BSD license is legally sketchy at best – AFAIK it has not been tested, which suggests that relying on any BSD licensed software exposes you to legal risk where you do not have an explicit patent license.

guelo• 10 years ago

This clause is awesome. Software patents are awful and this clause reduces the chances of patent lawsuits.

STRML3• 10 years ago

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) is one of the few solutions I like. I would be very happy to see it, or something like it, go mainstream.

nzonbi• 10 years ago

Polymer (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.

STRML3• 10 years ago

Yeah, I had good fun building a Polymer frontend for my weekend project, Secureshare. I got around some of the data binding shortfalls with polymer-signals.

It's been probably 2 years since I did it, so I'm sure there are better solutions - but I liked it as a dev environment. It's somewhat opaque, though.

https://github.com/STRML/securesha.re-client/tree/master/pol...

spankalee3• 10 years ago

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.

dinkumthinkum3• 10 years ago

Does all that really give you hope for the web as an application platform? I feel like there is an obvious kind of joke in so many discussions of front-end web programming tools. It is boarding on like a farce or satire of some kind ...

Every comment is has a different litany of obscure libraries and frameworks and combinations that sound like a set of random dictionary words with just a few common threads "react, react, blah blah."

It doesn't seem like "pace of technology change" and it certainly doesn't inspire the idea of relative maturity of the web as an app platform .... it seems like a comedy.

STRML3• 10 years ago

It does give me hope.

It's happening, and yeah, it's not perfect. But almost nothing in tech is. If we can build the right abstractions to paper over the mess that is the web as a platform, it might be possible for us to easily build reliable / useful / safe applications again.

rtsao• 10 years ago

CSJS author here, thanks for the plug! I think CSJS fairly unique in comparison to the numerous alternatives in that it:

1) Can be used without any tooling whatsoever. It's just plain JS.

2) Doesn't reinvent the wheel. You can use regular CSS (normal syntax, pseudo classes, media queries) and regular JS (variables, modules) together, allowing you to use the best of both worlds.

I loved the ideas behind CSS Modules but wasn't sure about the complexity of re-implementing a new module/variable syntax into CSS. Why not just use what is already provided in JavaScript?

shados18• 10 years ago

What's the story for tooling though? I haven't looked at CSJS much, just the readme, but it seems like the CSS bit essentially is a string, so you don't get the same kind of tooling you can from either CSS files or javascript objects, because it's all strings.

Am I just missing something obvious?

marknadal• 10 years ago

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.

ams6110• 10 years ago

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.

baddox• 10 years ago

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.

arvinsim• 10 years ago

He did put a disclaimer at the bottom to use only what you need.

dinkumthinkum3• 10 years ago

Your view has merit but I think it is a minority one. Actually, I think the community is way beyond just webpack and babel. I think it's not exactly the "new Java," I think it's something we have not really see . It is kind of a stupendous over proliferation of many of these little kind of obscure projects.

I saw a headline of an article the other day, something about "collections of microservices becoming the new monoliths" and it seems like that's what JS community is tending toward, an enormous amount combinations of these these frameworks/libraries/build tools/package managers. I guess the advantage of this style over traditional monoliths is there are more conferences to go to, I dunno.

n0us• 10 years ago

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.

jastanton• 10 years ago

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

amackera• 10 years ago

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

Can_Not• 10 years ago

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.

z3t42• 10 years ago

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!

phoboslab• 10 years ago

Ejecta lets you use Canvas+JS without the browser – at least on iOS. http://impactjs.com/ejecta

err4nt• 10 years ago

How does it look on retina/hiDPI displays?

z3t42• 10 years ago

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.

kmfrk• 10 years ago

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

sotojuan2• 10 years ago

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.

dchest• 10 years ago

ESLint catches more errors.

mariusasdf• 10 years ago

eslint is great. Through plugins it supports ES6, jsx, etc. Also, automatic code fixing.

shados18• 10 years ago

eslint also has auto-fix support to some extent. I don't know how far JSCS pushes it though.

The biggest thing is that whenever something new pops up, you can get an eslint plugin to lint it (eg: it took a wh ile for jshint to be able to take JSX or even just ES6 syntax, while ESLint got plugins for it pretty quick).

I think (don't quote me) that eslint is starting to have pretty cool Flow hooks, too.

acron0• 10 years ago

Not even a mention of ClojureScript? :(

shados18• 10 years ago

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.

t1amat7• 10 years ago

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.

keithwhor• 10 years ago

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/

[2] https://medium.com/@keithwhor/realtime-doesn-t-belong-everyw...

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

shados18• 10 years ago

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.

dinkumthinkum3• 10 years ago

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

tonyle• 10 years ago

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.

lsdafjklsd• 10 years ago

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.

shados18• 10 years ago

Ramda really is awesome.

pandler• 10 years ago

we've turned an ember-cli ember app into a react redux app in place using immutable.js and ramda for everything

Would you mind elaborating what you mean by that? We also use Ember and I've been championing the use of Ramda. I'm curious how you fit immutable.js into Ember.

jdd• 10 years ago

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

calebgilbert• 10 years ago

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

Mc_Big_G• 10 years ago

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.

tobltobs5• 10 years ago

Come on, Ember is so 2015 ...

jjawssd3• 10 years ago

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

hackerboos• 10 years ago

What the author failed to mention is how much work it is to get all of these ad-hoc projects working together.

Ember is a pretty cozy ecosystem in comparison. You get Babel, JSHint, npm and QUnit - out of the box. Most of which can be swapped out for your preferred libraries.

seanp2k23• 10 years ago

This. My team is currently making a pretty big bet on the future of Ember, and so far it's been amazing (coming from Drupal + Rails templates with jQ everywhere). Back-ends are in Rails API. Works great with Ember and you don't have to make 47462685868 decisions to get started with a project, make all the tooling play nice, then teaching the rest of your team how it all works. We're currently in the process of establishing a "paved road" for CI/CD for Rails API back-end + Ember front-end apps.

Ember CLI is also awesome, and Ember CLI Deploy is damn cool once you get it: http://ember-cli.com/ember-cli-deploy/docs/v0.4.x/lightning-...

Deployments take tens of seconds. Roll-backs take single-digit seconds. Previewing not-active-but-uploaded versions of the UI is trivial. Everyone does the same exact thing when they deploy (or throw it on Jenkins for even more fun).

pedrokost• 10 years ago

Fully agree. Recently, I have discovered a new reason to use Ember. I have an Ember app I built, but only have a few hours a month to maintain it. Using the Ember stack makes it trivial for me to quickly (and almost painlessly) upgrade as needed, and focus the little time I have on building features. Reading this article made me cringe at the thought of using the proposed stack for this app, having to follow the development of each of these components separately, and fixing the glue between them when things go sour.

Ember gives me confidence, that I can keep maintaining the app with very low effort, especially now, that the Ember community is releasing a LTS version.

davidjnelson10• 10 years ago

Hopefully it's improved since I used it two years ago, but back then the component api was terrible. Simple things like nesting components required undocumented apis and was much harder than it needed to be.

alextgordon3• 10 years ago

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.

jessep• 10 years ago

Seems like it makes sense to me. Here's an analogous situation to jquery:

X = a huge workshop with a million tools, a table saw, ladders, and yes, a hammer and some nails

Y = some nails

Z = a hammer

You need to hammer stuff as part of your job. Yeah, if you get rid of X you need to replace it with Y and Z, but it still seems like simplifying to me, if you're replacing a whole room full of tools with just the tools you actually need.

alextgordon3• 10 years ago

The workshop is free to use (it's on Google CDN), but the hammer and nails cost money. Seems like a no brainer to use the workshop.

If the hammer and nails were actually better, then fine. But there's nothing actually wrong with $.ajax, that I can tell.

hughes• 10 years ago

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.

BinaryIdiot2• 10 years ago

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.

ChrisDutrow5• 10 years ago

Perhaps I'm naive, but shouldn't very many users already have jquery cached from several CDNs? So if you use a popular CDN for it, it should affect load times too much in most cases?

Joeri• 10 years ago

Odds are a single retina icon in your app is larger than jquery. Worrying about javascript code size is like worrying about the drag of a car bumper sticker.

elchief2• 10 years ago

Remember last year when $.ajax wasn't legacy? Those were good times.

sotojuan2• 10 years ago

? I always just install `isomorphic-fetch` or the browser-only version. Works fine. Why load jQuery instead of that?

alias240• 10 years ago

fetch does not support cancellation or onprogess events.

coldtea• 10 years ago

You would have a point only if X was smaller (or at least equal) to size, complexity etc to Y + Z.

And the whole point of TFA is that this is not the case. You can argue that it is, but not without getting into specifics.

Merely asking how can 2 things be simpler/smaller/better than 1 thing without taking into account what those 3 things are, makes absolutely no sense.

alextgordon3• 10 years ago

jQuery is an 86kB static resource that almost certainly already exists in the browser's cache. You can choose to use it, or not, but you can't get stop it from being there!

So I'm unsure what kind of complexity you're adding by using it. Mental? Spiritual? Metaphysical?

Sacho2• 10 years ago

Meh. I think a better reason to use something over $.ajax is the functionality and the API, not because "you don't need jQuery". $.ajax is very general purpose, whereas in most cases you simply need to be able to get and post json. Also, jQuery's promise implementation is one of the least-featured and most awkward to use, which drags down the $.ajax API.

tobltobs5• 10 years ago

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.

seanp2k23• 10 years ago

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"

davidjnelson10• 10 years ago

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.

davidjnelson10• 10 years ago

Hmm, I haven't found this to be true. I researched and chose nearly the same stack at work about six months ago, except I chose and we use immutable.js, es7 async functions, flow, and axios.

What seems to be about right is that javascript spa frameworks go on two year hype cycles if you look at backbone->angular->react.

I suspect react will buck this trend though because it's so heavily used in production consumer apps at facebook/instagram, because of react-native because it got components so right that it's almost hard to build ridiculously long "controllers" when using it, and that it's one way data flow make it a lot harder to write an app with state spread out all over the place rather than in a single client side data model. But who knows, time will tell :-)

tobltobs5• 10 years ago

Yeah, this time it's different ...

ausjke• 10 years ago

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

Kequc• 10 years ago

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.

interlocutor4• 10 years ago

You still need some sort of templating library. You can use Handlebars or Mustache, but if you are using TypeScript there is now something better: https://github.com/wisercoder/uibuilder

UIBuilder is basically TypeScript's TSX file but without React's bloat. The whole UIBuilder is about 100 lines of code. The advantage over Mustache is compile-time error checking of expressions used in the template, and of course full Intellisense, Refactoring etc if you are using Visual Studio.

tomc19852• 10 years ago

You can write your own "templating library" in about 20 lines of regular boring ol' JS

terda12• 10 years ago

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.

jschrf• 10 years ago

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

JDDunn94• 10 years ago

I am currently building a large SPA in pure javascript (custom elements mostly) and it's wonderful. It's great to work with real components instead of React's hacked kinda-sorta-components.

achairapart• 10 years ago

Can we all agree that State of the Art JavaScript in 2016 is a mess?

BinaryIdiot2• 10 years ago

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.

kowdermeister• 10 years ago

Just as messy as a supermarket for having lots of options for chips, booze or milk.

drumttocs8• 10 years ago

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.

elchief2• 10 years ago

Meteor is so February 2016

davidjnelson10• 10 years ago

Meteor's concept of hot patching deployed, running applications in users browsers is _amazing_.

treenyc• 10 years ago

Why not 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

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

shados18• 10 years ago

If you want the React semantic without the size, you can just use something like https://github.com/developit/preact (which is like 3kb once deployed).

You also don't need JSX if you don't want to. Using React without JSX and just aliasing the dom functions ends up looking almost the same.

The reason behind React and Flux is because of pitfalls behind MVC...though the whole rational behind that is probably not fit for an hacker news reply :)

cetra3• 10 years ago

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/) and angular (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).

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.

techdragon2• 10 years ago

Personally, my ideal library would be one that doesn't make me 'beg for help'... one that is so easy to use that I can just 'weave it in' to all of my existing HTML that need it without needing a mountain of pre made parts to work faster. After all... making strait HTML is pretty damn fast with any competent template engine, server side or client side.

mst• 10 years ago

Getting a more MVC approach and still leveraging the react ecosystem is making me seriously consider trying react+mobx.

hjek• 10 years ago

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://purecss.io/

kenOfYugen3• 10 years ago

Mithril is really nice, I've been following its progress since the beginning. If I had to use a framework, Mithril would be my first choice.

lichess.org is a very busy application built around Mithril.

b34r• 10 years ago

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

tomc19852• 10 years ago

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

shados18• 10 years ago

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

davidjnelson10• 10 years ago

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.

raspasov• 10 years ago

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.

reedlaw• 10 years ago

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.

increment_i• 10 years ago

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.

shados18• 10 years ago

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.

clouddrover2• 10 years ago

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.

untog2• 10 years ago

criticize this convoluted house of cards - and of course proceed to be downvoted into the Stone Age as the latest casualty of HN censorship.

Pretty much all of the top comments are criticisms like you have outlined. They almost always are, too - they might get downvoted, but they get upvoted a lot more.

dang• 10 years ago

and of course proceed to be downvoted into the Stone Age as the latest casualty of HN censorship

That's not true. If anything, more people here support the house of cards view.

It's a common cognitive bias on HN to see the community as lined up against one. Of course the opposite side imagines the same thing. L'enfer c'est les autres.

Niksko• 10 years ago

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?

t1amat7• 10 years ago

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

mparr4• 10 years ago

It's not that simple.

I can swap out Angular for React + Redux in my application without my backend knowing about it. The same is not true of React + Relay + GraphQL.

It's a bigger, more involved decision that doesn't strike me as being particularly practical for an individual or a small team. Couple that with the fact that making a bigger, more involved decision is harder for bigger teams and it becomes apparent why it would be hard for Relay + GraphQL to "win" over Redux.

pkrumins• 10 years ago

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.

shados18• 10 years ago

The ecosystem exploded because of a few core advances (ES6 finally coming out, Babel coming into light, the CommonJS approach to modules, the rebirth of functional programming on the frontend, etc).

This is behind us now. If you sit in forums, chat rooms and other JS centric communities, you'll see that the dialog is pretty different.

It's no longer "Let's build a new tool!" (oh there's some of that, but they rarely hit the spotlight). It's "How do we make this tool work in this edge case we didn't think of".

There's still a framework every other day, but they're usually built on top of the core things now, and no one really pay attention to 99% of them anymore.

If you remember the early days of Java and SOAP with the new SOA framework a day, this is pretty similar. It's settling down.

leeoniya• 10 years ago

Good ideas get standardized.

Ideas from Coffeescript made it into es6, Promises, fetch, etc. Once there are sufficient standards that solve the pain points, the fragmentation will go away. JS is playing catch-up because it was pointless to advance the language when IE didn't even support the existing standards and had 90% market share. Now it has to distill all the good ideas from the past 2 decades and other languages in short order. The chaos is understandable.

spriggan34• 10 years ago

Standardization isn't enough. No browser implements ES6 modules thus the webpacks and co.

utku_karatas2• 10 years ago

JS scene desperately needs a moratorium on tooling just like Python did on language features 5-6 years ago.

Actually the language also needs a total freeze in features. ES5, ES6, transpilers, this and that and bla bla. I used to love language geekery, not so much after a few years of JS exposure. And now there is WebAssembly which is supposed to be a "game changer". Fuck that. I don't want the game to change anymore, I just wanna play.

Or perhaps, I'm just getting old.

girvo• 10 years ago

I don't understand this argument at all. You don't have to be on the bleeding edge. In fact I recommend against it for nearly all cases. If you want to write standard ES5, and skip all this stuff, you can! There is no one holding a gun to your head telling you to keep up "or else".

I pick and choose the tools I need. Some are new, some are old. This goes for any language I use, too, not just JavaScript.

exizt88• 10 years ago

It's all ugly and complicated. There's no beauty to these tools.

Which succesful, widely adopted languages have beauty to their tools?

mbrock• 10 years ago

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.

Um. That applies to all software... but not especially to React and Redux. Or what are you comparing with?

Is there anything in particular you dislike about React, or Redux, or Babel?

I don't think this ecosystem is going to "collapse" at all. Something else will come along, as always. Until then, it's a fine set of tools.

You don't need to feel despair about choosing tools.

Spending weeks to learn an ecosystem of dynamic web programming... yeah, what's wrong with that? How quickly would you prefer to learn?

I learned to use React in a couple of days, for what it's worth. It's remarkably straightforward and the API surface area is small.

Redux is such a simple idea that I accidentally invented nearly the same thing before I even knew about Flux: put your app's state in a global immutable object, then use values to represent actions that transform the state. It's not ugly or complicated.

You don't need to be tricked by peer pressure either. You can be as conservative and cautious as you wish.

Why all this... whining?

iffe_closure• 10 years ago

Redux is such a simple idea that I accidentally invented... >put your app's state in a global immutable object, then use values to represent actions that transform the state. It's not ugly or complicated.

i agree that react is fairly simple..it's the other pieces to get it to be a complete solution that are just ugly and complex. I'm sorry but flux and redux are another layer of abstraction that are much harder for new starters to grasp. The advocates are so deep in the echo chamber that you don't realize how daunting all this.

anantzoid• 10 years ago

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.

techdragon2• 10 years ago

Yeah... until the mountain of poorly documented plugins built on Webpack causes it to collapse just as Grunt, and Gulp did before it.

The first time I used Webpack... I wanted to punch someone so badly... their documentation for the Webpack plugin they wrote didnt mention that it would also turn all my SCSS/CSS into JavaScript. Imagine the disaster that was. This is the experience I have over and over again. I expect a 'plugin' to plug into things without requiring me to read every line of the plugin's source code... if I have to do that I may as well write my own tool. Community displeasure builds until someone writes a new tool and we get yet another mass exodus to that tool in the hope it will be better. It seems to be about 18 months to 1 year.

I suspect the entire JavaScript ecosystem is suffering from an effect similar to Dunbar's Number, https://en.wikipedia.org/wiki/Dunbar%27s_number

There becomes 'too many libraries' and after a certain point, the tower collapses again to a smaller pool of new dependencies because we cannot without much "fighting the tide" maintain a mental model with the level of complexity necessary to keep all these dependencies in our heads while working.

xirdstl• 10 years ago

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.

daviddahl• 10 years ago

+1000

wainstead• 10 years ago

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.

Yah, it's like XML all over again, when you describe it that way.

eranation• 10 years ago

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.

ellius• 10 years ago

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.

shados18• 10 years ago

The article mentions https://github.com/petehunt/react-howto. Its a damn good place to start.

ChrisDutrow5• 10 years ago

I just took a look, really good article.

melvinmt• 10 years ago

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.

scwoodal• 10 years ago

It's Django flavored but take a look at this repo[1]. Disclaimer, I'm the author. It wouldn't be too much effort to abstract out the front-end and make it back-end agnostic.

[1] https://github.com/scottwoodall/django-react-template

house9-2• 10 years ago

My co-workers put together 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

davidjnelson10• 10 years ago

The two best ones I know of are:

https://github.com/davezuko/react-redux-starter-kit and https://github.com/erikras/react-redux-universal-hot-example

arxpoetica2• 10 years ago

No mention of WebSockets...

andybak6• 10 years ago

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

arxpoetica2• 10 years ago

WebSockets are one of the most underestimated value-adds in modern browsers. Pub-sub. Real time. Ease of data transfer and client-to-server synchronization. I can't think of a modern project that wouldn't benefit from sockets, unless the site is literally 100% static. But then, why use most of the stack outlined in the article?

davidjnelson10• 10 years ago

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.

georgefrick4• 10 years ago

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.

jjawssd3• 10 years ago

AMEN

CalRobert• 10 years ago

It's also more than a little frustrating when you come to HN and people say "Angular/Node/whatever is bad, and you're a bad person if you use it" all while I'm actually making neat stuff using the aforementioned tools.

Well, I thought they were neat before at least.

akamaka4• 10 years ago

While other people are busy writing blog posts, I've been shipping successful projects with Angular. I'm getting paid to write code, and I don't get paid to write blog posts defending Angular, so I don't bother. Also, I've shipped some very complex apps built with Angular, and it's very obvious to me that many of the common complaints about it are nonsense written by people who have just used it for a few days.

JDDunn94• 10 years ago

Absolutely. React creates a dependency at the worst possible place, the view/component level. That's the one part of your code that should be the most re-useable. How many times do we have to re-write the same image galleries?

The only clear winner can be vanilla JS web components, especially custom elements. A temporary polyfill is fine, but we need to say no to the extra dependencies like React and Polymer that trap us in dependency hell and minimize re-useability.

spriggan34• 10 years ago

The only clear winner can be vanilla JS web component

It cannot work since some browsers have different support for different features. You think people stopped using Android 2.x or old iphones ? So you end up with polyfills and since polyfills become dependencies you end with abstractions akin to frameworks, even worse since you now need to maintain your own mess.

Javascript isn't scoped in an HTML page, that's its first "sin". Therefore, any component architecture needs to work against the natural workflow of a webpage. So no ,the winner is certainly not "vanilla JS" and you know it. unless you are dealing with some trivial apps, I bet you'd use framework X or Z in an heartbeat.

spankalee3• 10 years ago

I'm on the Polymer team, so admittedly biased here, but I don't understand your comment about Polymer minimizing reusability.

Polymer is designed to _mazimize_ reusability and interoperability via standards. Polymer elements just elements and you use them via standard API - set properties, attributes, listen for events, add children. The only wrinkle is that Shadow DOM is a little slow to polyfill, so we're using a wrapper on the DOM API. This will eventually go away.

Polymer is also extremely small compared to other libraries, and has no external dependencies: 34k gzipped without polyfills and 42k with. This will get better as native Custom Elements arrive across browsers later this year.

My main point is that in the Web Components future, it will not matter so much what libraries are used to implement components, as long as they are standard elements on the outside. The guts can be Polymer, some future web-component supporting React, Angular, etc., or just plain JS.

mwhite• 10 years ago

No one is saying that no one should still use tech that was previously state of the art. No one is saying that you need to rewrite existing apps if there's no business need to.

I use Backbone models in a React app because Backbone is still the best library for models. I haven't tried Redux because it doesn't solve any problem I know I have.

Plenty of people skipped Angular because they knew it wasn't going to be on top of the hill for very long in the evolution of the frontend ecosystem.

ericflo• 10 years ago

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?

jmduke3• 10 years ago

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.

georgefrick4• 10 years ago

"It's pretty clear... is the direction the industry as a whole is going".

You or anyone else posting hasn't identified this "industry", it appears to be "quickly built apps that have no lifespan". I mean no offense; but we're back to saying it should be used because people are using it.

I'm upset at exactly that; it's not like anyone replied with objective software development reasoning that justifies this constant shift of frameworks, or addresses the need for enterprise software to have a longer horizon for support and talent.

narrator• 10 years ago

I just don't get the reactjs hype either. If you look at the data[1], it's still in the early phases of the adoption cycle while angular is a very broadly used technology. I guess if you just look at the bay area it looks like it's getting some traction, at least in San Francisco[2].

[1] https://www.google.com/trends/explore#q=angularjs%2C%20react... [2]https://www.google.com/trends/explore#geo=807&cmpt=q&q=angul...

jmduke3• 10 years ago

For me, at least, it is a helpful reminder that HN is disproportionately enamored with the bleeding edge, and that at any given time around a thousand people are exploring Java for every one person exploring React.

(Put another way: hype, even valid hype, can fall victim to an echo chamber.)

Brakenshire• 10 years ago

That data looks messed up to me. The Reactjs search is most common among Russia, China, US, Australia, Canada, France, UK, Germany. The Angular search is most popular in India, Sri Lanka, Bangladesh, Belarus, Israel, South Korea, Hong Kong ,Singapore, Tunisia, Ukraine. I suspect it may be because the angular search includes the term 'angular', whereas the equivalent for react is 'react js' (and not just 'react').

ChrisDutrow5• 10 years ago

Out of curiosity, what's wrong with backbone?

nobleach• 10 years ago

I don't think anything is "wrong" with Backbone. It's dated in its ideologies though. Backbone comes from an era of script tags and a global "Backbone" namespace. Until recently, it required jQuery to do its "innerHtml/append" DOM manipulation. As a way to add structure to a jQuery app, it's great. It leaves a lot of freedom to the implementer. I did find that I required something like Marionette to assist with views however. Many developers are starting to stray from the MVC pattern toward other (perhaps more interesting) patterns and I think this is where some of the koolaid-style "hate" comes in.

georgefrick4• 10 years ago

Nothing is wrong with Backbone. I thought it was beautiful. We don't always pick our tech though. It's part of the problem here; the hype engine is used to steer non-technical people, or more managerial technical people. While the engineers and technical leads might be completely comfortable; the next project starts and you are told it should use X since that is what the client kept mentioning when they called.

Also, some people love this. It means they can show up at work and talk about how they learned React and it's better and they can do a pretty good job of using the hype train to stand out from their peers.

tarsinge• 10 years ago

My maybe controversial opinion is that a lot of these hype problems, fatigue, ... come from one thing : Angular is a bad framework which beneficiated from an ENORMOUS buzz. I clearly remember 2-3 years ago when there was still no big apps written in it but everyone wanted to use it because "the JavaScript framework from Google! It will rule them all!". Meetups were full, enterprise catched on, and everyone invested huge amount of time learning this very hard and convoluted framework, and rewrote their app. Now we have a more natural, simpler, battle tested and better evolution with React, but everyone is understandably tired. I blame all this fatigue on this Angular mess, which is the definition of adopting technology because of hype and a lot of people fell in the trap

AlwaysBCoding2• 10 years ago

You nailed it. I feel like I've been permanently damaged from digest cycles, ng-filters, providers, transclusion etc... I feel like others must have been damaged enough to write off new Javascript frameworks entirely, which is unfortunate given how great React is.

akamaka4• 10 years ago

I just shipped another of many successful projects using Angular. There are lots of blog posts out there complaining about it, such as that it's over-hyped, or that it causes messy HTML templates. I didn't start using it because of the hype, and I don't find it hard to write clean templates. The complaints are mostly nonsense, as far as I'm concerned, and I'm highly suspicious of any argument in favour of React that's simply based on saying it has "won" or that it is the "next generation".

dkarapetyan• 10 years ago

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.

ilostmykeys• 10 years ago

Relay beats Redux any day

https://gist.github.com/idibidiart/49a095b6bc528638f34f

shados18• 10 years ago

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

kayoone2• 10 years ago

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.

doczoidberg2• 10 years ago

I think the same. I don't understand the react hype. Yes, it is easy to learn but it doesn't even have basic features such as routing. Maybe I am more a framework guy but I think on such a basic level of software development a framework does better than a fragmented ecosystem.

t1amat7• 10 years ago

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.

kayoone2• 10 years ago

ng2 will work with native script: http://angularjs.blogspot.de/2015/12/building-mobile-apps-wi...

sklivvz1971• 10 years ago

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.

shados18• 10 years ago

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.

bbcbasic2• 10 years ago

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.

t1amat7• 10 years ago

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.

bbcbasic2• 10 years ago

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

andybak6• 10 years ago

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.

thenomad• 10 years ago

I'd assume the reactions in this thread are part of the reason why people have been asking for a guide like this for months, and one hadn't been forthcoming.

The "if I write an article expressing my opinion on this controversial issue I believe is important, 99.7% of the responses will be attacks, more or less regardless of the amount of time I put into writing it or the extent to which it's 75%, 95%, or 99% accurate" issue is a problem Internet-wide.

Of course, criticism is valuable, but the balance seems a little skewed right now.

danmaz742• 10 years ago

It's just one data point, but a few months ago we had to choose the tools which we should use in our next bigger projects for front-end development, one where we had to start from scratch with a completely new and pretty junior team, and one where we had to progressively consolidate and refactor a fairly complicated SPA written with CoffeeScript and jQuery (both front ends are on top of a Rails backend and integrate with some non-SPA Rails frontend).

We did some pretty extensive research and comparisons back then. What we came out matches 90% what the OP proposes, and we're very satisfied with the results so far.

dcposch• 10 years ago

I also agree with 90% of what OP proposes.

He didn't explain what he likes about eslint-airbnb. A lot of open source projects are adopting Standard (https://github.com/feross/standard) and I've had a great experience with that.

He gets the big picture right--Keep It Simple. For example, he recommends using straight npm scripts when possible rather than Grunt / Gulp / Yeoman / etc

oneeyedpigeon• 10 years ago

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

DrJokepu• 10 years ago

Yes, well that doesn't seem to be working very well, does it?

andybak6• 10 years ago

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

abledon• 10 years ago

When i clicked on the link, i was really hoping it was a tongue-in-cheek medium article that just said to use jQuery haha.

lomnakkus7• 10 years ago

Well, I guess I can count myself amongst the "haters". Specifically, I noticed your

4. I hate dynamic typing

... but I absolutely disagree with the phrasing. Your underlying assumption seems to be that "dynamic typing" is a Good Thing, by definition. I want to challenge that.

Thing is... I don't hate dynamic typing[1] as long as everyone is being "consenting adults" about it (GvR)... I just LOVE static type checking since it helps people who absolutely hate each other to get along on >= 1 axis! So much so that I try to evangelize at every opportunity.

5. Javascript is broken beyond repair

This is a straw man. People usually have very specific and valid(!) objections to JS semantics... and, sure, they can and probably will be fixed at some point, but given the facts and constraints of the web platform it's going to take years and years. Personally, I'd want to be programming in a better language ASAP rather than in several years.

[1] Should really be "dynamic type checking", but whatever.

andybak6• 10 years ago

Yes. But my point is that not every discussion needs to be dominated by the well-known split between two factions who both have strong feelings about type systems.

You have every right to evangelise - but try and try and avoid making top level comments on the matter unless it's on a post that specifically is discussing static vs dynamic typing. The subject gets enough airtime and it's good for other topics to get a look in. :-)

vehementi• 10 years ago

Or a "yes we already know that" filter...

This is what really gets me in every thread about anything. People begin touting their opinions from basically their gut or first principles without getting to the state of the art of the discussion before proceeding. We now have four #alphago threads with many of the same comment chains. What can we do to prune all of that stuff on similar threads or reposts?

cel1ne• 10 years ago

Regarding CSS I recommend tachyons [0] over css-modules.

[0] http://tachyons.io/

kenOfYugen3• 10 years ago

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

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

[3] http://programmers.stackexchange.com/questions/278778/why-ar...

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

k__3• 10 years ago

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 :/

kenOfYugen3• 10 years ago

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

RobertKerans• 10 years ago

I think the key point he makes (even though it's almost throwaway at the end of the paragraph) is that the community is rapidly declining. I agree with you completely on the syntax: it's not my bag (I prefer writing plain [ES6] JS), but idiomatic CoffeeScript is remarkably expressive. But the decline, which is undoubtedly accelerating, is problematic. I'm busy ripping CS code out of several big Rails apps simply for the sake of maintainability going forward. Good CoffeeScript code is not quite 1-to-1 translatable to/from JS; it's a simple language, but it is an actual language with its own constructs. I feel it's important to make it as easy as possible for others to maintain code I've written, and using JavaScript makes that easier than having it written in another language.

The Bluebird comparison I think is off for that reason - Bluebird is a JS library: you only need to know the API, it's still JS. If a developer understands promises, there's no great step between native and Bluebird.

(I totally agree with what you're getting at btw, I just think [maybe for the worse, maybe not] that it is pragmatically better, with the advent of ES6, to stick to JS; TypeScript maybe gets a let-off here as it's just a thin layer on top, not a different language).

sandra_saltlake• 10 years ago

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

k__3• 10 years ago

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

neovive• 10 years ago

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

t1amat7• 10 years ago

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/ [2]: http://blog.evanyou.me/2015/10/25/vuejs-re-introduction/

doczoidberg2• 10 years ago

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?

pdog• 10 years ago

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

feiss• 10 years ago

I feel dumb for not using React. Damn, I even feel I'm living in sin.

mhd• 10 years ago

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

vmware5052• 10 years ago

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

davidjnelson10• 10 years ago

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

Versus react's: https://facebook.github.io/react/docs/multiple-components.ht...

Versus angular's: 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.

vmware5052• 10 years ago

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 (Tick the check-boxes, Ember.js is nicely object oriented, so you can get a lot from parent classes.)

oever• 10 years ago

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.

jgalt212• 10 years ago

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

ashwin_kumar• 10 years ago

> "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

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.

State of the Art JavaScript in 2016

Related Stories