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

281–290 of 306 posts

Re: State of the Art JavaScript in 2016

#281

Post by davidjnelson »

andybak wrote: post #196
arxpoetica wrote: post #128

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.

Re: State of the Art JavaScript in 2016

#282

Post by davidjnelson »

shados wrote: post #229
tomc1985 wrote: post #97

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

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…

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.

Re: State of the Art JavaScript in 2016

#283

Post by spankalee »

JDDunn9 wrote: post #271
spankalee wrote: post #259

Earlier quoted context omitted.

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

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.

Re: State of the Art JavaScript in 2016

#284

Post by Lazare »

dcposch wrote: post #276
danmaz74 wrote: post #202

Earlier quoted context omitted.

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

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

Re: State of the Art JavaScript in 2016

#285

Post by vehementi »

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…

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

Re: State of the Art JavaScript in 2016

#286

Post by kayoone »

t1amat wrote: post #234
kayoone wrote: post #178

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

ng2 will work with native script: http://angularjs.blogspot.de/2015/12/building-mobile-apps-wi...

Re: State of the Art JavaScript in 2016

#287

Post by Brakenshire »

narrator wrote: post #145
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…

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

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

Re: State of the Art JavaScript in 2016

#288

Post by oever »

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.

Re: State of the Art JavaScript in 2016

#289

Post by t1amat »

kayoone wrote: post #286
t1amat wrote: post #234

Earlier quoted context omitted.

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

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.

Re: State of the Art JavaScript in 2016

#290

Post by t1amat »

bbcbasic wrote: post #264
t1amat wrote: post #230

Earlier quoted context omitted.

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

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

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.

Post reply on HN