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

151–160 of 306 posts

Re: State of the Art JavaScript in 2016

#151

Post by samcodes »

janfoeh wrote: post #119
shados wrote: post #101

Earlier quoted context omitted.

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.

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

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.

Re: State of the Art JavaScript in 2016

#152

Post by dkarapetyan »

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.

Re: State of the Art JavaScript in 2016

#153

Post by marcus_holmes »

bottled_poe wrote: post #94
Lazare wrote: post #15

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

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.

Re: State of the Art JavaScript in 2016

#155

Post by marcus_holmes »

Silhouette wrote: post #108
tobltobs wrote: post #63

Earlier quoted context omitted.

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.

Re: State of the Art JavaScript in 2016

#156

Post by clouddrover »

qaq wrote: post #129
clouddrover wrote: post #118

Earlier quoted context omitted.

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

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

Re: State of the Art JavaScript in 2016

#157

Post by BillyParadise »

jjawssd wrote: post #133
tobltobs wrote: post #71

Earlier quoted context omitted.

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.

Re: State of the Art JavaScript in 2016

#158

Post by f1hybrid »

natrius wrote: post #113
finishingmove wrote: post #31

Earlier quoted context omitted.

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.

Re: State of the Art JavaScript in 2016

#159

Post by ChrisDutrow »

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?

Re: State of the Art JavaScript in 2016

#160

Post by tarsinge »

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…

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
Post reply on HN