State of the Art JavaScript in 2016(medium.com)
medium.com
State of the Art JavaScript in 2016
https://medium.com/javascript-and-opinions/state-of-the-art-javascript-in-2016-ab67fc68eb0b#.37u0xx9xi
305 comments
> 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:
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 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.
Flow has pretty good support for tagged unions like this which act like ADTs:
http://flowtype.org/blog/2015/07/03/Disjoint-Unions.html
http://flowtype.org/blog/2015/07/03/Disjoint-Unions.html
This is great. Seems less cumbersome than TypeScript's user defined type guards for distinguishing cases of a union. The sentinel value concept is something you could at least steal when creating user defined type guards to make them simpler, at least.
TypeScript union types and Flow tagged unions are nice to have, but to make them really useful you also have to provide a good way to pattern match on them. And there they both are still way behind Haskell.
That's interesting! I haven't paid much attention to Flow since trying out the initial release and finding it a bit lacking. (But then, I'm used to GHC/Haskell, so everything lacking!)
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.
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.
This is really nice with a very good much to common JS patterns. Among other things it types the usage of string literals making possible to typecheck and refactor code that contains if (foo === 'bar').
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
Oh, wow, that's pretty evil code! :)
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'
}))
})Easy, but absolutely horrid on a large scale. (I mean, just try to enumerate the amount of redundancy you have in that short snippet you posted!)
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.
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.
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.
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.
Generally when TypeScript is compared to C#/Java, it is about the syntax look, or when contrasting it to other type system such as, let say, Scala. And then it's very much on the C#/Java side of the fence.
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)
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)
For comparison, Flow supports tagged unions like this:
http://flowtype.org/blog/2015/07/03/Disjoint-Unions.html
http://flowtype.org/blog/2015/07/03/Disjoint-Unions.html
TS has string types starting from 1.8, although they can't be used for narrowing down the type yet in the way that Flow can.
http://bit.ly/1LhA5id
http://bit.ly/1LhA5id
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.
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.
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.
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.
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).
Strongly agree. Surprised the author felt this way...
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.
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.
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.
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.
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
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
`feross-standard` is much less popular than `eslint-airbnb`, and it faces a struggle being adopted because it enforces some very unpopular choices.
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...
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...
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.
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.
"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.
They already do; if something doesn't positively contribute to the discussion, downvote it.
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. ;-)
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. ;-)
Yes we can and I started by yours. Sorry not adding to the discussion.
I actually edited my top level comment immediately after writing it to try and engage more directly with the topic at hand and tone down the 'meta-ness' of my post.
Even so I'm slightly embarrassed that it's the top voted comment. I'd prefer it if a more strictly on-topic comment was above me.
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.
Yes, well that doesn't seem to be working very well, does it?
> 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?
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?
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.
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.
> 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.
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. :-)
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. :-)
Ah, true. I think I may have missed your point entirely, but I'm not sure the blame rests entirely with me, FWIW. I think being more explicit about your point up-front ("the tease") and then elaborating ("the payoff") might have served your purposes better.
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 :).)
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 :).)
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.
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.
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.
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.
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.
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.
Standardization isn't enough. No browser implements ES6 modules thus the webpacks and co.
How the modules get loaded isn't specified either. All that's specified ATM are the syntax and static semantics. The loader spec probably has to be finished before any browser implements es6 modules.
And when they do support ES6 modules, I will kick my builder out the door, but until then there is no other way of keeping sane among the thousands of lines of JS.
[deleted]
[deleted]
> 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?
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?
> 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.
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.
> 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.
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.
[deleted]
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.
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 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.
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'm still using browserify, knockout and lodash for all my projects, been using knockout for over a year and it has been rock solid, had zero issues that where traced back to knockout, browserify has worked very well for me same with lodash.
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.
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.
It's a cognitive load, a burden. The paradox of choice, anxiety etc.
> 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.
Yah, it's like XML all over again, when you describe it that way.
> 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.
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.
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.
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.
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.
Both React and Angular has existed for more than a year. Angular is a couple of years old and still works although they have new version.
> It's all ugly and complicated. There's no beauty to these tools.
Which succesful, widely adopted languages have beauty to their tools?
Which succesful, widely adopted languages have beauty to their tools?
+1000
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.)
I disagree with the breezy assertion that types don't matter, and the offhand dismisal of TypeScript. And saying that "TypeScript tries too hard to make JavaScript like C# or Java" reveals, in my view, a fundamental failure to understand what TypeScript does.
I also think the author is a bit too strongly in favour of `mocha`; I don't think `ava` should have been some easily dismissed, and I've recently run across a pretty nice framework called `painless`. And even if you do use `mocha`, I find `expect` to be a better assertion library than `chai`. I think a better answer here might be "use whatever works for you, so long as its not Jest". (The shoutout to `enzyme` was on point though; great library if you need to test React components.)
The author seems a bit conflicted on whether he likes or dislikes types.
First, to say that "Types are not nearly as critical to front end development as some will have you believe" misses the point of types. Every programming language has types, even dynamically typed languages. As a programmer, embracing that types underly the code's meaning affords much more power to write clean, correct, and elegant code. This argument stands regardless of the type of programming; types underly code.
On the other hand, there's his remark, "TypeScript tries too hard to make JavaScript like C# or Java." (You claim that this is an unfair complaint against TypeScript. Would you care to elaborate what you think TypeScript's purpose is?) Personally, I feel similarly when working in TypeScript. Sure, the compiler can catch a few things, and it's certainly a step above only runtime type checks, but the type system itself is fundamentally flawed.
The type systems of Java and TypeScript are actually quite similar, so I'm going to refer to them both here. Neither language has a really good idea of what a sum or union type looks like. Consider doing math, but you can only multiply. Sure, it's possible to hack around some things so that you get the same results, you're doing a huge song-and-dance just to say that what you really want is this plus that.
Type systems like those present in Java or TypeScript (or, as it turns out, most mainstream languages) that lack unions end up leaving this weird aftertaste.
So my takeaway here is that we can do better. Certainly writing Java or TypeScript eliminates classes of bugs that Python or JavaScript are susceptible to, but let's keep pushing. We owe it to ourselves to strive for much better more expressivity in our type systems.
I'll use TypeScript over JavaScript for now, but I'm always keeping an eye out for technologies that raise the bar.
First, to say that "Types are not nearly as critical to front end development as some will have you believe" misses the point of types. Every programming language has types, even dynamically typed languages. As a programmer, embracing that types underly the code's meaning affords much more power to write clean, correct, and elegant code. This argument stands regardless of the type of programming; types underly code.
On the other hand, there's his remark, "TypeScript tries too hard to make JavaScript like C# or Java." (You claim that this is an unfair complaint against TypeScript. Would you care to elaborate what you think TypeScript's purpose is?) Personally, I feel similarly when working in TypeScript. Sure, the compiler can catch a few things, and it's certainly a step above only runtime type checks, but the type system itself is fundamentally flawed.
The type systems of Java and TypeScript are actually quite similar, so I'm going to refer to them both here. Neither language has a really good idea of what a sum or union type looks like. Consider doing math, but you can only multiply. Sure, it's possible to hack around some things so that you get the same results, you're doing a huge song-and-dance just to say that what you really want is this plus that.
Type systems like those present in Java or TypeScript (or, as it turns out, most mainstream languages) that lack unions end up leaving this weird aftertaste.
So my takeaway here is that we can do better. Certainly writing Java or TypeScript eliminates classes of bugs that Python or JavaScript are susceptible to, but let's keep pushing. We owe it to ourselves to strive for much better more expressivity in our type systems.
I'll use TypeScript over JavaScript for now, but I'm always keeping an eye out for technologies that raise the bar.
Although the article covers a lot of things and provides some arguments (credit where it's due), the fashion in which the choices are made suffers from a kind of tunnel-vision favoritism. Claims like, "Everyone should use React. Period. Now!" just make me question the merits of its proponents. The JavaScript community is really infamous for this...
React is a paradigm shift in UI development. If you've never tried it or a library inspired by it, that's why you're questioning the proponents. We're trying to spread the gospel that some folks found a better way to do things. Yes, I believe it is a mistake for any UI developer to delay learning React. It's fine to choose other tools later.
I come to HN regularly for advise. Should I be taking yours? I'm a web dev by proffession. React is a paradigm shift? Kind of like the paradigm shift 20 years ago where we said "separate your markup from your style, you'll be better off, promise"? Using css felt right, right from the start. I should really learn React? Mixing js and html in a react flavor does not give the the same sense of being on the right track.
You should learn React for one simple reason: It's quite definitely going to be huge. Well, that's what I was saying a year ago - it's fair to say now that it is already huge and it's likely to stick around for a long time (at least in JS years).
If you're involved in the JS scene, learning React will give you a big advantage. At which point you can decide whether you like it or not.
As for mixing JS and HTML, I went to a talk at last year's React Europe that beautifully explained why this isn't a concern. I had the same reservations at first, but I was convinced then. Suffice to say, give it a shot and see how you feel about it after (besides, jsx is optional).
Start here: http://jamesknelson.com/learn-raw-react-no-jsx-flux-es6-webp...
If you're involved in the JS scene, learning React will give you a big advantage. At which point you can decide whether you like it or not.
As for mixing JS and HTML, I went to a talk at last year's React Europe that beautifully explained why this isn't a concern. I had the same reservations at first, but I was convinced then. Suffice to say, give it a shot and see how you feel about it after (besides, jsx is optional).
Start here: http://jamesknelson.com/learn-raw-react-no-jsx-flux-es6-webp...
> Mixing js and html in a react flavor does not give the the same sense of being on the right track.
But you're not mixing js and html. JSX is not html, it's a DSL to express a tree-like structure. In that sense, it's like mixing js and...dom creation logic.
The reasons I'm aware of to avoid mixing html and js fall into roughly two categories - separation of concerns(don't mix business rules, state management, control flow etc with presentation) and concerns of encoding(building strings of html makes for poor development, debugging, brittle code, and so on).
Since React is just a view layer, it does not impose an entangling of concerns. You can do everything within React components, or separate things on your own or via some other framework.
Meanwhile, the gains from manipulating a DOM or a Virtual DOM are immediately obvious. Even the most popular libraries like jQuery advocate using a more structured approach than simply concatenating strings(e.g. jQuery's whole DOM creation and manipulation lib - although it does make tradeoffs and still allows plenty of html through). The (Virtual) DOM tree naturally allows for composition, compared to the complexities of composing strings of html together.
The paradigm shift from React isn't so much React itself, but the ecosystem it (subtly, or not so subtly) pushes alongside with it. Immutable state and pure rendering functions force you to think through the states and edge cases of your application that would otherwise remain as subtle bugs. Components with a clean life cycle(as opposed to angular 1 directives) allow for easy composition. The virtual dom allows you to divorce your framework from html and the browser, and transplant it to other devices.
By the way, the separation of markup and style was a fight for a semantic web. Web apps, which are React's primary use-case, generally sidestep that concern. The theoretical benefits of separating markup and style are still the same today, but the expectations placed on a web site have increased tremendously, and you must juggle those benefits with others.
But you're not mixing js and html. JSX is not html, it's a DSL to express a tree-like structure. In that sense, it's like mixing js and...dom creation logic.
The reasons I'm aware of to avoid mixing html and js fall into roughly two categories - separation of concerns(don't mix business rules, state management, control flow etc with presentation) and concerns of encoding(building strings of html makes for poor development, debugging, brittle code, and so on).
Since React is just a view layer, it does not impose an entangling of concerns. You can do everything within React components, or separate things on your own or via some other framework.
Meanwhile, the gains from manipulating a DOM or a Virtual DOM are immediately obvious. Even the most popular libraries like jQuery advocate using a more structured approach than simply concatenating strings(e.g. jQuery's whole DOM creation and manipulation lib - although it does make tradeoffs and still allows plenty of html through). The (Virtual) DOM tree naturally allows for composition, compared to the complexities of composing strings of html together.
The paradigm shift from React isn't so much React itself, but the ecosystem it (subtly, or not so subtly) pushes alongside with it. Immutable state and pure rendering functions force you to think through the states and edge cases of your application that would otherwise remain as subtle bugs. Components with a clean life cycle(as opposed to angular 1 directives) allow for easy composition. The virtual dom allows you to divorce your framework from html and the browser, and transplant it to other devices.
By the way, the separation of markup and style was a fight for a semantic web. Web apps, which are React's primary use-case, generally sidestep that concern. The theoretical benefits of separating markup and style are still the same today, but the expectations placed on a web site have increased tremendously, and you must juggle those benefits with others.
> separate your markup from your style, you'll be better off, promise
I think the benefits of this were undeniable but not quite for the reasons everyone thought. At that point html was such a mess that imposing ANY structure on it would have been an improvement. CSS saved us from nested image-table-slicing hell.
Separating markup from style is one way to structure a complex document but it's not the only way. However it's better than 'no way'. But don't cargo-cult it.
I think the benefits of this were undeniable but not quite for the reasons everyone thought. At that point html was such a mess that imposing ANY structure on it would have been an improvement. CSS saved us from nested image-table-slicing hell.
Separating markup from style is one way to structure a complex document but it's not the only way. However it's better than 'no way'. But don't cargo-cult it.
One good (very good) thing about React is that you can learn it very quickly - at least all the basics. This is also because it only covers the "view" part of a framework.
In the past I tried many times to use some spare time to learn Angular, but it always felt too overengineered to me (also because it does much more than React) and I always stopped at the beginning. With React, just a few hours were enough to appreciate the concepts and get started.
Then of course you can add Redux and that will take more time, but you can almost just as well use React components with any state manager you like.
In the past I tried many times to use some spare time to learn Angular, but it always felt too overengineered to me (also because it does much more than React) and I always stopped at the beginning. With React, just a few hours were enough to appreciate the concepts and get started.
Then of course you can add Redux and that will take more time, but you can almost just as well use React components with any state manager you like.
You should really watch pete hunts original talk:
https://www.youtube.com/watch?v=DgVS-zXgMTk
dude, what are you talking about. I've used Backbone, Angular, and React extensively, and React is a significantly better paradigm for building stateful UI's than any of those other frameworks. It's not just a matter of stylistic preference, it's better in an objective way the same way git is better for source control than FTPing files to a server.
When things align, and the abstraction suddenly makes everything simpler, you start to see the wisdom of it. It's less about "proponents," more about people who understand it and how it affects the reality of frontend engineering.
mocha, ava, expect, chai, painless... honestly what the fuck is this. I'm not a javascript developer - is the ecosystem really so fragmented? What a nightmare.
fragmented, yes, but also amazingly thriving.
There is no one standard choice for anything (except possibly React and Redux as the author says). You get to choose your own stack, how you like it.
Yes, it's more effort to get something you like. But you end up with something you like more.
There is no one standard choice for anything (except possibly React and Redux as the author says). You get to choose your own stack, how you like it.
Yes, it's more effort to get something you like. But you end up with something you like more.
It's not so bad. You just pick the most popular thing or use the recommendations in articles like this one. The ecosystem is harder to dive into than any other language I've used, but you only dive in fresh the first time (or after you've done something else for two years).
I was kinda hoping it was satire
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."
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."
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.
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.
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/
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/
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.
Getting a more MVC approach and still leveraging the react ecosystem is making me seriously consider trying react+mobx.
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 :)
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 :)
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.
lichess.org is a very busy application built around Mithril.
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
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
> 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?
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?
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."
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."
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.
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.
No, that's incorrect. It is any patent assertion against Facebook. Read it for yourself: https://github.com/facebook/react/blob/master/PATENTS
Wow never knew. That's a pretty huge barrier that more people should know about.....
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.
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'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.
This clause is awesome. Software patents are awful and this clause reduces the chances of patent lawsuits.
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).
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).
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.
Your "obvious" problem is based on the premise that whoever has the most money will win a lawsuit in the US. In that case, almost no-one using React needs to worry about this, because either Facebook is going to come after them and they will lose but that could happen regardless of how they act, or Facebook is going to decide they don't want to come after them and it doesn't matter.
This. I get that there's a few corporates that might have a patent portfolio they'd conceivably want to enforce against Facebook. But for the rest of humanity this is just a non-argument. If FB want to pick a fight with you, you're in a fight whether you use React or not.
It's just that with using react you leave your castles gate wide open.
But again, how is React any different in this respect to any other library or, for that matter, anything you develop in-house? Most of those libraries and anything you build in-house don't come with patent grants at all, and even if one other party grants you rights you still don't know whether some third party might also have a claim against you.
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.
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.
if you have patents you want to enforce, yes. But I think most software folk kinda assume that if you're the kind of douche that enforces software patents then you deserve everything coming to you...
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.
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.
Lodash v4 has its FP module included with it: require('lodash/fp') for immutable, auto-curried, iteratee-first, data-last method modules.
> 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.
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.
Ramda really is awesome.
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.
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.
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.
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 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.
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).
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).
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.
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.
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.
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.
Come on, Ember is so 2015 ...
Not sure if sarcasm or serious, but this sums up everything that is wrong with the Javascript community succinctly
I'd place a small bet on the former, but I wouldn't go all in. I agree with you - those javascript folks are more ADHD than me. And that's saying a lot.
Good point
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.
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.
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.
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.
That's just considered good practice. React brings nothing new to separation of concerns. In fact, it works against it.
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.
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.
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.
You can write your own "templating library" in about 20 lines of regular boring ol' JS
With compile-time error checking of expressions that insert dynamic content into the template? With support for intellisense and refactoring?
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.
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"
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.
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.
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 :-)
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 :-)
Yeah, this time it's different ...
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.
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.
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
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.
;permanently damaged...
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?
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?
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.
- 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.
"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.
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.
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.
Well, I thought they were neat before at least.
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.
"I don't get paid to write blog posts defending Angular, so I don't bother."
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.
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.
That's really interesting to know. I didn't read those blog posts back in the day, so I never realized how much history has repeated itself. There's a lesson to be learned here.
> While other people are busy writing blog posts, I've been shipping successful projects with Angular.
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'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.
You're entirely correct about the form of my argument being weak. Too busy shipping code to make a more coherent argument. :P
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 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.
This !!!!
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".
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...
[1] https://www.google.com/trends/explore#q=angularjs%2C%20react... [2]https://www.google.com/trends/explore#geo=807&cmpt=q&q=angul...
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').
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.)
(Put another way: hype, even valid hype, can fall victim to an echo chamber.)
"state of the art" is the keyword in the title.
It does mean bleeding edge, most hyped, etc...
It does mean bleeding edge, most hyped, etc...
Right. My point is more that the relative importance of using 'state of the art' technologies is overhyped on sites like HN, and that its role in the overall zeitgeist of computing is not as large as HN would have you believe.
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.
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.
Out of curiosity, what's wrong with backbone?
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.
Yeah, I use Backbone with Marionette on a project that's a few years old ( demo.enterprisejazz.com ). The "freedom to the implementer" part is very important to someone like me.
I don't think it would be productive to switch to something new even if that new thing was better.
I don't think it would be productive to switch to something new even if that new thing was better.
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.
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.
AMEN
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.
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.
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.
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.
Using Polymer(...) instead of document.registerElement(...) means that for anyone to re-use a component I build, they will need Polymer as a dependency. There will likely be more web component based libraries popping up, so then I'm going to need to download half a dozen identical libraries to use different components for my site? Then there's hacked components like React that don't even use the web components spec...
Yes, to use any component you will need that component's dependencies. That's just true of any software component. The Polymer() call has nothing to do with it, as in the end it just calls document.registerElement(). Raw elements that call into a template library in attachedCallback() will depend on that template library.
> 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.
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.
The custom element polyfill is 2KB gzipped. All browsers are on board with supporting it. No, polyfills are not akin to frameworks, and yes, I am building a large SPA using just custom elements (no framework) and it's amazing.
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.
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.
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.
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.
[deleted]
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.
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.
He did put a disclaimer at the bottom to use only what you need.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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...
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...
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?
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?
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?
Am I just missing something obvious?
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.
Go to terminal
ember new app
ember server
start writing code.
> 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.
> 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.
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.
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.
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.
If the hammer and nails were actually better, then fine. But there's nothing actually wrong with $.ajax, that I can tell.
Why would you need the workshop if you're not going to use any of it except one thing?
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.
I'd happily include a 9kb (unminified) polyfill and work off the assumption that I can remove it a few years down the road.
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.
$.Ajax is awesome and while XMLHttpRequest is awkward it's pretty straight forward.
If that's all you're after, I'd suggest something like Zepto win only the Ajax module: http://zeptojs.com
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?
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.
Remember last year when $.ajax wasn't legacy? Those were good times.
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.
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.
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?
So I'm unsure what kind of complexity you're adding by using it. Mental? Spiritual? Metaphysical?
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.
> 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
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
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).
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).
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 :/
Out of curiosity, what tools are you referring to that are nicer on ES6 and not applicable to LS? Could you give examples?
all the auto-complete stuff in atom.
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.
Can we all agree that State of the Art JavaScript in 2016 is a mess?
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.
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.
[deleted]
Just as messy as a supermarket for having lots of options for chips, booze or milk.
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.
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.
> 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.
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.
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.
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.
> 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.
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.
Bingo. And that, IMO, will be it. The problem right now is that people have no choice. They can use compiled to JavaScript languages, but they're ALL leaky abstractions.
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.
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.
Y but you will have to support JS for 10+ years regardless
Maybe not. There's a WebAssembly polyfill for browsers which don't yet (or never will) support WebAssembly: https://github.com/WebAssembly/polyfill-prototype-1
And the load times are still good: https://github.com/WebAssembly/design/blob/master/FAQ.md#can...
And the load times are still good: https://github.com/WebAssembly/design/blob/master/FAQ.md#can...
> 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.
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.
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...
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?
One difference though is that I've read Relay and GraphQL will eventually win out over Redux. Thoughts?
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...
[1]: https://mobile.twitter.com/dan_abramov/status/69755646131300...
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.
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.
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.
Meteor is so February 2016
Meteor's concept of hot patching deployed, running applications in users browsers is _amazing_.
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/
[1] http://nodaljs.com/
[2] https://medium.com/@keithwhor/realtime-doesn-t-belong-everyw...
[3] http://graphql.nodaljs.com/
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.
I think something released as long ago as January at this point is probably obsolete. :)
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.
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
Superagent has flaws. It doesn't support promises out of the box unfortunately :(
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.
>> "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.
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.
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.
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.
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.
ng2 will work with native script: http://angularjs.blogspot.de/2015/12/building-mobile-apps-wi...
Thank you, I will check this out! I hadn't considered a NativeScript route.
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.
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.
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.
> 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.
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.
[deleted]
Not even a mention of ClojureScript? :(
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.
I do really wish JS had native immutables with structural sharing, though.
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.
- 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.
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:
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!
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!
Ejecta lets you use Canvas+JS without the browser – at least on iOS. http://impactjs.com/ejecta
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.
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.
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
You can check here with this tutorial, how easy to write a complex application with Ember.js: http://yoember.com
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.
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.
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.)
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?
I don't get the whole React love? I always learnt not to mix view and business logic? React does this?
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.
The article mentions https://github.com/petehunt/react-howto. Its a damn good place to start.
I just took a look, really good article.
Just wanted to mention VueJS as an option on the front-end for those looking for a simple JS library with components.
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/
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/
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
- 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
Why is eslint considered better than jshint+jscs? jscs also supports auto-fixing, which is pretty dope.
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.
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.
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.
ESLint catches more errors.
eslint is great. Through plugins it supports ES6, jsx, etc. Also, automatic code fixing.
[deleted]
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.
No mention of SystemJS/JSPM?
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.
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.
In contrast, I have had extremely good experience using Webpack, and my app uses dozens and dozens of modules.
I've never run across this, or indeed, heard of anyone have experienced this before. More details? I'm honestly curious.
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...
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...
Yeah the line of thinking seems to be that everything else is broken, not webpack. And the module maintainers say "well it works with everything else except Webpack so webpack is broken, they should fix it." Seriously crap situation.
But people should code for Webpack or JSPM or require JS or whatever. A good solution should just work no matter how the lib was coded, if it doesn't then the solution isn't worth the investment.
One of many examples
http://andrewhfarmer.com/aws-sdk-with-webpack/
Search google for webpack incompatible
http://andrewhfarmer.com/aws-sdk-with-webpack/
Search google for webpack incompatible
Thanks for the example.
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.
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 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.
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.
Most people don't need these things. And more and more companies have devops and infrastructure teams that can deal with that.
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.
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.
I'd wager a bet that most people using JS today are nowhere close to having devops and infrastructure teams, but are still single people in their bedrooms copying and pasting stuff from Stack Overflow trying to make their online flower shops work.
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.
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.
The reality is that these tools, eventually, are used by businesses trying to build stuff efficiently.
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.
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 feel like if you are trying to make your online flower shop work, you probably shouldn't go near any where near any of these libraries. I think they are for experts who are working on large projects, probably 30,000+ lines. For the casual developer, use a script tag and go sell some flowers. I love that you can do that with Javascrpt, it's really easy to just write some code, so many fewer things to worry about for the beginner/intermediate than languages like Java and you can be so much more productive at the non-expert level.
Exactly, or better yet just use a saas ecommerce / blog /cms software package which gives you a lot of customizability without any programming like wordpress, wix, etc.
It took me a while, but I'm now a big fan of React, Webpack, Babel, etc. That said, I had to make a little project yesterday, and I through 5 script tags on it, on of which was jQuery, and everything was fine. All of these new tools don't stop you from using what worked 3 years ago. I don't think allowing for more complicated set ups means it's less democratic. It just makes certain projects available to single developers, that would have in the past required a large team.
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.
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.
Agree we definitely need a stack that integrates all the best of breed tools for this stuff. There's some good boilerplates out there, which almost gets there, but it's not quite the same. I've considered building one. I think it would be especially interesting if it supported server side rendering out of the box and tightly integrated with aws lambda, aws api gateway, and the serverless framework.
can you give some examples, this article made me consider if I should rewrite my pretty developed gulp setup as webpack
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.
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).
I feel dumb for not using React. Damn, I even feel I'm living in sin.
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)?
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.
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
Recommend: https://egghead.io/series/getting-started-with-redux
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
https://github.com/davezuko/react-redux-starter-kit and https://github.com/erikras/react-redux-universal-hot-example
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
[1] https://github.com/scottwoodall/django-react-template
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
the whole function composition has a clean feeling and LS removes a lot of cruft
Regarding CSS I recommend tachyons [0] over css-modules.
[0] http://tachyons.io/
[0] http://tachyons.io/
I tried to like typescript however so far failed, don't feel like it though everyone else seems are applauding it.
It's not so bad. You just pick the most popular thing or use the recommendations in articles like this one.
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.
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.
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
No mention of WebSockets...
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').
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.
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?
[deleted]
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.
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.
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.
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 :-)
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 :-)
If I may make a recommendation: check out ClojureScript with reagent and re-frame when you feel you've achieved what you set out to in Elm. While Elm nailed the essence of FRP, ClojureScript really nails the experience I was looking for in ways Elm can not.
While it doesn't have the gradual typing and fantastic compiler messages, it is also functional and immutable. But to my view it has all around better tooling, very simple FFI (either reference JS already on the page transparently or pull in JS formally via extern definition files similar to TypeScript typings), optional typing via core.typed, sourcemaps with a native debugger, and a node-like full stack synergy through Clojure but with all the power of the JVM.
You definitely lose some confidence at run time due to the dynamic typing, but on the whole I think the gains far exceed that. At least for me it's a package that is very hard to beat.
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.
Relay beats Redux any day
https://gist.github.com/idibidiart/49a095b6bc528638f34f
https://gist.github.com/idibidiart/49a095b6bc528638f34f
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).
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
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
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 :)
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 :)
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.
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.