19 ms·
Step-by-step tutorial to build a modern JavaScript stack from scratch
- iyn 10y agoFYI: if somebody doesn't want to wire everything, there's a pretty good solution: https://github.com/facebookincubator/create-react-app https://github.com/facebookincubator/create-react-app 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.
- anon1253 10y agoI 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.
- TheDrizzle43 10y agoIn 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.
- deleted 10y ago[deleted]
- ng12 10y agoAre 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.
- Roboprog 10y agoOh sure, let's pick on the fat kid :-) Yeah, there's a lot of evil lurking in Java-land, but that doesn't stop people from having to use all those things, either.
- rootlocus 10y ago> You might pick Ant, Ivy, Docker, Dropwizard, Guice, Jersey, Jackson, Mockito, JUnit, etc. I would pick maven, and add the rest as dependencies inside the pom.xml file (the only configuration file I need to worry about). It would take me about 5 minutes and then I could import the project into IntelliJ IDEA and hack away. I can write a tutorial about it in a single blog post, together with the necessary commands to build, test and deploy the artifact. With javascript, I need: webpack.conf, package.json, .babelrc and god knows what else. Seems like every piece of technology around javascript (transpilers, packers, dependency managers) requires another layer of configuration, another set of CLI commands, and another waste of time trying to figure out why it doesn't work.
- deleted 10y ago[deleted]
- ceronman 10y agoJava is no less complex indeed. I'm just starting to use its ecosystem and I definitely think it has a lot of complexity. But there are other tools that are much simpler. One example is the Dart programming language. I know it's not very popular here in HN land, but the experience is really really nice. You have a fast, powerful, concise, sane and optionally static typed language with awesome tooling (debugging, introspection, profiling, package management) and great support from Google. All this comes in a single easy to use installer. The only extra thing that you might need to download is a plugin for your favorite editor or IDE. Dart, of course, doesn't enjoy all the hype that the JS ecosystem has, but the barrier of entry is really low, and the tools are extremely polished, stable and very production ready. I recommend anyone who is not scared of leaving the hype train to give it a try.
- rubber_duck 10y ago
- Roboprog 10y agoDescribing that collection of tools as "minimalistic" was indeed a touch of irony. 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 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".
- Roboprog 10y agoI guess I should have said it is helpful that somebody is putting together a tutorial for what they feel is a useful path to a certain destination. BUT, the author might want to address the "elephant in the room" that there is a certain amount of necessary complexity if you want to meet certain goals.
- deleted 10y ago[deleted]
- xg15 10y ago...and I'm just sitting here, using jQuery..
- Roboprog 10y agoAnd that works well for some use-cases, as well. E.g. - I (only) want to read some hidden link data in the original page DOM, then load some page fragments that are taking longer to generate.
- elnado 10y agoYeah that's awesome! I still reference the Angular seed project whenever doing a quick front-end for a prototype.
- rimantas 10y agoWhat's comical (or sad, really) that things built with this often are not even web apps.
- Wintamute 10y agoThe create-react-app tool from Facebook lets you create a "modern" (air quotes yours) web app with one development dependency and zero configuration. https://facebook.github.io/react/blog/2016/07/22/create-apps-with-no-configuration.html 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.
- treehau5 10y agoIt's funny, but if some of these people griping about web development tried to unpack their favorite enterprise framework, like Spring MVC or whatever J2EE/.NET architecture they are running, there would be way more packages and bundles wrapped up together. It's just the web is finally getting to a good place.
- fourthark 10y agoYeah, difference is between a "standard library" with a million components, and a million independently distributed components. With the usual tradeoffs between centralization and competition.
- ng12 10y agoHow do you think you get to a standard library? How do you package the best tools when you don't know what the best tools are?
- deleted 10y ago[deleted]
- hhsnopek 10y agoI agree, all you really need is webpack and vuejs
- giancarlostoro 10y agoI'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.
- beejiu 10y ago> I hate going to websites that literally don't work @ all if I have no JavaScript enabled It is no surprise that businesses don't want to spend an extra 20% development time supporting 0.5% of web users. At some point, it becomes a problem for the user - you cannot support everyone.
- astrobe_ 10y agoExcept they could spare 200% development time with only HTML+CSS. Many times the real motivation is monetization. Simple sites like HN that don't get revenue from readership don't need Javascript.
- CaptSpify 10y agoAgreed. Why spend more effort making sites less usable for everyone? If you keep things small and simple, you spend less time developing and they are more resilient
- Touche 10y agoProgressive enhancement isn't about people with JS turned off. It's about resiliency to failures. That might be network congestion, it might be a mistake in your code, or something else.
- garysieling 10y agoOnce 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.
- cel1ne 10y agoI would give up Immutable because of it's bad performance and often confusing api. 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-of-mocha-so-should-you-6aa105d8eaf4#.53b5r8pfe https://medium.com/javascript-scene/why-i-use-tape-instead-o...
- flanbiscuit 10y agohaven't tried out Tape but if I could get rid of 2 libs and just use one then that's great.
- vmasto 10y agoCare to provide sources for Immutable's bad performance?
- acemarke 10y agoThere is some overhead to its use, both conceptually and with actual performance. I wrote a comment a while back describing some concerns with using it [0]. I also have some links relating to potential performance issues as part of my React/Redux links list [1]. [0]: https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abramov_redux_is_not_an_architecture_or/d51g4k4/?context=3 https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abra... [1]: https://github.com/markerikson/react-redux-links/blob/master/react-performance.md#immutable-data https://github.com/markerikson/react-redux-links/blob/master...
- BigJono 10y agoGulp is obviously not needed as well. That's the most confusing dependency in this stack imo.
- mambodog 10y agoI 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).
- bsou 10y agoAlternative stack that gets you much of the same stuff with less: 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
- k__ 10y agoThere are many alternatives to chai/mocha. Ava, Jest and Tape. I wouldn't consider Webpack an alternative to Gulp. Gulp is more generic. But if you use Webpack you can replace to task-runner part with a few scripts. When using ES6 or TypeScript I'd also consider Immutable to be optional, because of "const" and "Object.assign()/Spread-Operator". Also, React & Redux can be replaced with 1 thing, when you use a framework that bundles view components and state management.
- vmasto 10y agoNit: not sure why you mention const. It does not provide any kind of immutability assurance.
- k__ 10y agoI just use const instead of var/let all the time and it prevented me from overriding the variable later, which forced me to write my code a bit more functional then before I used it. I know that I can still change indirect references or override valueOf() etc.
- pault 10y agoYou probably know this, but for anyone else reading, the problem is that if you assign an object or array using const, the object/array members are still mutable. If you have a tree structure, you have to recursively Object.freeze the entire tree to get immutability, which AFAIK is basically what immutable.js does for you. I also use const by default, but I find that more often than not my variables are trees and lists.
- 10y ago
- rhodri 10y agoYarn came out this month
- ourmandave 10y agoCome Nov 1st, it will be so last month.
- LordHeini 10y agoDon't forget that next month someone will pull down his trivial package doing uppercase or something and the whole stack (of cards) will come crashing down. Lately there was some great post here on hn mocking all that js framework lunacy. But i guess that joke is old now as well... But seriously does someone use this to do proper work? And if so does this person expect this to be maintainable in the near future?
- elnado 10y agoYes.
- Matachines 10y agoNot only do people do this to do proper work, but the major companies people look up to do and want to work at or emulate do. Hence the problem.
- jasonthevillain 10y agoTo me, Yarn seems like the least troublesome new thing. Is it new and redundant? Yeah, but it's also a drop in AND drop out replacement for NPM. Many of the other "modern touches" would require you to rewrite your whole app if you concluded something was more trouble than it was worth.
- dglass 10y agoThis 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.
- 20years 10y agoYou 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.
- ythl 10y agoIt's just tiring though. I want to make a simple website. But in order to do it "right" or "optimally" or whatever, I need to flush all the old stuff I know down the toilet (jQuery, etc.) and learn a mountain of new stuff.
- 20years 10y agoWho are you trying to make it "right" or "optimally" for? The developer community or the end user? Unless your end user is the developer community, I doubt they give a crud if you are using jQuery or all of this stuff. As long as your app is doing what they want it to do and doing it well, that is what matters most. If you want to make a simple website, all of this is way over-kill. That is one of the downsides with these discussions. People are lead to believe that all of this is needed to "make a simple website". I am not at all opposed to learning new stuff especially if it is going to make your job easier, but don't feel you have to abandon your current toolbox and buy into a new one every few months just to keep up. That imo is madness and will only hold you back from getting stuff done.
- ng12 10y agoAt my current gig we maintain two stacks: 1. Angular-based template generator for "I'm a backend dev but my manager assigned me to build a front-end, just tell me how to do it" 2. React/Webpack/Babel/etc. stack for the front-end folks who really care about customization and control. If you don't need to build complex, maintainable web applications for your job this toolset probably comprises more reading/setup than you'd want to do. For me they're a life saver.
- sospep 10y agodefine:irony - a state of affairs or an event that seems deliberately contrary to what one expects and is often amusing as a result. 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
- cyberferret 10y agoExactly. I clicked on the link and when I saw the list of libraries alongside the word 'simple', I immediately thought it was a parody or satire site. I kept reading, looking for the joke and wondering why I didn't 'get' it?!?
- dclowd9901 10y agoYou don't need ES6, Babel, Gulp, Immutable or Flow. Now it's just React, Redux, Webpack, and a testing suite.
- johnwatson11218 10y agoI'm only half kidding but how complex does modern js have to get before it is easier to code business apps in something like unity3d?
- majewsky 10y agoThis is exactly why asm.js and WASM exist: to enable frontend code to be written in something that's not JS.
- johnwatson11218 10y agogood to know. I had heard of this stuff before but just assumed it was yet another framework.
- giancarlostoro 10y agoAm 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.
- bikamonki 10y agoAre you guys familiar with the term overengineering?
- Matachines 10y agoI wonder what % of HN would be unemployed if companies moved away from crazy complex SPAs. Surely how crazy they get is a reason why many here have jobs.
- nulagrithom 10y agoI 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.
- morgante 10y agoI 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).
- threeseed 10y agoThe complexity of the tools isn't the problem. It's the fact that the entire Javascript community seems to suffer from ADHD and is constantly inventing a new tool that is marginally better than the last. So for those us who don't do front end development we come back and suddenly have to learn 20 new tools.
- czep 10y agoAs 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?
- pault 10y agoThe good news is that it can all be broken down into view library, state management, transpiler, build tools, and test framework. Almost all of these tools fit one or more of these categories. If you pick the one or two most popular libraries from each of these categories and build a toy app using them, you'll be 90% of the way there. The stack listed in this article is the current vogue. If you're not already using webpack with react, I would recommend putting the time in to learning that. It's a beast and the documentation leaves a lot to be desired, so you'll have to supplement your education with a lot of google searches, but it's quite powerful and flexible. React has come to dominate the ecosystem so rapidly that for the medium term you're probably fine just sticking with that, and learning complementary tools like various flux or relay/graphQL implementations. Angular is the only other tool I regularly run into as a freelancer, but this is less and less often. Almost all the clients I've worked for in the last six months have wanted react. Of course there are many more exotic stacks that some people swear by, but if your goal is to cover the largest percentage of the job market possible, react and angular will get you there with a minimum of effort.
- dwaltrip 10y agoI would look at adding SCSS to your workflow. It makes writing maintainable stylesheets much easier. The two biggest wins from using SCSS, in my opinion, are the variables and the ability to nest selectors. The node-sass package (on NPM) comes with a command line tool, so you don't even need to add a separate build tool. I have an NPM script that executes: node-sass -w styles/app.scss -o dist/ The -w flag tells the tool to stay in "watch" mode, such that it will auto recompile your SCSS code into CSS whenever a change is made.
- codingdave 10y agoAt 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.
- Matachines 10y agoWhat's the author's credibility? I know it's free, but why should I give my time to read this compared to other resources? I don't know how to say it without sounding like a dick, but the amount of long "learn web dev" resources by people who can't write well and whose only ethos is just being a programmer is ridiculous.
- dvdhnt 10y agoWell, for what it's worth, he has a Masters in Computer Science, his open source Initializr project is pretty popular apparently, this tutorial has 3700+ stars on Github, he wrote a book on HTML5, and was a front-end engineer at Yelp. You can see his Github here https://github.com/verekia https://github.com/verekia And his resume here http://verekia.com/resume/ http://verekia.com/resume/ Edit: I find the article to be fairly well written, and I do have a background in reporting and am a full time dev using most of these tools (although I'm not particularly bound to them).
- finchisko 10y agoOver the years (ok months) I build aversion against JS stacks. I tried to used many of them when they popped up and I was starting new project. But it was never a fit to me. However to give them at least some credit, I read sometimes list of libs they're using for inspiration.
- tomcam 10y agoAn excellent description of the stack and an able "defense". Thank you very much
- stevoski 10y agoFrom section 1 of the tutorial: > 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.
- joshkpeterson 10y agoThe thing is, Yarn is likely to supersede npm at the command line so this is really future-proof.
- pault 10y agoWelcome to front end development. :)
- gotofritz 10y agoYarn solve some problems that the npm folks were unwilling / unable to solve, and is backed by Facebook + Google (+ others) so it's likely to be here to stay. Unless npm wake up and smell the coffee and implement some of it themselves, but experience shows they are quite opinionated and not in a good way.
- Klathmon 10y agoIIRC the yarn developers worked with NPM to get it out. It's not a lack of will or ability on the part of NPM that it can't be "fixed", it's that NPM has just so much baggage. They can't change how things are installed, because that would mean getting rid of features that many people rely on. For a while they didn't even have any documentation on how NPM worked, it was a bit tautological (npm worked in the way that npm worked...). And rather than add flags or settings to NPM to support yarn's use cases which would bloat the code, add a pretty sizable increase to maintenance and support, and would really be a mess, they decided to create their own tool which is similar enough to make it easy to switch, but without any of the legacy baggage that NPM needs to support. It's a perfect example of the unix philosophy at work ("Don't hesitate to throw away the clumsy parts and rebuild them."), and just about everyone (including NPM) is happy with the work they are doing.
- torkable 10y agogod just use elixir, what is this nonsense
- deleted 10y ago[deleted]
- kennell 10y ago> It teaches you how to set up ES6, Babel, Gulp, ESLint, React, Redux, Webpack, Immutable, Mocha, Chai, Sinon, and Flow. Stopped reading right here.
- blueside 10y agoI would suggest to the author to put a "This is not satire" disclaimer at the top of article to discourage users from leaving.
- jfe 10y agoso easy, any 10 year old with 30 years' experience can do it.
- zemo 10y agobased 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".
- disordinary 10y agoThis whole complicated stack of parts is why I don't really like React, you're never 100% sure if what you're doing is best practice. I find Ember to be much better, you only need to install Ember CLI and everything is put together for you.
- be_erik 10y agoEmber still has by far the best out of box experience and guides like this make that point painfully well. With Ember CLI you start at step 1, skip all the build steps (babel, webpack, etc...), and move on to learning the framework and getting some work done. In the end you'll end up with a framework that already has a story for state management, api interaction, client side routing, and a complete testing story. I've setup the described React stack many times. I like React as a view management library, but it requires a large amount of duct tape to get working and even once it is I still have to dedicate a lot of time to tweaking and maintaining all of these interconnected build steps. There are still tradeoffs that have made React a great choice some cases (namely its reliance on build duct tape allows it to be retrofitted into larger mature apps), but for apps I want to just work out of the box Ember/Ember CLI is an easy choice.
- captainbenises 10y agoYou don't need all those tools. I'm a big fan of browserify and the budo development server. npm init npm install -g budo npm install --save-dev babelify babel-preset-es2015 echo "console.log('hello world')" > index.js budo index.js --live -- -t [ babelify --presets [ es2015 ] ] Add tape for some tests and you're done.
- Achshar 10y agoRidicule 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.
- frik 10y agoExactly. It seems the less people know about web tech, the more third party stuff the add to a website. And then they wonder why the visitors drop off and hate the sites. Some website got so bad, that they crash mobile browsers due excessive CPU/memory usage. As you mentioned server side generated code with eg PHP and HTML5, CSS3 and JS5+ is in many cases all you need to know.
- metaloha 10y agoLately I've been seeing this as part of the problem in web dev. When you start a new project - let's say something like an employee management system that tracks schedules, locations, reviews, etc. - one of the early things you do is probably grab a framework for the back-end; maybe Laravel or Symfony or Zend - or maybe you roll your own (router, controllers, models, views, whatever). You mentally conceptualize and visualize the entire project in terms of delivering "views" to the browser (something not helped by the inaccurate terminology used in most back-end "MVC" frameworks). Why don't we see the front-end in the exact same way? I have a list of requirements that the interface needs to accomplish - why don't I use a front-end framework (which can actually be a real MVC framework)? Why do we consider all these things for the back-end, but then write just one or two Javascript files for the front-end and add a few libraries like jQuery and/or Modernizr? Where's the consistency? Why do we just throw all our JS code into a single file? Our contemporaries would ridicule us if we did that with our PHP files. Up until, like, Thursday, I thought this way as well. I guarantee my next big project (after a few small practice projects) will place the "views" and "controllers" where they belong, completely within the browser. This is where the user interaction happens, and there's no need for a server round-trip every time something gets clicked. The "model" is the data store (i.e. the back-end server) - all the client needs is an interface to it. The back-end will be nothing more than the "model" layer, though it will necessarily have it's own routing and controllers (after all, business logic still belongs on the server where the user can't mess with it). Access is through a REST API, and it delivers nothing but data and URLs for static/generated assets. Is this more difficult? Definitely. Requires more tooling on both ends? Absolutely. Lets me properly architect and visualize the entire project from front to back without any inconsistencies in perception? Yes. This is not MVC, this is VC/MC.
- tribby 10y ago"This is a minimalistic JavaScript stack" "ES6, Babel, Gulp, ESLint, React, Redux, Webpack, Immutable, Mocha, Chai, Sinon, and Flow" brutal.
- bendavis381 10y agoMinimalist python backend stack: 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.
- tribby 10y agoI'd opt for flask if I were using python, but that's just me :) the thing about the above-mentioned JS stack is that it's barely the tip of the iceberg. most of the dependencies in those python apps are built using standard libraries that simply don't exist in javascript. glazing over the whole "you're about to download a bunch of random stuff from npm that may be unmaintained or malicious" thing doesn't do a service to a junior dev. it's also not a "modern" stack. gulp? webpack. npm? yarn. react? vue. and in another month it will be something else. what you would opt for in python, is well-established, built on libraries that are part of python's core, and maybe except for the testing stuff has been around for 100 javascript years. I'm criticizing neither the article nor its author, simply remarking that javascript in 2016 is, in practice, completely fucking brutal.
- jverrecchia 10y agoI believe you quoted me wrong :) 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.
- vnchr 10y agoI'm between entry-level and intermediate as a full-stack JavaScript dev, and I'm seeing these tools (or equivalents) as the basics used at the last couple jobs and the ones I'm applying to now. Really appreciate you putting this together. Thanks so much.
- deleted 10y ago[deleted]
- manish_gill 10y agoThis is ridiculous.
- fsloth 10y agoThe "... from scratch" part made me think of actully implementing a Javascript based browser environment from first pronciples and not just of a list of random third party libraries.
- gagsrg 10y agoI don't use testing frameworks, no point to it.
- ge96 10y agosubbed
- Raed667 10y ago"From scratch" tutorial, that tells you to go learn react elsewhere then come back...