I feel dumb for not using React. Damn, I even feel I'm living in sin.
State of the Art JavaScript in 2016
241–250 of 306 posts
Re: State of the Art JavaScript in 2016
#242[deleted]
Re: State of the Art JavaScript in 2016
#243JavaScript 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).
Re: State of the Art JavaScript in 2016
#244I'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 startin…
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.
Re: State of the Art JavaScript in 2016
#245Ok, 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…
+1000
Re: State of the Art JavaScript in 2016
#246Earlier quoted context omitted.
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.
Re: State of the Art JavaScript in 2016
#247I'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?
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.
Re: State of the Art JavaScript in 2016
#248Earlier quoted context omitted.
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 really watch pete hunts original talk:
https://www.youtube.com/watch?v=DgVS-zXgMTk
Re: State of the Art JavaScript in 2016
#249Ok, 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…
> 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…
> 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.
Re: State of the Art JavaScript in 2016
#250Earlier quoted context omitted.
Flow has pretty good support for tagged unions like this which act like ADTs: 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.