Hacker News new | past | comments | ask | show | jobs | submit | page 2 login
State of the Art JavaScript in 2016 (medium.com)
550 points by achairapart on Mar 11, 2016 | hide | past | web | favorite | 297 comments



No mention of SystemJS/JSPM?


I found a mention in the comment section (I believe by the author of the article), which said it didn't work all that well for them.


I find lots of modules that won't build with Webpack and a very solid chunk of my available development time is spent trying to diagnose and fix problems caused by modules that won't build under Webpack. I recommend against it.


In contrast, I have had extremely good experience using Webpack, and my app uses dozens and dozens of modules.


I've never run across this, or indeed, heard of anyone have experienced this before. More details? I'm honestly curious.


It happens all the time because most UMD implementations are broken and make incorrect assumptions, so you often have to follow the "Fix broken modules" steps on https://webpack.github.io/docs/shimming-modules.html

And if your package depends on a broken module, you're essentially SoL unless you make assumptions about the path NPM will install stuff and configure webpack to fix -that- one.

That's more a problem with the state of broken UMD modules than Webpack itself though, but I've considered configuring webpack to ignore all AMD syntax quite a few times...


Yeah the line of thinking seems to be that everything else is broken, not webpack. And the module maintainers say "well it works with everything else except Webpack so webpack is broken, they should fix it." Seriously crap situation.


But people should code for Webpack or JSPM or require JS or whatever. A good solution should just work no matter how the lib was coded, if it doesn't then the solution isn't worth the investment.


One of many examples

http://andrewhfarmer.com/aws-sdk-with-webpack/

Search google for webpack incompatible


Thanks for the example.


If you mean old jQuery plugins or libraries that aren't CommonJS compatable, Webpack even has your back on that via its various plugins.

I was able to take an extremely large node-incompatible app and "webpackify" it through the tooling in a way that would have been impossible any other way.

Highly disagree.


I'm trying to program an application, not Webpack. If there are plugins that solve some problems then why aren't they part of the default config of webpack?

I'm not programming for the fun of programming build tools, I just want the damn thing to work. Zero interest in working out how to make webpack work. This is the problem with javascript build tools - they think I care enbough to want to work out how to configure them. I just want the module that I need to function.


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 head, no matter their skill and experience level. You could almost mash the keyboard until it worked.

For me, this is a democratizing quality which is fundamental to the spirit of the web, and I would be more than happy to give up generators and class keywords for it.

I've recently spent over six hours trying to build and use a JS library, fighting with package managers, build systems and transpilers, whereas earlier all I would have need to do was download a file and include a <script> tag. We're not moving in the right direction.


The reality is that these tools, eventually, are used by businesses trying to build stuff efficiently.

If we were to have a hackathon, and I could use the stack I have at work (which contains some of these tools, plus our own secret sauce), I'll trash anyone who's using script tags on a page.

Things like webpack, commonjs, npm, etc, are ways to bring that to everyone.

If you're making a little one off or a small project, then anything you're comfortable with will work. Heck, go and use a tool just because you like the logo. It won't make much of a difference.


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 the beginner/intermediate than languages like Java and you can be so much more productive at the non-expert level.


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.


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.


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.


can you give some examples, this article made me consider if I should rewrite my pretty developed gulp setup as webpack


Before you do that, just try to build all the modules you use with webpack into a simple barebones app and see if your app works.


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


I feel dumb for not using React. Damn, I even feel I'm living in sin.


What's the current thinking on React? Is it primarily indicated for SPAs? Or should one us it throughout a web app (even for pages that don't qualify as their own SPA)?


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.


My co-workers put together https://github.com/CodingZeal/react-boilerplate but the documentation is a bit lacking at the moment, you really need to know a lot about redux to use it.

Recommend: https://egghead.io/series/getting-started-with-redux



It's Django flavored but take a look at this repo[1]. Disclaimer, I'm the author. It wouldn't be too much effort to abstract out the front-end and make it back-end agnostic.

[1] https://github.com/scottwoodall/django-react-template


I would use something linke cyclejs with LiveScript, if I start something new.

the whole function composition has a clean feeling and LS removes a lot of cruft


Regarding CSS I recommend tachyons [0] over css-modules.

[0] http://tachyons.io/


I tried to like typescript however so far failed, don't feel like it though everyone else seems are applauding it.


It's not so bad. You just pick the most popular thing or use the recommendations in articles like this one.


Here's a short story.

I used to do a little bit of JavaScript. Initially it was easy. Functions! Easy enough. Vars! Cool. I get all of that. I wrote some code, worked. Wrote some more and it started not working as expected. I was curious why. I started reading into it and discovered interesting concepts like "hoisting".

Then a friend of mine told me about Clojure/ClojureScript. I never understood hoisting.


I wrote an app generator (actively maintained) that actually follows many of these recommendations if anyone is interested: https://www.npmjs.com/package/generator-enigma


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.


WebSockets are one of the most underestimated value-adds in modern browsers. Pub-sub. Real time. Ease of data transfer and client-to-server synchronization. I can't think of a modern project that wouldn't benefit from sockets, unless the site is literally 100% static. But then, why use most of the stack outlined in the article?


I have found using Elm a real joy, albeit for hobby projects. I do hope pure functional languages become state of the art by 2026.


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.

That said, Elm can be difficult to use today. The foreign function interface is not all that great of an experience. There is a lot of friction in just defining, serializing and deserializing JSON objects. You wind up writing a lot of code you wish you didn't have too. Their great time traveling, hot reloading debugger doesn't actually hot reload anymore. And there is no real back end language synergy to speak of at the moment. Many are looking toward Elixir and Phoenix for support instead of more language-similar Haskell options like Yesod and Snap.

The competing PureScript, GHCJS, Websharper and FunScript alternatives also complicate the landscape that Elm plays in greatly.


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

I feel FP will remain a hobby though and the best I can hope for is to convince .NET colleagues to make immutable classes, use code contracts to avoid null problems, and generally try to minimize state and maybe use Rx. Even F# would be too much of a push for most .NET shops. I have a mortgage and fixing bugs caused by ridiculous state and null references in .NET code pays it and then some :-)


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.



Until there's no 1:1 relationship between the client and the server APIs, or you don't control all parts of the server... Relay is amazing, but it makes assumptions about the server (its kind of the point).


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 tags on your own, spend more time testing, etc...well, that's up to you :)


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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: