State of the Art JavaScript in 2016
medium.com
medium.com
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.
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.
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.
TypeScript definitely got the structural checking of interfaces right, but I beleive (correct me if I'm wrong, I'm referring to https://github.com/Microsoft/TypeScript/issues/202) that classes are also structurally checked. Flow does nominal checking for those, with very good reasons.
While it's a shame the details are light because you kind of need the presenter to go with the slides, the following explains a few of the reasons between TypeScript vs Flow:
http://www.scs.stanford.edu/16wi-cs240h/slides/fb-slides.htm...
(not the whole deck, just a few slides after 45)
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
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.
I truly feel that "disjoint unions" is one of those things you don't appreciate the true value of until you've used them for quite a while. The real eye-opener for me was implementing a state machine and finding that I could explicitly state exactly which bits of the state machine would propagate to $NEXT_STATE at every step... and have the compiler double-check for me that I got it right.
EDIT: I accidentally a accidentally.
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'
}))
})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.
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.
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.
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.
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.
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
Notably, it uses a "no semicolon" style which is used by around 11% of JS devs[1] and is always capable of igniting a heated argument, but it also has some other questionable choices: For example, it enforces spaces after function names (eg, "function valid (size, name) {/.../}" versus "function invalid(size, name) {/.../}"), which no other style guide or linting rules agrees with.
The point of posts like OP's is, I think, to advocate people standardize on the best tools, or when multiple tools are equally good, the most popular ones. `eslint-airbnb` is at least as good, and much more popular by basically any metric (eg, the `airbnb/javascript` repo has 31k stars, the `feross\standard` repo has 4k stars, etc.). To the extent that there is (or should be) a standard for linter rules, I think it's airbnb's.
[1]: https://ponyfoo.com/articles/javascript-developer-survey-res...
They already do; if something doesn't positively contribute to the discussion, downvote it.
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. ;-)
Even so I'm slightly embarrassed that it's the top voted comment. I'd prefer it if a more strictly on-topic comment was above me.
> 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.
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. :-)
I must say, I'm also not a fan of the almost-always-fake "balance" thing we see so much in journalism and television, FWIW.
(Just as a trivial example there can be no "balance" between a Homeopath who claims to cure toothaches and a dentist. One is supported by massive amounts of a-priori plausible evidence and the other... isn't. Sorry about that mini-rant :).)
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?
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.
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.
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.
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.
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.
I keep an eye on what is coming down the pipe but I don't buy into anything until it's been around long enough for me to get a good grasp on what the lay of the land is.
In the meantime I have a working stack that allows me to accomplish anything I reasonably need to and I know it'll work.
For those not au fait with Knockout, recent releases add HTML components, deferred and pure computeds and in 3.4 they increased performance through hot paths over 100% making it insanely faster.
I like it a great deal.
Which succesful, widely adopted languages have beauty to their 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?
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.
As always in a large enough population, there exists multiple dichotomies. Its a difficult problem; In this case, some people want better(more specific) tools, and others want less choice and time to learn one tool well. There is no really good answer to this, given that you can't please everyone, and software empowers minorities to fulfill their visions regardless of the majority. Ideally we can just hope that all evolution is cyclic (explosion of ideas, consolidation of ideas, repeat) and overall we stay in a healthy equilibrium. However, this is a problem in all aspects of life, from fashion to food. Even within computer science its not a problem unique to JavaScript.
JavaScript without Babel, React + (Flux | Meteor | Redux | Relay) is a non-starter. Some may also swap out for: Angular | Ember | Backbone + jQuery. And almost always there are additional "custom"[0] homegrown frameworks on top of or alongside everything else. Java without (Spring | Guice), Lombok, (AspectJ | Spring AOP), Guava, (JodaTime | Java8), ApacheCommons, (Log4J | SLF4J), (Hibernate | ...) is a non-starter. Some may also swap out for: JavaEE + (Glassfish | JBoss). And almost always there are additional "custom"[0] homegrown frameworks on top of or alongside everything else.
I'm just using Java because I have to deal with it daily. However, undoubtedly this is a problem across any language or tool that has a large enough population.
[0] "custom" is in quotes because developers that create them always claim they are general purpose, regardless that in reality only one application has ever used it in production.
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.
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.
Yah, it's like XML all over again, when you describe it that way.
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.)
If you're involved in the JS scene, learning React will give you a big advantage. At which point you can decide whether you like it or not.
As for mixing JS and HTML, I went to a talk at last year's React Europe that beautifully explained why this isn't a concern. I had the same reservations at first, but I was convinced then. Suffice to say, give it a shot and see how you feel about it after (besides, jsx is optional).
Start here: http://jamesknelson.com/learn-raw-react-no-jsx-flux-es6-webp...
I think the benefits of this were undeniable but not quite for the reasons everyone thought. At that point html was such a mess that imposing ANY structure on it would have been an improvement. CSS saved us from nested image-table-slicing hell.
Separating markup from style is one way to structure a complex document but it's not the only way. However it's better than 'no way'. But don't cargo-cult it.
But you're not mixing js and html. JSX is not html, it's a DSL to express a tree-like structure. In that sense, it's like mixing js and...dom creation logic.
The reasons I'm aware of to avoid mixing html and js fall into roughly two categories - separation of concerns(don't mix business rules, state management, control flow etc with presentation) and concerns of encoding(building strings of html makes for poor development, debugging, brittle code, and so on).
Since React is just a view layer, it does not impose an entangling of concerns. You can do everything within React components, or separate things on your own or via some other framework.
Meanwhile, the gains from manipulating a DOM or a Virtual DOM are immediately obvious. Even the most popular libraries like jQuery advocate using a more structured approach than simply concatenating strings(e.g. jQuery's whole DOM creation and manipulation lib - although it does make tradeoffs and still allows plenty of html through). The (Virtual) DOM tree naturally allows for composition, compared to the complexities of composing strings of html together.
The paradigm shift from React isn't so much React itself, but the ecosystem it (subtly, or not so subtly) pushes alongside with it. Immutable state and pure rendering functions force you to think through the states and edge cases of your application that would otherwise remain as subtle bugs. Components with a clean life cycle(as opposed to angular 1 directives) allow for easy composition. The virtual dom allows you to divorce your framework from html and the browser, and transplant it to other devices.
By the way, the separation of markup and style was a fight for a semantic web. Web apps, which are React's primary use-case, generally sidestep that concern. The theoretical benefits of separating markup and style are still the same today, but the expectations placed on a web site have increased tremendously, and you must juggle those benefits with others.
In the past I tried many times to use some spare time to learn Angular, but it always felt too overengineered to me (also because it does much more than React) and I always stopped at the beginning. With React, just a few hours were enough to appreciate the concepts and get started.
Then of course you can add Redux and that will take more time, but you can almost just as well use React components with any state manager you like.
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.
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.
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."
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 :)
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.
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/
lichess.org is a very busy application built around Mithril.
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
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.
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?
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."
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.
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).
Patents, and particularly submarine patents, have been a risk in the software industry for a long time. This is particularly true in jurisdictions like the US, where both the everyone-pays legal system and the recognition of software patents are unfavourable to the little guy in most circumstances. No doubt many of us don't particularly agree with or support the current legal position, but there it is.
So that brings us back to my earlier question, which I notice you haven't actually answered: for this to make any difference in law, Facebook would need to have relevant patents that will apply if you use React, so what are they?
And if your argument is still that it doesn't matter because they can just sue you and keep pumping money in until you lose through attrition in court, then this is all irrelevant anyway, because in that case surely there would be any number of other grounds they could use to support an artificial, aggressive lawsuit like that without even mentioning anything about patents. I don't really believe even the US legal system is that distorted, by the way, I'm just playing along with your earlier argument to show why it wouldn't matter even if you were right.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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 :-)
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.
Well, I thought they were neat before at least.
I've got no dog in the Angular fight, but I will point out a problem with the 'while others have been arguing I've been shipping' line: while it does optimise for productivity ('shipping'), it ignores correctness. Imagine someone writing, 'while others were fighting over crypto, I was shipping [ROT13-using code].'
My problem is that these arguments are important: e.g. we know that the halting problem is not generally computable, so a product which relies on computing it cannot be right. And oftentimes 'just shipping' ignores the lessons learnt by those with more experience than oneself: 'I've been shipping' can really mean 'I've been busy putting myself in a position to learn' and 'others writing blog posts' can really mean 'folks who've learnt the hard way trying to warn others.'
Like I said, I really have no clew if Angular is a problem or not; I don't really write any JavaScript these days. My only concern is the form of your argument.
I definitely do worry sometimes that spending too much time getting things done takes away from time spent learning how to do things better. I hope that I've found a good balance between the two, but it's easy to get it wrong, and your point is an important one.
I really like this comment; because it resonates with my Backbone experience. I kept reading these hit pieces by Angular fans as part of my daily info gathering; but I had code to write and a project to deliver.
But not writing those blog posts may have been an error on our part; we avoided the discussions and it leads to the cool kids changing the rules all day.
I can't force you or I to write these posts; but maybe we have to face that there is a cost to not contributing.
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.
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.
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.
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.
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?
- 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.
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.
[1] https://www.google.com/trends/explore#q=angularjs%2C%20react... [2]https://www.google.com/trends/explore#geo=807&cmpt=q&q=angul...
(Put another way: hype, even valid hype, can fall victim to an echo chamber.)
It does mean bleeding edge, most hyped, etc...
I don't think it would be productive to switch to something new even if that new thing was better.
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.
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.
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.
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.
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.
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...
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.
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.
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.
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?
Am I just missing something obvious?
Go to terminal
ember new app
ember server
start writing code.
> 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.
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.
If the hammer and nails were actually better, then fine. But there's nothing actually wrong with $.ajax, that I can tell.
I'd happily include a 9kb (unminified) polyfill and work off the assumption that I can remove it a few years down the road.
$.Ajax is awesome and while XMLHttpRequest is awkward it's pretty straight forward.
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.
So I'm unsure what kind of complexity you're adding by using it. Mental? Spiritual? Metaphysical?
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...
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).
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.
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.
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.
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.
Once people can use the tool they want instead of the tool they have to use, things will be a lot better.
One thing about WebAssembly (and compile to JS languages have had that issue for a long time, and still do to some extent) is the tooling. If the debugger doesn't properly handle breakpoints in the original source (for real. Not the garbage that is sourcemaps that can't even properly map variable names), and if people developing in WebAssembly languages still have to think javascript, then it won't be much better.
And the load times are still good: https://github.com/WebAssembly/design/blob/master/FAQ.md#can...
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.
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.
One difference though is that I've read Relay and GraphQL will eventually win out over Redux. Thoughts?
[1]: https://mobile.twitter.com/dan_abramov/status/69755646131300...
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.
[2] https://medium.com/@keithwhor/realtime-doesn-t-belong-everyw...
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.
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.
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.
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.
I do really wish JS had native immutables with structural sharing, though.
- 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.
The interesting part is maybe that most apps look like this:
<html><body><canvas id="canvas"></body></html>
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!
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.
You can check here with this tutorial, how easy to write a complex application with Ember.js: http://yoember.com
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.
I don't get the whole React love? I always learnt not to mix view and business logic? React does this?
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/
- 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
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.
http://andrewhfarmer.com/aws-sdk-with-webpack/
Search google for webpack incompatible
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...
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.
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.
We're still in a world where every team is a snowflake (the closest things to breaching that was Rails and other server side MVC frameworks similar to it). Once the tech slows down a bit, you'll probably see better solutions.
That being said, dealing with legacy code always always suck.
For the life of me I cannot remember who it was, but somebody once essentially said that Javascript had the quality of allowing anybody to bring to life what's in their head, no matter their skill and experience level. You could almost mash the keyboard until it worked.
For me, this is a democratizing quality which is fundamental to the spirit of the web, and I would be more than happy to give up generators and class keywords for it.
I've recently spent over six hours trying to build and use a JS library, fighting with package managers, build systems and transpilers, whereas earlier all I would have need to do was download a file and include a <script> tag. We're not moving in the right direction.
If we were to have a hackathon, and I could use the stack I have at work (which contains some of these tools, plus our own secret sauce), I'll trash anyone who's using script tags on a page.
Things like webpack, commonjs, npm, etc, are ways to bring that to everyone.
If you're making a little one off or a small project, then anything you're comfortable with will work. Heck, go and use a tool just because you like the logo. It won't make much of a difference.
I agree though that the vibe is different. Newcomers feel less welcome. I think by the end of this year, we will see a layer of abstraction over a stack similar to the one described in this article, and that it will be the new jQuery, in terms of letting a novice developer make something surprisingly powerful. At least I hope so.
Recommend: https://egghead.io/series/getting-started-with-redux
https://github.com/davezuko/react-redux-starter-kit and https://github.com/erikras/react-redux-universal-hot-example
the whole function composition has a clean feeling and LS removes a lot of cruft
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.
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.
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 :-)
While it doesn't have the gradual typing and fantastic compiler messages, it is also functional and immutable. But to my view it has all around better tooling, very simple FFI (either reference JS already on the page transparently or pull in JS formally via extern definition files similar to TypeScript typings), optional typing via core.typed, sourcemaps with a native debugger, and a node-like full stack synergy through Clojure but with all the power of the JVM.
You definitely lose some confidence at run time due to the dynamic typing, but on the whole I think the gains far exceed that. At least for me it's a package that is very hard to beat.
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
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 :)