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

271–280 of 306 posts

Re: State of the Art JavaScript in 2016

#271

Post by JDDunn9 »

spankalee wrote: post #259
JDDunn9 wrote: post #139

Earlier quoted context omitted.

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

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

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

Re: State of the Art JavaScript in 2016

#272

Post by davidjnelson »

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 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 :-)

Re: State of the Art JavaScript in 2016

#273

Post by davidjnelson »

seanp2k2 wrote: post #134
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.

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.

Re: State of the Art JavaScript in 2016

#274

Post by davidjnelson »

Mc_Big_G wrote: post #59

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.

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.

Re: State of the Art JavaScript in 2016

#275

Post by davidjnelson »

vmware505 wrote: post #269

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…

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.

Re: State of the Art JavaScript in 2016

#276

Post by dcposch »

danmaz74 wrote: post #202
andybak wrote: post #195

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

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…

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

Re: State of the Art JavaScript in 2016

#277

Post by davidjnelson »

drumttocs8 wrote: post #81

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's concept of hot patching deployed, running applications in users browsers is _amazing_.

Re: State of the Art JavaScript in 2016

#278

Post by davidjnelson »

ChrisDutrow wrote: post #177
janfoeh wrote: post #119

Earlier quoted context omitted.

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…

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…

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.

Re: State of the Art JavaScript in 2016

#279

Post by davidjnelson »

samcodes wrote: post #151
janfoeh wrote: post #119

Earlier quoted context omitted.

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

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.

Re: State of the Art JavaScript in 2016

#280

Post by davidjnelson »

melvinmt wrote: post #126

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.

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

Post reply on HN