I feel like the people complaining about how many libraries there are in this stack don't know what these tools do. Most are small tools that do one thing very well.
Yarn installs packages, much like Gem, NuGet, whatever. Pretty standard.
React is a frontend framework. Not surprising that you'd use one. I suppose you could opt to write a giant pile of vanilla JavaScript instead (I'm assuming you're not using this kit for a simple webpage, which would be silly. We're building a web app, right?)
I'd dare to compare Gulp + Webpack + Babel to your "compiler" in a way. I'm a little lost at why we're using both Webpack and Gulp though. Babel is a necessary evil to ensure we're "cross-platform" in a manner of speaking. These are probably your most "unnecessarily complicated" tools.
ESLint and Flow check your code for obvious mistakes. Reminds me of IntelliSense and compiler warnings. Again, pretty standard stuff.
Mocha is a test runner and Chai is an "assertion library". Chai isn't a big deal: expect(foo).to.equal('bar'); Simple stuff.
Feel free to scoff at Redux and Immutable if you'd like. Probably unnecessary.
Am I the only one that likes this ecosystem? I feel like it follows the Unix philosophy of "Make each program do one thing well". You need almost all these tools in other environments -- they're just typically chosen for you in advanced.
I think the reason most of us dislike the ecosystem isn't because therre are many libraries and tools in the stack. In the C-world, every time you type 'make' I am probably executing two dozen different programs, so we are very comfortable with "Make each program do one thing well".
The problem that most of us dislike the javascript/web ecosystem is that those set of libraries and tools keep changing every couple years. As someone who doesn't do this as a full time job but once in a while has to poke his head out to the other side, it's really hard to keep up with even the acronyms. For example, I know that we are using npm, but now you say we should use yarn?!
I like it too. People vastly over-estimate the complexity of these tools.
As a freelancer, I start a new project every other week or so. It's really not hard to get up and running with these tools. They're also incrementally adoptable: since most of them are loosely coupled, you can get started with a new one without rewriting your whole stack (for example, I first used React with Gulp+Browserify, not I've switched to Webpack).
I like it as well. I have yet to see tech stack that has comparable potential but is less complicated and can be stripped down as low as the web stack if your requirements permit it.
I mean yeah, if you have a big app, complex requirements, there is a bunch of stuff you need to take care of.
However, I would like to see the tech stack that allows you to do the same with less complexity.
It's not like Android (gradle?!, java 6?!, the android api!?) or iOS development is a walk in the park if you want to do anything with production quality.
I'm usually one of those "JS frontend ecosystem is too complex" guys, but I found this tutorial to be quite approachable. Maybe the format of introducing one thing in each section helps?
There was a similar but much more complicated tutorial on HN a while back that I didn't get at all. Most of the explanation was handwavy - "just do this, trust me" - and the entire tutorial was dumped on a single page. Just looking at the scrollbar discouraged me!
I'm kind of surprised to see Yarn in a tutorial already. Welcome to the fast-moving world of JS, I guess?
Unix philosophy is "Make each program do one thing well", but they've made them once, many decades ago and haven't change them much since. The problem here IMHO is the speed at which it all evolves, and even more the speed at which the old tools become obsolete. You start a new project with the current 'cutting-edge' stack, and within the 6 months everyone switched to something else. It's become a full-time job just to stay up to date with everything that's going on, and that means making architecture decisions is a lot harder. Also, I personally dislike the fact that it forces one to pick a niche. For decades you could say "I'm good in front-end dev" and really mean it, and now it's not possible anymore to be truly proficient in all that's going on, you just have to specialize.
I love the fact that tons of great engineers are coming up with new ideas everyday to make my life as a developer easier.
I love hearing a developer at a daily stand-up meeting saying he's been up all night trying out a new shiny thing and concluding by saying it also solves a big issue we had in our product and here's the pull request (timestamp 4am).
The hype is here for a reason. Hype is nothing bad, being excited about your tools makes your days happier.
I love the fact that JS people are never going to take "No" for an answer, constantly pushing the boundaries of what's possible, and making the web standards improve. I love the rise of functional programming. JS is a playground where mathematical theory and all of its beauty meets practice and the real world. It attracts talented people who bring a new perspective to our field. I love the fact that now I have theorems that ensure my login button will work.
> I'm a little lost at why we're using both Webpack and Gulp though.
Same here. I think one of the huge benefits of webpack is that it actually kills a lot of complexity by allowing you to skip gulp/grunt in most cases.
I think most people do not realize that the JS ecosystem is actually removing complexity.
Most people think the JS ecosystem is overly complicated, when in fact, it's just that in JS the complexity is exposed. This allows us to focus on reducing it. In order to address an issue, you must first make it visible.
Nowadays the trend in JS is to use multiple small tools that solve specific issues very well. We have a complexity in setup in exchange for less complexity in development. I argue this is a good thing, because setup is easy to document and only happens once in a project. Whereas you face development complexity every day.
This part from the tutorial is very significant to me:
> I recommend writing everything from scratch yourself
Yes! Yes! Yes! That's the heart of the JS philosophy: the ecosystem is trying very hard to make you understand what you are doing and why. It's giving you the keys to question what you're told and improve it. It's also why there's so much trolling. It's a good thing, question what seems too complex so that people can tackle the issue.
Please, do keep saying JS sucks, it's exactly what makes it so strong.
Do not use a framework, wire-up things yourself so that tomorrow you can repair it or upgrade it easily.
Do not write your router from scratch. But do connect the standard-issue router to your business logic yourself. Don't let someone else plug it in for you. It'll fit, but it won't look as good as if it were custom-made by a great tailor.
Finally, I love the config files. I hear a lot of trolling about all the config files, but I love the fact that I don't need to tell both webpack and mocha how to transpile JS and can just let the .babelrc tell them and everyone else. It's amazing that you can just git clone something and have all your environment setup as the author intended: language variant, linting... with .eslintrc developers using IntelliJ and atom both see the same messages.
Long live JS, or whatever comes next as we improve it!
If you have worked in JS for some time, and have an idea what all these tools do, This comment is probably the best tl;dr of what you are going to learn ! Pretty balanced, Just to the point.
I havn't read the tutorial, but looks promising !. Will sure checkout this weekend :)
I think what sets many people off -- including myself -- is that the "recommended" libraries change so often. It's like a joke: "You're still using npm for installing packages? That's SO 2015! Of course you should be using Yarn."
After 21 years of JavaScript, one would expect a little more stability, so that the web app you build in 2016 with cutting-edge technology wouldn't be scoffed at in 2017 and obsolete by 2018.
"You need almost all these tools in other environments -- they're just typically chosen for you in advanced."
+ I don't think anyone is complaining about what the tools do, or necessarily their quality.
The fundamental complain is 'churn'. The stack you see today may be replaced in a year - moreover - it's really hard to tell where the community is going. There are few resources (or rather too many) that can tell you what 'works and what doesn't' etc..
Also - many of these problems should not exist in the first place, and kind of illustrate the underlying failures of the web-browser platform in the first place.
Again - great stack. But it won't last long, and it's very expensive to churn.
Recent comment at a JS meetup form some guy: "I just left a startup where I was the key Angular guy, it was all in Angular 1 - I have no idea who's going to support that now that I'm going considering everything is Angular 2 now".
Reasonable assertion.
Also - I'm not so sure the 'do one thing and do it well' theory is always an advantage. There are many solid platforms where things are really well curated by company ABC. I'd suggest that if they do their jobs well, it's better than a community approach.
Obviously - community vs. monolith is not black and white, and there are advantages to each side, but it would be unwise I think to ignore the problems of constant churn.
Another example - just at MS HQ in Montreal for a preso on React. 100 devs in the room were not particularly excited. They seemed more resigned to it than anything. The consensus was 'yet another thing'? I think there is really a big gap between those pro-shops on the cutting edge - and 'everyone else'. And React is by no means trivial.
> Since it came out in October 2016, [Yarn] received a very quick adoption and is becoming the new package manager of choice of the JavaScript community. We are going to use Yarn in this tutorial.
It's October 2016 as I write. Tell me this tutorial is satire. Please.
Ridicule me all you guys want but I still write using just html/css/js and sublime text (no jquery either). And I have written a 30k line project using just that and php.
Being a filthy casual has it's upsides. I can do whatever I want insanely quick. Moving projects from machine to machine is quick as well. Only time I use command line is for git. I do have the advantage of having all my customers on a modern browser. But if that were not the case, only thing extra that I would need is babel. None of what OP mentions is "needed" to create a "modern" web app. Far from it.
I appreciate the effort, certainly do. But, and this a big but: the amount of tooling, libraries, complexity and systems needed for a "modern" web app is almost comical at this point.
It's surprisingly full featured. Testing, ES6, CSS, live reload dev server, building for production ... everything you need for the majority of React based web app builds. Literally up and running in minutes. Also you can just offload all of the cognitive burden of selecting tools to people much more qualified.
Judge the whole scene by one GitHub project if you will, but the "boo hoo web development is too complicated" meme is getting a bit old now. It's mainly coming from a place of ignorance. Yes it's been a journey for web development over the past few years, but there are powerful and simple tools available now that other platforms and communities could learn from, rather than just disparage.
(above not quite done, it's for a presentation I'm going to do in December, but it's pretty close)
React works better for many things - server side rendering for SEO; endless scrawling wall of chunks of more-of-the-same (social media...) - but it's not "simple".
Are you sure it doesn't seem that way to you because you're less familiar with the ecosystem? Compare it to a Java backend. You might pick Ant, Ivy, Docker, Dropwizard, Guice, Jersey, Jackson, Mockito, JUnit, etc. I don't consider that to be radically less complex than the front-end stack proposed here -- but it just seems that way because a lot of those are "de facto" tools.
I've never been a front-end guy, and now the barrier grows with all these frameworks to make amazing applications still holding me back. Plus the fact that if I have NoScript installed, all my work is now pointless. I hate going to websites that literally don't work @ all if I have no JavaScript enabled, with the exception of HN and those rare sites that have minimal JavaScript in use.
In fairness you definitely do not need everything listed here to have a perfectly fine web app. I think it's more beneficial to add in things when you find a use case for it. You probably don't need 3 unit testing libraries, you don't need Redux to use React, nor do you need Immutable to use Redux.
Once you get an application set up for the first time you don't really have to change it much, unless you want to take advantage of new features in the browser or Node.
As a back-ender looking to dabble with modern front-end development best practices, I'm encouraged to find guides like this one. Even if the array of available packages and tools appears dizzying, and often times faddish, it's nice to see the many options laid out rather concisely.
I have a decent handle on React and some of its immediately related tools, which has greatly improved my fluency with contemporary front end work. I may not ever use all these tools, but again it's helpful to see their setup illustrated in an easy fashion.
Apart from React, what would be the next most important tool to pickup?
This is exactly why I don't do frontend development anymore. The number of tools needed to get an app up and running is ridiculous. Add in cross browser compatibility and it's all just one big headache.
You don't need all of these tools to get an app up and running even though reading the tech blogs may make it seem like you do. Frontend dev isn't really that difficult if you focus only on what is really needed for your app at hand.
Cross-browser compatibility? That is mostly moot with modern browsers. You really do not know how bad it was in the IE5/IE6 days. Browser compatibility is positively dreamy these days. It is getting better.
I don't think 'bad performance' is a fair characterisation of Immutable.js. If you're calling .toJS() all over the place it will be doing a lot of redundant work. However there should be no need to do that, if you just pass the data structures around and access their fields directly.
That's not to say that you should necessarily use Immutable.js; if you don't understand the use case where structural sharing in persistent immutable data structures is useful and require it for your application then you should probably just leave this tool on the shelf.
However, if, for example, you are maintaining maps containing many items which are updated frequently, then you may benefit from the time and space complexity of structurally shared maps (Immutable.js) rather than creating a full copy on each mutation (plain JS objects).
EDIT: just to be clear, I think that the tutorial itself is valuable and I appreciate it. I just wanted to post the link to CRA before somebody will come here complaining about "JS fatigue". I use most of the tools that tutorial describes and will use it to learn more about wiring testing-related tools. So yeah - thanks for posting the link and for the author(s) for taking the time to create such resource.
Am I the only one who thought the title meant actually rebuilding some of these tools from the ground up? Building a stack and using / leveraging a stack is significantly different.
At one extreme, one can build a modern app from scratch with no libraries. At the other, you can over-engineer it with far more libraries than you need. Somewhere in the middle lies the correct answer.
So the key is not necessarily to have a set boilerplate to start from. It is to understand what each tool offers, and why/when it is better then not having that tool. So you can look at a project, and make an informed decision of what stack to build.
based on the title, I thought it was going to talk about how to build a modern front end from scratch. That is, "modern" meaning that it meets the user's expectations, fits the realities of how they are browsing, and makes use of the features of current browsers (web sockets, local storage, etc); "from scratch" meaning using only your own code written in vanilla javascript. I thought this was going to be about the fact that you can do compelling work on the front-end without needing to get bogged down in a tangled web of dependencies. I struggle to see how this qualifies as "minimalist".
Building good applications for lots of people requires lots of stuff. Using vanilla JS to build web apps is as much fun as using vanilla python to build a backend.
The "guide" is minimalistic, not the stack. The point of making the guide minimalistic is to help folks feel less overwhelmed by the complexity of said stack.
[+] [-] nulagrithom|9 years ago|reply
Yarn installs packages, much like Gem, NuGet, whatever. Pretty standard.
React is a frontend framework. Not surprising that you'd use one. I suppose you could opt to write a giant pile of vanilla JavaScript instead (I'm assuming you're not using this kit for a simple webpage, which would be silly. We're building a web app, right?)
I'd dare to compare Gulp + Webpack + Babel to your "compiler" in a way. I'm a little lost at why we're using both Webpack and Gulp though. Babel is a necessary evil to ensure we're "cross-platform" in a manner of speaking. These are probably your most "unnecessarily complicated" tools.
ESLint and Flow check your code for obvious mistakes. Reminds me of IntelliSense and compiler warnings. Again, pretty standard stuff.
Mocha is a test runner and Chai is an "assertion library". Chai isn't a big deal: expect(foo).to.equal('bar'); Simple stuff.
Feel free to scoff at Redux and Immutable if you'd like. Probably unnecessary.
Am I the only one that likes this ecosystem? I feel like it follows the Unix philosophy of "Make each program do one thing well". You need almost all these tools in other environments -- they're just typically chosen for you in advanced.
[+] [-] khc|9 years ago|reply
The problem that most of us dislike the javascript/web ecosystem is that those set of libraries and tools keep changing every couple years. As someone who doesn't do this as a full time job but once in a while has to poke his head out to the other side, it's really hard to keep up with even the acronyms. For example, I know that we are using npm, but now you say we should use yarn?!
[+] [-] morgante|9 years ago|reply
As a freelancer, I start a new project every other week or so. It's really not hard to get up and running with these tools. They're also incrementally adoptable: since most of them are loosely coupled, you can get started with a new one without rewriting your whole stack (for example, I first used React with Gulp+Browserify, not I've switched to Webpack).
[+] [-] Retozi|9 years ago|reply
I mean yeah, if you have a big app, complex requirements, there is a bunch of stuff you need to take care of.
However, I would like to see the tech stack that allows you to do the same with less complexity.
It's not like Android (gradle?!, java 6?!, the android api!?) or iOS development is a walk in the park if you want to do anything with production quality.
[+] [-] Cyph0n|9 years ago|reply
There was a similar but much more complicated tutorial on HN a while back that I didn't get at all. Most of the explanation was handwavy - "just do this, trust me" - and the entire tutorial was dumped on a single page. Just looking at the scrollbar discouraged me!
I'm kind of surprised to see Yarn in a tutorial already. Welcome to the fast-moving world of JS, I guess?
[+] [-] ivanhoe|9 years ago|reply
[+] [-] snorrah|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] novaleaf|9 years ago|reply
[+] [-] djfm|9 years ago|reply
It's living, it's thriving.
I love the fact that tons of great engineers are coming up with new ideas everyday to make my life as a developer easier.
I love hearing a developer at a daily stand-up meeting saying he's been up all night trying out a new shiny thing and concluding by saying it also solves a big issue we had in our product and here's the pull request (timestamp 4am).
The hype is here for a reason. Hype is nothing bad, being excited about your tools makes your days happier.
I love the fact that JS people are never going to take "No" for an answer, constantly pushing the boundaries of what's possible, and making the web standards improve. I love the rise of functional programming. JS is a playground where mathematical theory and all of its beauty meets practice and the real world. It attracts talented people who bring a new perspective to our field. I love the fact that now I have theorems that ensure my login button will work.
> I'm a little lost at why we're using both Webpack and Gulp though.
Same here. I think one of the huge benefits of webpack is that it actually kills a lot of complexity by allowing you to skip gulp/grunt in most cases.
I think most people do not realize that the JS ecosystem is actually removing complexity.
Most people think the JS ecosystem is overly complicated, when in fact, it's just that in JS the complexity is exposed. This allows us to focus on reducing it. In order to address an issue, you must first make it visible.
Nowadays the trend in JS is to use multiple small tools that solve specific issues very well. We have a complexity in setup in exchange for less complexity in development. I argue this is a good thing, because setup is easy to document and only happens once in a project. Whereas you face development complexity every day.
This part from the tutorial is very significant to me:
> I recommend writing everything from scratch yourself
Yes! Yes! Yes! That's the heart of the JS philosophy: the ecosystem is trying very hard to make you understand what you are doing and why. It's giving you the keys to question what you're told and improve it. It's also why there's so much trolling. It's a good thing, question what seems too complex so that people can tackle the issue.
Please, do keep saying JS sucks, it's exactly what makes it so strong.
Do not use a framework, wire-up things yourself so that tomorrow you can repair it or upgrade it easily.
Do not write your router from scratch. But do connect the standard-issue router to your business logic yourself. Don't let someone else plug it in for you. It'll fit, but it won't look as good as if it were custom-made by a great tailor.
Finally, I love the config files. I hear a lot of trolling about all the config files, but I love the fact that I don't need to tell both webpack and mocha how to transpile JS and can just let the .babelrc tell them and everyone else. It's amazing that you can just git clone something and have all your environment setup as the author intended: language variant, linting... with .eslintrc developers using IntelliJ and atom both see the same messages.
Long live JS, or whatever comes next as we improve it!
[+] [-] ateevchopra|9 years ago|reply
I havn't read the tutorial, but looks promising !. Will sure checkout this weekend :)
[+] [-] facorreia|9 years ago|reply
After 21 years of JavaScript, one would expect a little more stability, so that the web app you build in 2016 with cutting-edge technology wouldn't be scoffed at in 2017 and obsolete by 2018.
[+] [-] jomamaxx|9 years ago|reply
+ I don't think anyone is complaining about what the tools do, or necessarily their quality.
The fundamental complain is 'churn'. The stack you see today may be replaced in a year - moreover - it's really hard to tell where the community is going. There are few resources (or rather too many) that can tell you what 'works and what doesn't' etc..
Also - many of these problems should not exist in the first place, and kind of illustrate the underlying failures of the web-browser platform in the first place.
Again - great stack. But it won't last long, and it's very expensive to churn.
Recent comment at a JS meetup form some guy: "I just left a startup where I was the key Angular guy, it was all in Angular 1 - I have no idea who's going to support that now that I'm going considering everything is Angular 2 now".
Reasonable assertion.
Also - I'm not so sure the 'do one thing and do it well' theory is always an advantage. There are many solid platforms where things are really well curated by company ABC. I'd suggest that if they do their jobs well, it's better than a community approach.
Obviously - community vs. monolith is not black and white, and there are advantages to each side, but it would be unwise I think to ignore the problems of constant churn.
Another example - just at MS HQ in Montreal for a preso on React. 100 devs in the room were not particularly excited. They seemed more resigned to it than anything. The consensus was 'yet another thing'? I think there is really a big gap between those pro-shops on the cutting edge - and 'everyone else'. And React is by no means trivial.
[+] [-] gotofritz|9 years ago|reply
[+] [-] stevoski|9 years ago|reply
> Since it came out in October 2016, [Yarn] received a very quick adoption and is becoming the new package manager of choice of the JavaScript community. We are going to use Yarn in this tutorial.
It's October 2016 as I write. Tell me this tutorial is satire. Please.
[+] [-] Achshar|9 years ago|reply
Being a filthy casual has it's upsides. I can do whatever I want insanely quick. Moving projects from machine to machine is quick as well. Only time I use command line is for git. I do have the advantage of having all my customers on a modern browser. But if that were not the case, only thing extra that I would need is babel. None of what OP mentions is "needed" to create a "modern" web app. Far from it.
[+] [-] anon1253|9 years ago|reply
[+] [-] Wintamute|9 years ago|reply
https://facebook.github.io/react/blog/2016/07/22/create-apps...
It's surprisingly full featured. Testing, ES6, CSS, live reload dev server, building for production ... everything you need for the majority of React based web app builds. Literally up and running in minutes. Also you can just offload all of the cognitive burden of selecting tools to people much more qualified.
Judge the whole scene by one GitHub project if you will, but the "boo hoo web development is too complicated" meme is getting a bit old now. It's mainly coming from a place of ignorance. Yes it's been a journey for web development over the past few years, but there are powerful and simple tools available now that other platforms and communities could learn from, rather than just disparage.
[+] [-] Roboprog|9 years ago|reply
Angular (1.x) might not be "cool" anymore, but it can be pretty darn "minimal" to set up: https://github.com/roboprog/ang-prog-enh
(above not quite done, it's for a presentation I'm going to do in December, but it's pretty close)
React works better for many things - server side rendering for SEO; endless scrawling wall of chunks of more-of-the-same (social media...) - but it's not "simple".
[+] [-] ng12|9 years ago|reply
[+] [-] giancarlostoro|9 years ago|reply
[+] [-] TheDrizzle43|9 years ago|reply
[+] [-] rimantas|9 years ago|reply
[+] [-] hhsnopek|9 years ago|reply
[+] [-] garysieling|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] czep|9 years ago|reply
I have a decent handle on React and some of its immediately related tools, which has greatly improved my fluency with contemporary front end work. I may not ever use all these tools, but again it's helpful to see their setup illustrated in an easy fashion.
Apart from React, what would be the next most important tool to pickup?
[+] [-] sospep|9 years ago|reply
example: This is a minimalistic and straight to the point guide to assembling a JavaScript stack.
It teaches you how to set up ES6, Babel, Gulp, ESLint, React, Redux, Webpack, Immutable, Mocha, Chai, Sinon, and Flow. It
[+] [-] dglass|9 years ago|reply
[+] [-] 20years|9 years ago|reply
[+] [-] steveax|9 years ago|reply
[+] [-] onewaystreet|9 years ago|reply
Cross browser compatibility is one of the reasons why these tools exist.
[+] [-] cel1ne|9 years ago|reply
Also I'd give up Mocha, Chai & Sinon for tape, which is way simpler and more than enough:
https://medium.com/javascript-scene/why-i-use-tape-instead-o...
[+] [-] mambodog|9 years ago|reply
That's not to say that you should necessarily use Immutable.js; if you don't understand the use case where structural sharing in persistent immutable data structures is useful and require it for your application then you should probably just leave this tool on the shelf.
However, if, for example, you are maintaining maps containing many items which are updated frequently, then you may benefit from the time and space complexity of structurally shared maps (Immutable.js) rather than creating a full copy on each mutation (plain JS objects).
[+] [-] BigJono|9 years ago|reply
[+] [-] iyn|9 years ago|reply
EDIT: just to be clear, I think that the tutorial itself is valuable and I appreciate it. I just wanted to post the link to CRA before somebody will come here complaining about "JS fatigue". I use most of the tools that tutorial describes and will use it to learn more about wiring testing-related tools. So yeah - thanks for posting the link and for the author(s) for taking the time to create such resource.
[+] [-] blueside|9 years ago|reply
[+] [-] kennell|9 years ago|reply
Stopped reading right here.
[+] [-] giancarlostoro|9 years ago|reply
[+] [-] bsou|9 years ago|reply
TypeScript, React, Redux, Webpack, Immutable, Ava
- TypeScript covers much of the benefit of es6/babel/eslint/flow, Ava covers chai/mocha, and webpack can cover most of what gulp provides
[+] [-] johnwatson11218|9 years ago|reply
[+] [-] codingdave|9 years ago|reply
So the key is not necessarily to have a set boilerplate to start from. It is to understand what each tool offers, and why/when it is better then not having that tool. So you can look at a project, and make an informed decision of what stack to build.
[+] [-] rhodri|9 years ago|reply
[+] [-] zemo|9 years ago|reply
[+] [-] bikamonki|9 years ago|reply
[+] [-] tribby|9 years ago|reply
"ES6, Babel, Gulp, ESLint, React, Redux, Webpack, Immutable, Mocha, Chai, Sinon, and Flow"
brutal.
[+] [-] bendavis381|9 years ago|reply
Django, gunicorn, Django Rest, Postgres (psycopg2), celery, redis, requests, nose, factory_boy, freezegun, raven
Building good applications for lots of people requires lots of stuff. Using vanilla JS to build web apps is as much fun as using vanilla python to build a backend.
[+] [-] jverrecchia|9 years ago|reply
The "guide" is minimalistic, not the stack. The point of making the guide minimalistic is to help folks feel less overwhelmed by the complexity of said stack.
[+] [-] mcbits|9 years ago|reply
[+] [-] jfe|9 years ago|reply