21 ms·

State of the Art JavaScript in 2016

• hoodoof 11y ago
  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.
  • bryanrasmussen 11y ago
    can you give some examples, this article made me consider if I should rewrite my pretty developed gulp setup as webpack
    • hoodoof 11y ago
      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.
  • williamstein 11y ago
    In contrast, I have had extremely good experience using Webpack, and my app uses dozens and dozens of modules.
  • Lazare 11y ago
    I've never run across this, or indeed, heard of anyone have experienced this before. More details? I'm honestly curious.
    • hoodoof 11y ago
      One of many examples http://andrewhfarmer.com/aws-sdk-with-webpack/ http://andrewhfarmer.com/aws-sdk-with-webpack/ Search google for webpack incompatible
      • Lazare 11y ago
        Thanks for the example.
    • shados 11y ago
      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 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...
      • hoodoof 11y ago
        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.
        • spriggan3 11y ago
          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.
  • cnp 11y ago
    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.
    • hoodoof 11y ago
      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.
      • shados 11y ago
        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.
        • janfoeh 11y ago
          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.
• deleted 11y ago
  [deleted]
• choward 11y ago
  No mention of SystemJS/JSPM?
  • finishingmove 11y ago
    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.
• fleshweasel 11y ago
  I strongly disagree about TypeScript-- I think it's a huge boon to productivity. TypeScript has has union types i.e. "number | string" which are similar to algebraic data types. TypeScript also has optional interface members and function parameters by putting ? at the end of the name, i.e. "foo?: number". Static types allow for much, much better tooling, particularly autocomplete and the ability to check whether your code is valid on some basic levels. I consider avoiding it to be a big waste of time. I've had a good experience getting the definitions files going for the libraries I use. I also disagree with the statement that TypeScript is making JavaScript "like C# or Java". TypeScript lets you opt out of type checking all you want with minimal difficulty. It also will by default always emit JavaScript even if it detects type errors.
  • finishingmove 11y ago
    Thanks for posting your thoughts. I was leaning towards TypeScript myself (as opposed to ES6) for an Angular project that will be migrated to version 2.0. Angular 2 was actually written in TypeScript if I am not mistaken, and it's one of the three say, "supported" ways of writing A2 apps (along with ES5 and Dart).
  • wozer 11y ago
    Agree. Typescript doesn't have real algebraic data types becauses at the end of the day, Typescript is just a statically-typed version of Javascript. And Javascript doesn't have adts. For me, the biggest advantage of static typing is that code is much more self-documenting. Also, refactoring becomes much easier.
    • spicyj 11y ago
      For comparison, Flow supports tagged unions like this: http://flowtype.org/blog/2015/07/03/Disjoint-Unions.html http://flowtype.org/blog/2015/07/03/Disjoint-Unions.html
      • Arnavion 11y ago
        TS has string types starting from 1.8, although they can't be used for narrowing down the type yet in the way that Flow can. http://bit.ly/1LhA5id http://bit.ly/1LhA5id
• hokkos 11y ago
  I use all those tools daily, but this article feel patronising to me, I would feel inconfortable to say that whatever I use is the state of the art. Also the author is totally ignorant and bigoted about typescript.
• Lazare 11y ago
  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 bit too strongly in favour of `mocha`; I don't think `ava` should have been some easily dismissed, and I've recently run across a pretty nice framework called `painless`. And even if you do use `mocha`, I find `expect` to be a better assertion library than `chai`. I think a better answer here might be "use whatever works for you, so long as its not Jest". (The shoutout to `enzyme` was on point though; great library if you need to test React components.)
  • finishingmove 11y ago
    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...
    • calinet6 11y ago
      When things align, and the abstraction suddenly makes everything simpler, you start to see the wisdom of it. It's less about "proponents," more about people who understand it and how it affects the reality of frontend engineering.
    • natrius 11y ago
      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.
      • 11y ago
• interlocutor 11y ago
  The problem with React is its patent rider. React.js comes with a BSD license, but has a patent rider that gives you a license to React's patents. This sounds like a good thing, right? But this rider has a "strong retaliation clause" which says that if you make any sort of patent claim against Facebook this patent license automatically terminates. Which means Facebook can now sue you for patent infringement for using React. You may think this is no worse than not having a patent rider at all. But that's not the case. If there is no patent rider then there is an implicit grant which cannot be revoked. If you work for a software company and your company has patents then keep in mind that by using React you are giving Facebook a free license to your entire patent portfolio. More info on weak vs strong retaliation clauses: http://www.rosenlaw.com/lj9.htm http://www.rosenlaw.com/lj9.htm
  • jwingy 11y ago
    Wow never knew. That's a pretty huge barrier that more people should know about.....
  • dsp1234 11y ago
    you are giving Facebook a free license to your entire patent portfolio. It's bad, but it's not quite that bad. Theoretically, you could stop using React, then start the patent litigation. Then Facebook could not sue you for React because at the time litigation started you were not using the license. But that's definitely a high barrier to jump if you've built up react as a core part of web and/or native applications.
  • Lazare 11y ago
    > You may think this is no worse than not having a patent rider at all. But that's not the case. If there is no patent rider then there is an implicit grant which cannot be revoked. I believe a couple of lawyers have suggested that this could, maybe, arguably be true. However, no court has ever ruled as such, and the consensus among IP lawyers is that it's an unlikely outcome. If you're worried about potential patent lawsuits, I would NOT suggest relying on the vague hope that someday a court might read an implicit patent grant into the BSD license, especially when you'll be facing off with Facebook's lawyers. Or do you have some citation for the "implicit patent grant"? In particular, a court decision finding one?
