Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

State of the Art JavaScript in 2016

medium.com

Post reply on HN
Print view View original

291–300 of 306 posts

Re: State of the Art JavaScript in 2016

#291

Post by [deleted] »

iffe_closure wrote: post #249
mbrock wrote: post #181

Earlier quoted context omitted.

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

[deleted]

Re: State of the Art JavaScript in 2016

#292

Post by hjek »

cetra3 wrote: post #136
treenyc wrote: post #84

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…

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 ( ht…

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/

Re: State of the Art JavaScript in 2016

#293

Post by georgefrick »

ericflo wrote: post #142
georgefrick wrote: post #130

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 startin…

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 s…

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

Re: State of the Art JavaScript in 2016

#294

Post by georgefrick »

akamaka wrote: post #176
CalRobert wrote: post #138

Earlier quoted context omitted.

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.

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.

Re: State of the Art JavaScript in 2016

#295

Post by georgefrick »

ChrisDutrow wrote: post #159
georgefrick wrote: post #130

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 startin…

Out of curiosity, what's wrong with backbone?

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.

Re: State of the Art JavaScript in 2016

#297

Post by akamaka »

georgefrick wrote: post #294
akamaka wrote: post #176

Earlier quoted context omitted.

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 chang…

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.

Re: State of the Art JavaScript in 2016

#298

Post by STRML »

dinkumthinkum wrote: post #74
STRML wrote: post #18

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…

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, re…

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.

Re: State of the Art JavaScript in 2016

#299

Post by tobltobs »

davidjnelson wrote: post #272
tobltobs wrote: post #66

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.

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 ap…

Yeah, this time it's different ...

Re: State of the Art JavaScript in 2016

#300

Post by wainstead »

pkrumins wrote: post #114

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…

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

Post reply on HN