6 ms·
Advice please: I tried to wade into the weird and complicated world of web development a few months ago, but eventually I gave up. At first I used a boilerplat
by Niksko 10y ago
Advice please: I tried to wade into the weird and complicated world of web development a few months ago, but eventually I gave up.
At first I used a boilerplate (in fact I think it was a previous version of this one), but it felt like I was jumping in the deep end. I didn't know what anything was, I didn't understand the configuration or the setup, and nothing was making sense.
So instead I decided "I'll start from scratch, introduce dependencies as I need them, and I'll actually understand what's happening". But then as I started to try and introduce dependencies and pieces of the toolchain and stack (Babel, GraphQL/Relay etc.) and that was a whole different type of confusing. I found it really hard to follow tutorials unless they were written for EXACTLY the stack I was using, because small changes seemed to radically change how I had to go about things.
How do you start? Both situations seem perilous. Bottom up is really difficult unless you follow a tutorial that exactly matches your stack. Starting with boilerplate means that if anything breaks you have no idea how to fix it or how anything works.
- rdoherty 10y agoI agree and I'm also curious how someone would integrate all the React ecosystem into an already exiting app (Rails specifically). Starting a new project is easy, rewriting one is a huge challenge.
- RobertKerans 10y agoReact Rails[1] works fine: you just get React, and it's difficult to integrate other shiny React-associated stuff like Redux, but it makes it incredibly easy to build out an app, or even just sprinkle components throughout an existing Rails app. It's dead simple to get started, and I've found it generally Just Works; the whole team I work on has been using it for the last 4-5 months without any issues. Just add to Gemfile -> it sets up a components folder + a file that imports the file tree -> then optionally set initializer options (like include React Addons, or use stage-0 stuff). All exposed globals though, which is a pain, but that's generally expected with the asset pipeline unless you're very disciplined. There's a pretty complete tutorial, but it's a bit out of date + uses CoffeeScript rather than JSX - I made a copy of the original, with updates, for one of my colleagues, the gist is here (sorry, might be a little rough): https://gist.github.com/DanCouper/b6953544a34606617eb5 https://gist.github.com/DanCouper/b6953544a34606617eb5 To get a bit deeper, there's React on Rails[2], which retains the same entry point, but moves all the JS to a separate folder at root, and uses Node to handle that side of things during development. The setup is batteries included, and pretty flexible, but I haven't used it a huge amount so can't give much detailed feedback. 1. https://github.com/reactjs/react-rails https://github.com/reactjs/react-rails 2. https://github.com/shakacode/react_on_rails https://github.com/shakacode/react_on_rails
- jbob2000 10y agoWork backwards. Start with tools that basically do all your work for you, and then try to understand the pieces as you work with them. Try the angular-fullstack generator using yeoman: https://github.com/angular-fullstack/generator-angular-fullstack https://github.com/angular-fullstack/generator-angular-fulls... This will generate you a fully functioning front end and server, with an authentication and user management service. It also has methods to push to heroku, so you don't really need to know how to deploy to a live server.
- jfdk 10y agoMy advice would be don't use all the fancy stuff. You really don't need to. A basic HTML page with a few <script> tags will go a long way. And with browsers supporting most of ES6 (WebKit supports all of it) you can use all the new JS features in your dev environment no problem. Don't introduce these dependencies if you're just learning. Just use what you need (React + Redux).
- dagw 10y agoHow do you start? Me? I start by asking myself "do you really really need Babel, GraphQL/Relay etc"? Once I've answered "probably not, at least not right now" I decide to use PostgreSQL with python and flask (or node and restify/express if I'm that sort of mood). For the front end I start with a simple bootstrap setup. Once I get to the point where I actually really need GraphQL or whatever I have a good enough understanding of my needs that it becomes pretty obvious how I should integrate it.
- bshimmin 10y agoIt's a ghoulish nightmare, isn't it? I think one possible approach - and I haven't tried this because I am in the fortunate position of having been working in web development for a long time and just about having kept pace with most of what's been happening (and also I've been happy enough to avoid the parts that weren't enticing or seemed actively unpleasant) - is to take something like this boilerplate project and prise apart its individual components to see if you can work out what each of them does and to get some experience with it in isolation. Perhaps you might start with a tiny project with React - just an HTML file and enough JavaScript to make React, well, react. Then maybe play about with ES6 and Babel. Then see what PostCSS does. Then add Redux in there to your React mini-project. Then... oh, I don't know, throw the whole thing away and use Elm, because that seems quite popular now.
- TJSomething 10y agoI am currently trying to get into the deep end by reading and watching enough tutorials that I can see the patterns emerge. It's tough. I miss Ember, but it's not really going to work on my current project, which is probably going use Webpack, Babel, React, Redux, GraphQL, Koa, Scala, Akka HTTP, and Sangria so far.
- ianstormtaylor 10y agoIf you're already going to be using GraphQL for your main API, I highly recommend looking at Relay. Slightly steeper learning curve than Redux, but it will more than make up for it once you get it configured, because you'll be able to completely ignore it and it will just work. You won't need to think about "how do I get this data" at all anymore.
- fiatjaf 10y agoWhoa, so many names.
- ianstormtaylor 10y agoAs someone who's been around frontend development for a while now, and who had a similar "wtf" moment when finally deciding to pick up React and all of its friends, I think it depends on what you want to learn... 1. If you want to learn frontend from scratch... Then I'd recommend not going anywhere near React at all. Stick with plain HTML/CSS/Javascript injected with <script> tags on the page. Throw in jQuery if you need to. Although if you're just hacking on things that need to work in Chrome / Firefox, you don't even need it. That should give you a good introduction to the fundamentals, and still be fairly easy to find tutorials and information about how to get things done. The key is to have a well-defined, but small project idea to be able to implement. When I was first getting started one of my early projects was a domain name search using the Domainr API. Something at that scale, with just one or two pages and a small amount of Javascript is perfect. 2. If you want to learn React... Then I'd recommend not trying to do add anything like Redux or Flux or Relay to begin with from the "state control" side. And don't worry about Webpack or Hot Module Replacement or anyting from the "build experience" side. The only additional thing I'd add here is Babel. While it's not required to get going with React, you'll find that 90% of people using React also use Babel for JSX, and so 90% of the tutorials are written in JSX. It's totally possible to first learn how the translate between non-JSX and JSX, and to convert it in your mind, but it'll end up confusing you way more than just deciding to get Babel running. Whatever you do, DO NOT start from a boilerplate. These things are actually completely counterproductive to learning how things work. You'll end up with a huge mess of things you don't understand! The only time a boilerplate is really ever useful is if you're having trouble configuring some tool, and you check out a few boilerplates to see how they work. If you ever actually generate a new project from one, god help you. Not recommended. With that, again, build something simple with React and JSX by itself. Self-contained, one or two pages. Be careful, because trying to throw in all of ES6 once you get Babel up might be alluring, but see if you can get by with just using straight ES5 to begin with. If you can do this for a little while, it'll be much clearer where React ends and ES6 begins. Trying to learn them at the same time is possible, but it makes it a much slower process. As the project expands, add in React Router to handle routing. If it continues to get bigger, or once you feel comfortable, add in Browserify or Webpack with HMR and Live Reload to see how much it improves your development workflow. 3. If you want to learn Redux... Here I can't really help you. I honestly am not convinced at all that Redux is a tool 90% of teams should be using. In my opinion, it's one of the primary reasons why tutorials these days are so damn complicated. If you can get away with not using it, always do that. If you have to learn it, do it the same way, get all of the React fundamentals down first. And honestly, get a live reloading development environment down first too, because Redux generally involves creating tons of files and directories to stay organized. If at all possible, I recommend looking into Relay (from Facebook) instead. It's an equally challenging amount of boilerplate and new concepts to learn, since the API isn't as clean as Redux's. But once you get it working, you can literally completely forget about data-handling logic and the app will function exactly as you expect it to. It's much, much simpler to reason about and develop around. --- Hopefully something in there helps! As confusing as it can be, once you get the hang of React, JSX, ES6, and live development it's incredibly productive and easy to reason about, and you'll want to be using it everywhere. (Redux is sadly the opposite.)
- fiatjaf 10y agoReally? GraphQL? You don't need that. You don't even need React, there a ton of excellent frameworks based on the same React ideas (virtual dom, a single state, render everything from top to bottom) out there, and they don't come with all these fancy arrogant stuff (Webpack, Redux, Babel, ignore these).
- cloverich 10y agoReact doesn't come with those things either. React is just a view layer. If its confusing (to anyone) -- just use Facebook's getting started example and start building stuff. It'll all come together.
- fiatjaf 10y agoI know, but the React community almost forces you to use all these, if you're following any tutorial or guide, or even just asking help on some specific issue.
- numbnuts 10y agoArrogant?
- the_bear 10y agoI ran into this recently myself. I've been doing web development my whole career, but I never got into the complicated toolchain side of it. I just used a vanilla html/javascript setup and I would build out my own tools or manually include existing libraries as I needed them (no webpack, etc.) Then it came time to learn React and pretty much every tutorial out there requires a twisted combination of npm, webpack, babel, etc. just to get a simple page running. I just about gave up. Then I realized that you can run React without any of that stuff by just copying the first section of sample code from this page: https://facebook.github.io/react/docs/getting-started.html https://facebook.github.io/react/docs/getting-started.html So I started with that and built out my own simple framework. As I became more familiar with React and how it interacted with my own homemade framework, I was able to understand where all of the other pieces fit in, and gradually I've been including some third party tools that previously seemed insanely complicated to me (note: the toolchains still seem needlessly complicated, but at least I can generally get things to work now).
- philihp 10y agoExactly this. If you're just starting out, just do a simple page with only React. Very quickly you'll find there are problems with managing your page lifecycle, and you might imagine a good solution to it. That solution probably looks a lot like Redux. Then you might want some unit testing of your React components. Woo, that too has also has a satisfactory answer with Enzyme. Slowly, you will add more and more to your toolkit. Before you know it, you have scaled the frontend ivory tower. There is a rationale for all of this, but you shouldn't feel obligated to use any of it. You can save yourself a lot of headache down the line by starting with a project like React Boilerplate. Maybe you don't need 70% of the things in it? That's cool. Just start with it, build up the bits that you need using just 30% of it. Then maybe later, you want another 10% of it... it's already there, configured, and ready for you to use.
- andy9775 10y agoTo learn, I built it up little by little. Start with Babel, Webpack, express and react. Build something basic. Next add Redux then react router and finally server side rendering. You have to use various tutorials, read lots of docs and try and fail. In the end I found I had a better understanding of what was going on.
- fauria 10y agoI completely agree. One of the things I find more stressful is the lack of time to dive deep into new stacks while meeting deadlines and delivering on time. Maybe a side project would be helpful. I personally have considered implementing an MVP for a personal project using a stack I already know, and then gradually reimplement different parts with newer technologies. Having a solid set of integration / E2E tests would probably easy the transition and help overcoming the If it ain't broke, don't fix it feelings that might later show up.
- freyr 10y agoModern web development is a bit of a mess. My advice is to start small, and introduce new technology gradually. You should be familiar the foundation (HTML, CSS, and vanilla JavaScript) first, if you're not already. Be able to manipulate elements of a webpage using vanilla JavaScript. At this point, you might want to get up and running with Babel and the new language features introduced in ES2015, since more and more tutorials are written assuming you're using ES2015. Then pick one library or framework (e.g., React) and get comfortable with it. Think of a simple project to build, then try building one even simpler than that. Don't introduce a second technology (e.g., Reflux, Relay, etc.) until you have a handle on the first. And even then, try to introduce just one new technology at a time. You might be thinking that this will be a slow, involved process. That is correct.
- wrong_variable 10y agoAs a web developer who is not a 'web bro' React. Redux. Reflux. Flux. Relay. Does anyone else see the madness in this ?
- mikeryan 10y agoI think we see the early growing pains of a new ecosystem. React is great and a fantastic tool but by making it "just the 'V'" it opened up a lot of options and complexity in the ecosystem and Redux/Reflux/Flux/Relay each are trying to fill in the missing pieces. And yes it's hard to figure out and painful even for seasoned vets. But its getting better, the community seems to be settling on Redux for the most part over Flux/Reflux (Relay tries to solve a different problem). NodeJS web development is kind of in the same boat. There's still no clear "winner" in the framework wars there like Django/Rails. I don't know why these trends seem to be magnified in the JavaScript ecosystem but it's similar to the early days of Java web development in the late 90s early 00s (Struts anyone?).
- evan_ 10y agoAre you objecting to the names, or that they all exist?
- vectorpush 10y ago
- pbreit 10y agoThe current state of web development is a disaster, imo. All the Node, Angular, React stuff is pretty much unintelligible for mere mortals. Rails/Django much easier but a bit bloated. The average app/website is glorified CRUD so I don't really see why it has gotten so complicated.
- vectorpush 10y agoFirst you should think about what you actually want to build, then determine which features would benefit that type of application, from there you can consider the available tooling that facilitates the development of those features. The fact that you are overwhelmed by the "start from scratch" approach makes me think you are falling into the common front-end pitfall of reaching for popular tools that you don't necessarily need (yet). These tools should be the answer to specific problems, instead of being problems that need an answer for why you should be using them. If you find that you can't extract useful information from tutorials that don't match your exact stack, then its probably the case that you're taking on too much and don't really understand the context for why these tools were developed in the first place. You should learn to walk before you delve into the technical intricacies of augmenting your gait with a fusion powered exoskeleton.
- jakub_g 10y agoA pragmatic attitude of mine is: do not use anything that is less than a year old. Applies to frameworks, tools, programming languages, operating systems etc. You can break this rule if you really know what you're doing, and it's only one thing in the chain. But basing your whole product on a whole stack of work-in-progress stuff is madness, unless you like pain. Ok, React et al. are more than one year old, but still the whole ecosystems is not the best one to just start your webdev career from, due to complexity, lots of moving parts, breaking changes, etc.
- larksimian 10y agoMy suggestion is to go through some full-stack tutorials. Vary them up to learn how workflows with different library combinations/boilerplates feel for you. For React my quick and dirty intro a few months ago involved: http://jamesknelson.com/learn-raw-react-no-jsx-flux-es6-webpack/ http://jamesknelson.com/learn-raw-react-no-jsx-flux-es6-webp... and then following along with http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial.html http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial... The first link is very light on dependencies and brief. The second link is basically a mini-ebook going from front-end to back-end but walks you through the choices very well. What you want to do is build apps, so look for tutorials that make you build an app from start to finish. Do a number of those, semi-rotely, and you'll develop familiarity with the tools and methods they use. That's when you want to deep dive on specific libraries and stacks. Imagine how complicated it would be to try to learn Rails by learning ActiveRecord and then ActiveSupport etc. The interesting work happens when all the dependencies are combined -- and the challenge/beauty of the framework is how it combines them -- not when they are taken as individual libraries. Boilerplates are shitty, immature frameworks but similar principles apply.
- htns 10y agoThat's a good suggestion. The teropa.info post was very helpful for reintroducing myself to web development after not touching it since 2008. I hope I'm not scaring anyone from getting started by adding I also consulted typescript tutorials ;D
- afarrell 10y agoThe Teropa one is particularly good because it uses Test-driven development, which is a good way to keep yourself from going too far down a rabbit hole.
- deleted 10y ago[deleted]
- RichH 10y agoJust use clojurescript its simpler. By the time you have set up webpack you would already have a webapp in clojure.
- pritambarhate 10y agoI think ES-6 requires a lot of tooling support (because you need to support older browsers too) so it can be very complicated to set up for a new comer. If "learning React" is not your goal then I think learning, Prototype Based Object Oriented JavaScript, jQuery and Backbone.js can help you make almost any type of web application. I think learning core ES-5 JS is important, for anybody who wants to learn ES-6. Once you have done couple of applications with this stack, I think gradually picking up Babel and Gulp like tools and React wouldn't be that hard.
- dceddia 10y agoI've been writing about this a lot recently -- particularly with React, where do you start? I think your "start from scratch" approach is actually the right one, and the only caution I'd add is that you'll probably be tempted to "introduce dependencies" TOO EARLY. Everything out there will guide you toward adding everything at once, or ramping up too quickly. Many tutorials are "full stack," and so you're tempted to make your stack match theirs just to make it easier to follow. Add to that the groupthink around the idea that you really need React+Redux+Webpack+etc+etc+etc to build anything of any meaningful size, and you're stuck with a lot of pressure to add more than you need, before you need it. Oh, and nobody really says "wait until X happens before you add Redux," it's much fuzzier than that, more like "you'll know it when it happens." Great. I wrote an article just the other day about this learning process: https://daveceddia.com/timeline-for-learning-react/ https://daveceddia.com/timeline-for-learning-react/ A key to the process is building a bunch of throwaway apps, I think. You don't want to dive in and try to build a full-stack app. Too many moving pieces, even if you're adding them one at a time. They're all independent libraries, right? That's what everyone keeps saying anyway. So why not just learn "pure React" (no Redux, no backend) first: get it down rock-solid, and THEN add one more library to the mix. Build a few small apps, add another. Eventually you'll know the whole stack cold, but not if you start with a shaky foundation.
- tunaoftheland 10y agoMany have already added excellent comments, and here's mine, as someone who's recently worked on a project with React + Redux + ES6 (Babel5 -> 6) + WebPack, etc.: Start simple and refactor the application as you add the other libraries gradually. In your particular case, forget everything else except React and ES5. It won't take long to understand what props and states are in React and to get used to the idiosyncrasies of JSX. You might even want to start out by kicking around in JSFiddle or JS Bin. The other tools are very useful, but they won't be so until you see the need for them, Make notes of which parts you find annoying with the simple setup and turn to see the tools you listed to see if/how they will help you. Kinda changing gears into a diatribe about the crazy ecosystem in the JS-land: I feel that there are several subsets of it that have been rising above the rest to give developers the productivities that they need. It's not clear-cut and there are many valid options, plus even more subspecies within those options. Several of them could be well-suited for the task at hand, so I wouldn't worry too much about making the wrong choice and paying heavy price for it. The way I see it, frontend development scene is tough if you have not already been immersing yourself in it for a while. It is like that now and it will be for immediate future. The good news is, it is getting better, and I think we will see the community gradually converging toward several collections de facto standards. It will remain amorphous, but not as overwhelming, I think.
- bdavisx 10y agoI think it was Dan Abramov (the creator of Redux and quite a few other things in the React ecosystem) said to start with React only; then, when your application gets complex enough to need other things (Router, Redux, etc.), you'll know it. And you'll know it because by starting simple, you won't get overwhelmed - and you'll build up the knowledge you need to move to the next level. As for where to start, either here for "text" only: https://facebook.github.io/react/docs/tutorial.html https://facebook.github.io/react/docs/tutorial.html OR here for video: https://egghead.io/series/react-fundamentals https://egghead.io/series/react-fundamentals (although I think it may require a subscription).