• STRML 11y ago
  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.22 of Flow (released just a week ago) brought massive speed improvements that bring it decently on par with any other linter. I found I could finally re-enable it in Sublime Text after this release. It catches all kinds of things linters won't, and the upstart cost is relatively low. On the other hand, TS has the benefit of years of type files available for almost any library; don't underestimate how great that is. Using React has been great as well. It's what I wish Backbone views had been from the beginning. We certainly aren't wanting for choice. Between the dozens of Flux implementations, React alternatives like Mithril, interesting languages like ClojureScript (with Om if you want to keep using React) or Elm, multiple typing systems, and even WASM on the horizon - web development is an exciting field. It's also overwhelming, and I say that as someone who keeps his head in it over 12 hours a day. --- Re: CSS, the story still feels incomplete. I want a way to write a library that will effortlessly import its own styles, so consumers can simply import the component and go to town. Most solutions are severely limited, slow, or both, mostly because they rely on inline styles. Nothing's wrong with inline styles, until you want to do :hover, :active, pseudo elements or the like. See the React material-ui project for a very real example of how this can go wrong - note how every component has a dozen or more extension points for styles. I built a project with this recently and it was intensely frustrating that I couldn't simply add some CSS to the app to fix styles across the board - I needed to keep a giant file of extensions and be sure to apply them every time I used a component. And, of course, component authors can't possibly anticipate every possible use, so some of my selectors were ugly "div > div > ul > li:first-child" monstrosities. CSJS (https://github.com/rtsao/csjs https://github.com/rtsao/csjs) is one of the few solutions I like. I would be very happy to see it, or something like it, go mainstream.
  • nzonbi 11y ago
    Polymer (https://www.polymer-project.org https://www.polymer-project.org) is a solution for the styles problem. You can pack each component with its own styles, complete with all its functionality. This allows for a very clean separation of concerns among components. Better than all other libraries that I have tried. I hope that web components take off, because it is a great way to build apps. Currently they are only supported in Chrome. Moving data between components in Polymer, can be done with data binding. The bad thing is that it could get messy for complex applications. Is not terribly bad, but it could be better. What Polymer needs is a better way to move data between components. If that problem is solved, Polymer would be an excellent alternative to create any kind of apps.
• marknadal 11y ago
  We all have our opinions and I would say take this article with a huge grain of salt (as well as my comment). State of the art javascript should still be considered a browser + editor + files. There is no need to overcomplicate things, and unfortunately Webpack and Babel do. It is terrifying to see javascript turn into the new Java - build steps and compile steps and configuration and everything you don't need except for distraction from getting real work done. Build your app first. Then when you are unhappy, see if these tools make your life easier. But play with them first, don't make upfront commitments.
  • ams6110 11y ago
    You're downvoted but I for one agree. KISS. If you really NEED all that stuff, fine, but it's quite clear why modern web pages are so bloated and slow on anything but current-gen hardware and fast networks.
    • deleted 11y ago
      [deleted]
    • baddox 11y ago
      I doubt this article offers any explanation of the bloat observed in many modern web pages. I suspect most web pages built using stacks like this will actually tend to be fairly economical on the client.
  • arvinsim 11y ago
    He did put a disclaimer at the bottom to use only what you need.
  • dinkumthinkum 11y ago
    Your view has merit but I think it is a minority one. Actually, I think the community is way beyond just webpack and babel. I think it's not exactly the "new Java," I think it's something we have not really see . It is kind of a stupendous over proliferation of many of these little kind of obscure projects. I saw a headline of an article the other day, something about "collections of microservices becoming the new monoliths" and it seems like that's what JS community is tending toward, an enormous amount combinations of these these frameworks/libraries/build tools/package managers. I guess the advantage of this style over traditional monoliths is there are more conferences to go to, I dunno.
• n0us 11y ago
  I would like to add that I've had an excellent experience with the Radium library for styles. Sass was a little better than CSS because you sort of get variables but being able to define styles in JS has fixed pretty much all of the remaining problems.
• jastanton 11y ago
  Wow, this is nearly our teams exact stack. One addition would be superagent instead of fetch. I really like Fetch, especially for react-native but superagent is just so simple and easy to use
  • amackera 11y ago
    Superagent has flaws. It doesn't support promises out of the box unfortunately :(
    • Can_Not 11y ago
      I don't think this is a problem, I expect to wrap my HTTP calls inside of promise factories anyways. Promises solve the issue of callback piramids, there's no issue with a single rogue, well contained callback.
• z3t4 11y ago
  I'm making web apps/clients in the browser, servers using node.js and desktop "native" apps using nw.js. All in vanilla JavaScript, and I love it. If you need additional functionality, there's always a module for it (npmjs.com) The interesting part is maybe that most apps look like this: <html><body><canvas id="canvas"></body></html> And the rest is JavaScript! It does seem a bit stupid to load the browser just for the canvas element though, so if someone know a better solution, please post!
  • phoboslab 11y ago
    Ejecta lets you use Canvas+JS without the browser – at least on iOS. http://impactjs.com/ejecta http://impactjs.com/ejecta
  • err4nt 11y ago
    How does it look on retina/hiDPI displays?
    • z3t4 11y ago
      I've never had the chance to use a hiDPI display. But it will probably be upscaled and look the same as on a normal screen. It would be an easy fix to increase the canvas context scale though.
• kmfrk 11y ago
  Why is eslint considered better than jshint+jscs? jscs also supports auto-fixing, which is pretty dope.
  • sotojuan 11y ago
    ESLint is extremely configurable and thus has a vibrant plugin ecosystem so I think that's why it has picked up a lot of hype.
  • dchest 11y ago
    ESLint catches more errors.
  • mariusasdf 11y ago
    eslint is great. Through plugins it supports ES6, jsx, etc. Also, automatic code fixing.
  • shados 11y ago
    eslint also has auto-fix support to some extent. I don't know how far JSCS pushes it though. The biggest thing is that whenever something new pops up, you can get an eslint plugin to lint it (eg: it took a wh ile for jshint to be able to take JSX or even just ES6 syntax, while ESLint got plugins for it pretty quick). I think (don't quote me) that eslint is starting to have pretty cool Flow hooks, too.
• acron0 11y ago
  Not even a mention of ClojureScript? :(
  • shados 11y ago
    ClojureScript is pretty fantastic, and Om had a lot of the ideas behind Redux before Redux (a bit like Elm). It's still a bit early to build a team revolving around FP though (it can be done, but you need a big company commitment in term of hiring practices, training people, etc). Consider React/Redux a gateway drug. Sprinkle in some Ramda, maybe even some Folktale...and then you're in a better spot to go. But starting with ClojureScript if you have a team not too familiar with the JS world is really rough. I do really wish JS had native immutables with structural sharing, though.
    • t1amat 11y ago
      I don't feel like the barrier to entry in ClojureScript is that deep. I think you will find it is awfully easy to pick up if you fall into one of the following categories: - You have experience with Lisp dialects (even better, Clojure specifically). In this case, you know the language semantics but not the application of in this domain. The core concepts are so simple, and there is so much material out there covering it, that picking this up should be easy. - You have experience with modern reactive architectures in any language and an understanding to structure application state atoms. In this case the concepts you learned will largely prevail and you will be left learning the language semantics. While Clojure has an enormous core library, you can do a lot with only a very rudimentary knowledge of the language. Also, what you aim for will probably make a difference. Reagent and the hiccup style is incredibly easy to pick up, and re-frame supplies a very nice state manager. Om and Om/Next are probably more difficult to pick up, and at least in the case of Om, probably not worth it now. Om/Next seems to be an attempt at replicating an entire React/Relay or Falcor/GraphQL stack in Clojure/ClojureScript, and at this point it is dubious what size of an application you need to develop to break even on the architecture and complexity costs.
• keithwhor 11y ago
  I'm a little bit bummed that the author seems to think there's "No API solution." Nodal [1] was released in early January to a great response, and I'd hope that more people are paying attention. Our most recent announcement was that we're focusing on being API-first [2]. We also have out-of-the-box GraphQL support [3]. [1] http://nodaljs.com/ http://nodaljs.com/ [2] https://medium.com/@keithwhor/realtime-doesn-t-belong-everywhere-build-scalable-api-services-in-node-js-with-nodal-10d0adfb66d https://medium.com/@keithwhor/realtime-doesn-t-belong-everyw... [3] http://graphql.nodaljs.com/ http://graphql.nodaljs.com/
  • shados 11y ago
    Don't be bummed :) The point was that there's no "obvious" solution. Something released in January needs a bit more time to become an obvious go-to. Doesn't mean it's not great or that it won't.
    • dinkumthinkum 11y ago
      I think something released as long ago as January at this point is probably obsolete. :)
• tonyle 11y ago
  Mainly used angular and node. Someone was telling me about ember.js, I wondered why I would use broccoli over browserify. 6 months later. Was comparing browserify vs webpack. 1 month later. Go to terminal ember new app ember server start writing code.
• lsdafjklsd 11y ago
  At work we've turned an ember-cli ember app into a react redux app in place using immutable.js and ramda for everything. It's been a huge boon. PS Ramda it eats lo-dash and its imperative API for lunch. It's for power users, everything curried, higher levels of abstractions. Pick it up and learn it, it'll make you a better programmer. Next stop Clojurescript. Om next is a library where you can get a feel for a Falcor + Relay stack in like 70 lines of code all without the specific tech bloat. David Nolen is a UI profit, just follow him.
  • shados 11y ago
    Ramda really is awesome.
  • pandler 11y ago
    > we've turned an ember-cli ember app into a react redux app in place using immutable.js and ramda for everything Would you mind elaborating what you mean by that? We also use Ember and I've been championing the use of Ramda. I'm curious how you fit immutable.js into Ember.
  • jdd 11y ago
    Lodash v4 has its FP module included with it: require('lodash/fp') for immutable, auto-curried, iteratee-first, data-last method modules.
• calebgilbert 11y ago
  In a development world that is already rife with planned obsolescence, the Javascript world is the shining jewel. Reminds me of trying to construct the killer Yu Gi Oh deck. By the time you get all the cool cards, paying a small fortune for them of course, a new ban list comes out, new decks come out, and you have to start all over again. Is the game improved through all of this? Maybe it is, maybe it isn't, but I would say that this question becomes beside the point for many players...
• Mc_Big_G 11y ago
  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.
  • tobltobs 11y ago
    Come on, Ember is so 2015 ...
    • jjawssd 11y ago
      Not sure if sarcasm or serious, but this sums up everything that is wrong with the Javascript community succinctly
      • BillyParadise 11y ago
        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.
        • jjawssd 11y ago
          Good point
  • hackerboos 11y ago
    What the author failed to mention is how much work it is to get all of these ad-hoc projects working together. Ember is a pretty cozy ecosystem in comparison. You get Babel, JSHint, npm and QUnit - out of the box. Most of which can be swapped out for your preferred libraries.
  • seanp2k2 11y ago
    This. My team is currently making a pretty big bet on the future of Ember, and so far it's been amazing (coming from Drupal + Rails templates with jQ everywhere). Back-ends are in Rails API. Works great with Ember and you don't have to make 47462685868 decisions to get started with a project, make all the tooling play nice, then teaching the rest of your team how it all works. We're currently in the process of establishing a "paved road" for CI/CD for Rails API back-end + Ember front-end apps. Ember CLI is also awesome, and Ember CLI Deploy is damn cool once you get it: http://ember-cli.com/ember-cli-deploy/docs/v0.4.x/lightning-approach-workflow/ http://ember-cli.com/ember-cli-deploy/docs/v0.4.x/lightning-... Deployments take tens of seconds. Roll-backs take single-digit seconds. Previewing not-active-but-uploaded versions of the UI is trivial. Everyone does the same exact thing when they deploy (or throw it on Jenkins for even more fun).
• alextgordon 11y ago
  > Unless you’re working on a legacy application or have 3rd party libraries that depend on it, there’s no reason to include it. That means you need to replace $.ajax. > I like to keep it simple and just use fetch. It’s promise based, it’s built in Firefox and Chrome, and it Just Works (tm). For other browsers, you’ll need to include a polyfill. I laughed. Is this satire? There's no reason to have X, therefore you need Y and Z to replace X. It just works.
  • jessep 11y ago
    Seems like it makes sense to me. Here's an analogous situation to jquery: X = a huge workshop with a million tools, a table saw, ladders, and yes, a hammer and some nails Y = some nails Z = a hammer You need to hammer stuff as part of your job. Yeah, if you get rid of X you need to replace it with Y and Z, but it still seems like simplifying to me, if you're replacing a whole room full of tools with just the tools you actually need.
    • alextgordon 11y ago
      The workshop is free to use (it's on Google CDN), but the hammer and nails cost money. Seems like a no brainer to use the workshop. If the hammer and nails were actually better, then fine. But there's nothing actually wrong with $.ajax, that I can tell.
      • Kiro 11y ago
        Why would you need the workshop if you're not going to use any of it except one thing?
  • hughes 11y ago
    Have you ever started a js app thinking you don't need jQuery? It usually goes great until you need to make a request. One look at `XMLHttpRequest` and suddenly including a 92kb (unminified) library starts to sound appealing. I'd happily include a 9kb (unminified) polyfill and work off the assumption that I can remove it a few years down the road.
• tobltobs 11y ago
  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.
  • seanp2k2 11y ago
    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"
    • davidjnelson 11y ago
      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.
  • davidjnelson 11y ago
    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 :-)
    • tobltobs 11y ago
• ausjke 11y ago
  I tried to like typescript however so far failed, don't feel like it though everyone else seems are applauding it.
• Kequc 11y ago
  A huge amount of this stuff is bloat, to me. It seems like this is a collection of libraries that largely were picked out of the problem that is javascript bloat today. Use typescript and just write it to do whatever you want it to do. You don't need React, or any of this stuff. Chai is good for testing. But as far as deploying a production application, there should be literally no dependencies. You don't need them. There is nothing today that typescript or even just raw javascript can't do perfectly fine on its own.
  • interlocutor 11y ago
    You still need some sort of templating library. You can use Handlebars or Mustache, but if you are using TypeScript there is now something better: https://github.com/wisercoder/uibuilder https://github.com/wisercoder/uibuilder UIBuilder is basically TypeScript's TSX file but without React's bloat. The whole UIBuilder is about 100 lines of code. The advantage over Mustache is compile-time error checking of expressions used in the template, and of course full Intellisense, Refactoring etc if you are using Visual Studio.
    • tomc1985 11y ago
      You can write your own "templating library" in about 20 lines of regular boring ol' JS
      • interlocutor 11y ago
        With compile-time error checking of expressions that insert dynamic content into the template? With support for intellisense and refactoring?
  • terda12 11y ago
    I disagree. I think React is a no brainer for any SPA. Try doing a full fledged SPA admin panel in pure javascript. It's madness. But with React you can separate everything else into components and it becomes clean and beautiful.
• achairapart 11y ago
  Can we all agree that State of the Art JavaScript in 2016 is a mess?
  • deleted 11y ago
    [deleted]
  • BinaryIdiot 11y ago
    It's always been a mess and the trend will likely continue :) Every few months there is a new, up and coming framework everyone is saying that's better than the last popular one. And it's written in a dialect of JavaScript that isn't supported in most places so it has to be transpired first. Good times /s Honestly when I'm going into a new project I use a handful of utility type libraries and that's it. You can still develop very quickly this way. The DOM is awkward but very easy to use. I'm not convinced you need a framework.
  • kowdermeister 11y ago
    Just as messy as a supermarket for having lots of options for chips, booze or milk.
• drumttocs8 11y ago
  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.
  • elchief 11y ago
    Meteor is so February 2016
  • davidjnelson 11y ago
    Meteor's concept of hot patching deployed, running applications in users browsers is _amazing_.
• treenyc 11y ago
  Why not mithril? https://lhorie.github.io/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 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 be compiled, but React's compiled code still has function calls for each virtual DOM element; Mithril templates compile into static Javascript data structures. Another difference is that Mithril, being an MVC framework, rather than a templating engine, provides an auto-redrawing system that is aware of network asynchrony and that can render views efficiently without cluttering application code with redraw calls, and without letting the developer unintentionally bleed out of the MVC pattern. Note also that, despite having a bigger scope, Mithril has a smaller file size than React."
  • shados 11y ago
    If you want the React semantic without the size, you can just use something like https://github.com/developit/preact https://github.com/developit/preact (which is like 3kb once deployed). You also don't need JSX if you don't want to. Using React without JSX and just aliasing the dom functions ends up looking almost the same. The reason behind React and Flux is because of pitfalls behind MVC...though the whole rational behind that is probably not fit for an hacker news reply :)
  • cetra3 11y ago
    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/ https://react-bootstrap.github.io/) and angular (https://angular-ui.github.io/bootstrap/ https://angular-ui.github.io/bootstrap/). But with mithril, the only bootstrap library I have found has not been updated in 2 years (https://github.com/eddyystop/mithril-components-bootstrap https://github.com/eddyystop/mithril-components-bootstrap). I really wish mithril had a bigger community around it, as when I used it for a few prototypes it was a pleasure to work with and fast as hell.
• b34r 11y ago
  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 https://www.npmjs.com/package/generator-enigma
• tomc1985 11y ago
  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
  • shados 11y ago
    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 :)
    • davidjnelson 11y ago
      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.
• raspasov 11y ago
  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.
• reedlaw 11y ago
  I agree that React, Webpack, et al. are great improvements compared to their predecessors. But do I really want to start an app in 2016 knowing that there may be even better tools in 2017? Most likely I would use these but what ails me is the thought that I might have to learn yet another tool and migrate. Why does the JavaScript ecosystem move so quickly? I get that browser technology is exciting and constantly improving. But why can't we settle on some well designed concepts and keep them well maintained? I hope React is it because I like it but it really depends on Facebook's commitment.
• increment_i 11y ago
  Whenever these kinds of JS commentaries pop up on HN nowadays, I notice two distinct camps of commenters emerge: Those who are obviously steeped in the JS scene and are delighted to argue the finer, more sophisticated points of it, and those who take their best look, step back, and criticize this convoluted house of cards - and of course proceed to be downvoted into the Stone Age as the latest casualty of HN censorship. My only observation of note I guess is the sheer marvel that all of this is nearly entirely supported by the Open Source community, and the amount of engineering effort being poured into the JS ecosystem at this point in time is nothing short of astounding. I can't wait to see where it goes in the next few years.
  • shados 11y ago
    We had a discussion about this in my last team. It really comes down to the JS community being divided in 2. You have the first group, of which most of us were part of at least at some point: developing in our language of choice and being "forced" to use JavaScript for some frontend stuff, in the same way we kind of have to use SQL in some form when hitting a database. That group generally wants to touch JS has little as possible then forget about it. Ideally making it as close to their language of choice as possible (similar to ORMs for database). Then there's the other side, people who are running away with it and pushing it as far as possible. That also comes with some problems (JS fatigue, millions of frameworks, etc). But generally, most comments will fall in one of the 2 categories.
    • clouddrover 11y ago
      > 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.
      • shados 11y ago
        Bingo. And that, IMO, will be it. The problem right now is that people have no choice. They can use compiled to JavaScript languages, but they're ALL leaky abstractions. Once people can use the tool they want instead of the tool they have to use, things will be a lot better. One thing about WebAssembly (and compile to JS languages have had that issue for a long time, and still do to some extent) is the tooling. If the debugger doesn't properly handle breakpoints in the original source (for real. Not the garbage that is sourcemaps that can't even properly map variable names), and if people developing in WebAssembly languages still have to think javascript, then it won't be much better.
• Niksko 11y ago
  I'm in the process of learning a JS stack at the moment, and I've come to almost an identical conclusion to this article about the packages and tools to use. One difference though is that I've read Relay and GraphQL will eventually win out over Redux. Thoughts?
  • t1amat 11y ago
    That Relay/GraphQL will "win" is very uncertain at this point. The solution is very interesting but only time and real world usage of it will tell in the long run. But you might be interested in this thread where the creator of Redux muses on a future convergence of Relay and Redux[1]. [1]: https://mobile.twitter.com/dan_abramov/status/697556461313007616 https://mobile.twitter.com/dan_abramov/status/69755646131300...
  • mparr4 11y ago
    It's not that simple. I can swap out Angular for React + Redux in my application without my backend knowing about it. The same is not true of React + Relay + GraphQL. It's a bigger, more involved decision that doesn't strike me as being particularly practical for an individual or a small team. Couple that with the fact that making a bigger, more involved decision is harder for bigger teams and it becomes apparent why it would be hard for Relay + GraphQL to "win" over Redux.
• pkrumins 11y ago
  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 and the ecosystem is getting extremely fragmented. Instead of just writing your application, you're in despair trying to choose the right tools, panicking about not being able to understand them, and then then you spend weeks learning them. You end up writing application that is glitching and you've no idea how to fix it because you depend on a dozen different tools. Worst part is that you don't even need them. You've been tricked by peer pressure into using them. When you've a complex, fragmented ecosystem, and developers are in stress because they can't understand and learn tools quickly enough, then the only logical conclusion that it will collapse, and only a few technologies will survive that will get mass adoption, and everything else will be forgotten.
  • shados 11y ago
    The ecosystem exploded because of a few core advances (ES6 finally coming out, Babel coming into light, the CommonJS approach to modules, the rebirth of functional programming on the frontend, etc). This is behind us now. If you sit in forums, chat rooms and other JS centric communities, you'll see that the dialog is pretty different. It's no longer "Let's build a new tool!" (oh there's some of that, but they rarely hit the spotlight). It's "How do we make this tool work in this edge case we didn't think of". There's still a framework every other day, but they're usually built on top of the core things now, and no one really pay attention to 99% of them anymore. If you remember the early days of Java and SOAP with the new SOA framework a day, this is pretty similar. It's settling down.
  • leeoniya 11y ago
    Good ideas get standardized. Ideas from Coffeescript made it into es6, Promises, fetch, etc. Once there are sufficient standards that solve the pain points, the fragmentation will go away. JS is playing catch-up because it was pointless to advance the language when IE didn't even support the existing standards and had 90% market share. Now it has to distill all the good ideas from the past 2 decades and other languages in short order. The chaos is understandable.
• eranation 11y ago
  > The learning curve is very flat So if the graph's x axis is time and y axis is the amount of stuff you learn, then a flat learning curve means that you gain very little added knowledge as time goes by. And a steep learning curve means that you learn a lot in a small amount of time. It always confused me why is it backwards.
  • deleted 11y ago
    [deleted]
• ellius 11y ago
  Can anyone tell me where to start on all of this as a self-taught beginner? I feel like I follow tutorials well and get basic apps up and running via tutorials. I've even built some basic tools in use by a handful of people at my job with Node and Meteor. But the minute I try to dive into React and some of these more professional tools in the ecosystem, I find myself totally lost.
  • shados 11y ago
    The article mentions https://github.com/petehunt/react-howto https://github.com/petehunt/react-howto. Its a damn good place to start.
    • ChrisDutrow 11y ago
      I just took a look, really good article.
• melvinmt 11y ago
  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.
  • scwoodal 11y ago
    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 https://github.com/scottwoodall/django-react-template
  • house9-2 11y ago
    My co-workers put together https://github.com/CodingZeal/react-boilerplate 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 https://egghead.io/series/getting-started-with-redux
  • davidjnelson 11y ago
    The two best ones I know of are: https://github.com/davezuko/react-redux-starter-kit https://github.com/davezuko/react-redux-starter-kit and https://github.com/erikras/react-redux-universal-hot-example https://github.com/erikras/react-redux-universal-hot-example
• arxpoetica 11y ago
  No mention of WebSockets...
  • andybak 11y ago
    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').
    • arxpoetica 11y ago
      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?
    • davidjnelson 11y ago
      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.
• georgefrick 11y ago
  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 starting over and feeling like you've chosen the right framework, but it's immature. Oh, we got it right this time! React is a paradigm shift! We've quickly forgotten we were saying this with Angular bindings. Oh your model based stuff is crap, this has TWO WAY BINDING, it's a paradigm shift! Now, I'm using Angular. I could recite the Backbone source code, we had a few small libraries and we built huge apps and they worked (and they were built with Grunt and it worked fine, but hey, move it all to Gulp! now! Paradigm shift!). In this case I was expecting it. I waited six months and Web Pack came along. We're going to go ahead and build our app in Angular 1.x with TypeScript and Web Pack and test it with Jasmine. This article is NOT correct. This hasn't been 'decided', there is no clear winner. You can't simply list the features of something as "amazing" and "where it's at". You are arguing finality here and you main data point is "coolness factor". It's not correct, it's not objective, and it isn't high quality, long term; well thought out software development practice.
  • jjawssd 11y ago
    AMEN
  • CalRobert 11y ago
    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.
    • akamaka 11y ago
      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.
• dkarapetyan 11y ago
  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.
• ilostmykeys 11y ago
  Relay beats Redux any day https://gist.github.com/idibidiart/49a095b6bc528638f34f https://gist.github.com/idibidiart/49a095b6bc528638f34f
  • shados 11y ago
    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).
• kayoone 11y ago
  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.
  • doczoidberg 11y ago
    I think the same. I don't understand the react hype. Yes, it is easy to learn but it doesn't even have basic features such as routing. Maybe I am more a framework guy but I think on such a basic level of software development a framework does better than a fragmented ecosystem.
  • t1amat 11y ago
    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 with massive scale dogfooding it, so you can be reasonably confident that the core library is high quality.
    • kayoone 11y ago
      ng2 will work with native script: http://angularjs.blogspot.de/2015/12/building-mobile-apps-with-angular-2-and.html http://angularjs.blogspot.de/2015/12/building-mobile-apps-wi...
      • t1amat 11y ago
        Thank you, I will check this out! I hadn't considered a NativeScript route.
• sklivvz1971 11y ago
  Every post that lists a set of tools is eventually going to be completely wrong. 1) This is the author's favorite setup in 2016. With all due respect, what is the lasting value of this information? 2) There is no "best" architecture. It depends on what problem one is solving. The author does not specify that, making their conclusions likely completely wrong in most cases. Yet, the language they use is in absolute terms. 3) 99% of JavaScript simply enhances static HTML pages. Yes, even in 2016. You probably don't even need jQuery, although it's likely to be available already. 4) It curiously evangelizes the "latest and greatest" frameworks, thus incurring in novelty bias -- new frameworks have less apparent problems because many side effects become apparent years later, once the codebase is mature.
  • shados 11y ago
    Redux is the only "new" thing in that list, and I could code it from scratch during a hackathon. It's also essentially a javascript port of what other framework and languages have been doing since before a lot of people reading this were born. Ironically, a lot of the comments in the article are complaining why some newer thing that just came out didn't make the list. Most of these tools are 2-3+ years old.
