61–70 of 306 posts
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
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…
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…
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. The obvious next question is: what patents are necessarily infringed in the first place, just because you used React? It's a useful tool, but even if Facebook have successfully acquired relevant US software patents, it's hard to believe there's anything significant in ther…
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: 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…
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/ [2] https://medium.com/@keithwhor/realtime-doesn-t-belong-everyw... [3] htt…
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…
Polymer ( 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 d…
It's been probably 2 years since I did it, so I'm sure there are better solutions - but I liked it as a dev environment. It's somewhat opaque, though.
https://github.com/STRML/securesha.re-client/tree/master/pol...
Why is eslint considered better than jshint+jscs? jscs also supports auto-fixing, which is pretty dope.
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.
> 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 nee…
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.
> 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 nee…
I'd happily include a 9kb (unminified) polyfill and work off the assumption that I can remove it a few years down the road.