• bbcbasic 11y ago
  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.
  • t1amat 11y ago
    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.
    • bbcbasic 11y ago
      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 :-)
      • 11y ago
• andybak 11y ago
  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-complex. We've had all the obvious reactions: 1. This isn't my stack of choice 2. React is flawed 3. Don't use frameworks at all 4. I hate dynamic typing 5. Javascript is broken beyond repair 6. It will have changed by next week All of these are valid discussions to have but they get wheeled out every time and - maybe with the exception of point 1 - they are only indirectly related to the topic of this post. So every js discussion becomes a meta-discussion. Same thing with Google posts ('oh they'll close that down next week'), ORMs ('they suck'), Python ('Python 3 was a mistake') etc. HN comments needs an on-topic vs off-topic filter. Or a "yes we already know that" filter... (The irony of the above statements when this is also a meta-post is duly noted) My own feeling is that everyone should avoid jumping on complex frameworks until they are really needed. jQuery, Pjax or intercooler.js can take you a long way and save a lot of headaches. But when you do need a proper MVC-like framework then this article is a valuable guide of the sort that people have been asking for for months.
  • thenomad 11y ago
    I'd assume the reactions in this thread are part of the reason why people have been asking for a guide like this for months, and one hadn't been forthcoming. The "if I write an article expressing my opinion on this controversial issue I believe is important, 99.7% of the responses will be attacks, more or less regardless of the amount of time I put into writing it or the extent to which it's 75%, 95%, or 99% accurate" issue is a problem Internet-wide. Of course, criticism is valuable, but the balance seems a little skewed right now.
  • danmaz74 11y ago
    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 with some non-SPA Rails frontend). We did some pretty extensive research and comparisons back then. What we came out matches 90% what the OP proposes, and we're very satisfied with the results so far.
• cel1ne 11y ago
  Regarding CSS I recommend tachyons [0] over css-modules. [0] http://tachyons.io/ http://tachyons.io/
• kenOfYugen 11y ago
  > Avoid CoffeeScript. Most of its better features are now in ES6, a standard. This argument against CoffeeScript isn't very objective. One of CoffeeScript's best features is the minimalistic and expressive syntax. "CoffeeScript (#6) appears dramatically more expressive than JavaScript (#51), in fact among the best of all languages."[1] "CoffeeScript is #1 for consistency, with an IQR spread of only 23 LOC/commit compared to even #4 Clojure at 51 LOC/commit. By the time we’ve gotten to #8 Groovy, we’ve dropped to an IQR of 68 LOC/commit. In other words, CoffeeScript is incredibly consistent across domains and developers in its expressiveness."[1] Using the author's train of thought I could state: "Avoid Bluebird[2]. Most of its better features are now in ES6 promises, a standard." Yes promises are in the ES6 standard, but that's not the best feature of bluebird. There were and are many promise based libraries, but bluebird was built for unmatched performance. One will use it if performance matters. Even today it's faster than the native implementations of promises [3]. > Tooling (such as CoffeeLint) is very weak. Maybe because, as it turns out, in CoffeeScript you don't need a lot of tooling. Why would that be a bad thing? > Electron is the foundation of the great Atom editor and can be used to make your own applications. Atom is written in CoffeeScript [4]. [1] http://redmonk.com/dberkholz/2013/03/25/programming-languages-ranked-by-expressiveness/ http://redmonk.com/dberkholz/2013/03/25/programming-language... [2] https://github.com/petkaantonov/bluebird https://github.com/petkaantonov/bluebird [3] http://programmers.stackexchange.com/questions/278778/why-are-native-es6-promises-slower-and-more-memory-intensive-than-bluebird http://programmers.stackexchange.com/questions/278778/why-ar... [4] https://github.com/atom/atom https://github.com/atom/atom
  • k__ 11y ago
    I'm using LiveScript for private stuff and ES6/JSX in production. LS is a pleasure to write. But the tooling on ES6 is nicer I must admit :/
    • kenOfYugen 11y ago
      Out of curiosity, what tools are you referring to that are nicer on ES6 and not applicable to LS? Could you give examples?
• sandra_saltlake 11y ago
  It's not so bad. You just pick the most popular thing or use the recommendations in articles like this one.
• k__ 11y ago
  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
• neovive 11y ago
  Just wanted to mention VueJS as an option on the front-end for those looking for a simple JS library with components.
  • t1amat 11y ago
    I was enjoying lurking, reading some of the freak out around what amounts to spending a day or a week learning a new framework. Whether you believe that this JS theatre is good or bad, learning new concepts and solutions is never a waste of time, even if only to internally validate some other method. But if you thought that being a competent software engineer only required a one-time, upfront educational cost you probably got into the wrong field. But throughout all this I was wondering who would come out and mention Vue.js. While my own current preference is CLJS and reagent/re-frame, I feel like this largely unknown framework should get some representation. (Disclaimer: I am not claiming this is the best framework out there, but it is very nice and I believe a great alternative for many of the commenters here who are coming from Angular, trying to figure out where to turn next, but not wanting to toss years of experience.) If you come from Angular and like it's declarative markup but don't care for the outdated architecture, Vue.js[1] is worth looking at. It's beautifully clean and blazingly fast (v-dom under the hood). If you are willing to use a Webpack or Browserify loader you get a very straightforward single file component style[2], similar to a web component, where you can easily mix and match style (scoped or not), script, and markup language of choice. The script side of the component looks remarkably similar to React if the render function was replaced with an external HTML template in the style of Angular. For the Angular developers out there who "like things the way they are" (mostly), do yourself a favor and check it out. [1]: http://vuejs.org/ http://vuejs.org/ [2]: http://blog.evanyou.me/2015/10/25/vuejs-re-introduction/ http://blog.evanyou.me/2015/10/25/vuejs-re-introduction/
• doczoidberg 11y ago
  Do I bet on the wrong horse if I use Angular 2 instead of React+other tools? I don't get the whole React love? I always learnt not to mix view and business logic? React does this?
• pdog 11y ago
  A summary, for convenience, of the state-of-the-art libraries for front end development in Q1 2016: - Core: React - State container: Redux - Language: ES6 with Babel - Linting: ESLint - Style guide (ES6): Airbnb JavaScript Style Guide() { - Dependency management: NPM, CommonJS, and ES6 modules - Build tool: Webpack - Testing: Mocha and Chai - Utilities: Lodash - Fetching: Use what-wg or isomorphic fetch rather than jQuery - Styling: Sass, PostCSS, Autoprefixer, CSS Modules
• feiss 11y ago
  I feel dumb for not using React. Damn, I even feel I'm living in sin.
• deleted 11y ago
  [deleted]
• mhd 11y ago
  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).
• vmware505 11y ago
  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: http://yoember.com http://yoember.com
  • davidjnelson 11y ago
    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 http://emberjs.com/api/classes/Ember.Component.html Versus react's: https://facebook.github.io/react/docs/multiple-components.html https://facebook.github.io/react/docs/multiple-components.ht... Versus angular's: https://docs.angularjs.org/guide/component 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.
    • vmware505 11y ago
      Ember implemented React and Redux concept a year ago, the component layer is based on Virtual DOM. You can see here all the hooks what you can find in React, maybe with a little bit different function names... a modern Ember app is full of components. ;) http://emberjs.com/api/classes/Ember.Component.html http://emberjs.com/api/classes/Ember.Component.html (Tick the check-boxes, Ember.js is nicely object oriented, so you can get a lot from parent classes.)
• oever 11y ago
  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.
• jgalt212 11y ago
  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)?
• ashwin_kumar 11y ago
  >> "You’ll be able to package your application and distribute it like any other desktop application, complete with an installer and auto-updates." Yep, Electron is excellent. However, Electron is built on top of V8 and V8 does not provide a way to protect the JS source. More than the technical problem this becomes legal issue for businesses that want to develop applications/tools rapidly with electron. refer: https://github.com/atom/electron/issues/2570 https://github.com/atom/electron/issues/2570 Cons of other options that I know: 1. Obfuscation is not ideal to hide the source from competitors. 2. Writing nodejs modules in C++ is not so easy way. Once could prefer to develop entire app with C++ than the learning curve associated with node modules in C++. 3. V8 snapshots maybe a way to go with nw.js. But doesn't work great and it is hard to isolate issues while packaging. 4. EncloseJS looks promising. There is no company behind it and no guarantee it will be supported. (I personally have been following up with issues in packaging an open source app with encloseJS. No luck so far with support. 5. nexe is interesting. But not easy and no clear way to work with it. What are your opinions? Any alternatives? P.S: I'm framing a base with Java (most likely C++ too) to develop an app that runs on client machine but on browsers. Performance and source protection are my goals. Might open source its architecture eventually.