17 ms·
React.js Introduction for People Who Know Just Enough JQuery
- jozan 11y agoThis is neat! Thanks for sharing.
- chibicode 11y agoThank you for reading!
- iamflimflam1 11y agoReally great tutorial - would be good in the next steps to talk about getting webpack setup etc..
- chibicode 11y agoThanks! I definitely should put more in the next steps, like examples/talks/etc. I wanted to ship this asap :)
- iamflimflam1 11y agoShipping - for some reason in my day job I can ship to almost any deadline. Side projects - one day I'll finally finish one...
- insin 11y agoThe SurviveJS book is a good reference for this: http://survivejs.com/webpack_react/ http://survivejs.com/webpack_react/
- chibicode 11y agoI'll add a link to it :)
- TheAceOfHearts 11y agoNot a walkthrough or guide, but I setup a boiletplate [0] that covers all your bases for development, production, and testing environments. I wrote about it a bit here [1]. Unfortunately... It does kind of assume you're familiar with CommonJS and a bit of the ecosystem. [0] http://github.com/cesarandreu/web-app http://github.com/cesarandreu/web-app [1] https://blog.cesarandreu.com/posts/a_reasonable_starting_point_for_building_a_web_app https://blog.cesarandreu.com/posts/a_reasonable_starting_poi...
- tracker1 11y agoI think this article demonstrates very well why I think React should be the first choice for any new web projects... what to go with it (ember, flux (and related), or other) is open to more debate. Of course there are great alternatives with similar workflows (mercury, etc).
- chibicode 11y agoYup, React does one thing, does it right, and does the right thing :)
- DigitalSea 11y agoI think this sums up React.js perfectly. Easy to learn and build something with, but the discussion around Flux and what libraries to use to implement it can complicate and deter newbies. The official explanation of Flux on Facebook's own site I think does a poor job explaining it in a way most developers (new and senior alike) can understand.
- tracker1 11y agoThat's very fair, it gets even more complicated when trying to do server/client mixed rendering with it. It's all very hard to grasp in a deeper level. This tutorial is absolutely awesome.. and I think the deep dive is worth it for larger apps too.
- radiospiel 11y agoThis is really neat.. one thing though: there is nothing magic about 'the "magic" state'; it would IMHO be better to just call it state (or inner state, or so), and to explain that once the state is changed react rerenders the component automatically.
- chibicode 11y agoYup, I agree... will fix! Thank you!
- aprdm 11y agoReally well written, as a backend developer who has been playing a little bit with frontend lately this hits the sweet spot :) Cheers
- chibicode 11y agoAwesome :) Glad to hear that!
- zamalek 11y agoConsumable content aside, I absolutely love the format of the tutorial. It's significantly more pleasant to dig into compared to what seems to be the more common tutorial format (e.g. [1]). Good work. [1]: https://tour.golang.org/welcome/1 https://tour.golang.org/welcome/1
- chibicode 11y agoThank you so much! :) I also found that a blog format is much easier to consume than a REPL/in-browser editor based one.
- DanSmooth 11y agoIt is, but the tutorial could have made good use of pagination or anchors, so one could bookmark where one has left off. Also: What's the deal with "the cow above"?
- krat0sprakhar 11y agoI think thats a joke on the cow printed on the ORielly book (also about React)
- chibicode 11y agoYes, I am going to implement pagination next (with React)!
- hodwik 11y agoThat's really funny, I'm always lamenting that I can't find tutorials as nice as the golang tour for other languages.
- zamalek 11y agoI find the prose format nicer because it's easier to keep going, but the Go REPL has more information density. Guess it comes down the preference.
- toxickg 11y agoGreat job, man! You make some strong points here that clearly reflect the important differences of these two approaches! Well done!
- chibicode 11y agoThank you :) !
- sancha_ 11y agoThank you, great intro to react. Easy for me as a backend dev to follow and get a grasp of React. One thing, the page loaded constantly itself, after reading half through the tutorial (3-4 minutes), I had about a hundred entries for the same page in the tab history. This makes the website aweful.
- chibicode 11y agoThanks and oh no, do you know which browser/OS you're using? Not sure if it's the JSBin thing... Edit: I think it has to do with JSBin. I reported the issue here: https://github.com/jsbin/jsbin/issues/2464 https://github.com/jsbin/jsbin/issues/2464
- ases 11y agoI'm getting this issue as well. Using Firefox 39 on OS X.
- chibicode 11y agoWill investigate! Sorry about this. Edit: It might have to do with JSBin. I reported it here: https://github.com/jsbin/jsbin/issues/2464 https://github.com/jsbin/jsbin/issues/2464
- sancha_ 11y agoFirefox on OSX, version 39.
- chibicode 11y agoWill investigate! Sorry about this. Edit: It might have to do with JSBin. I reported it here: https://github.com/jsbin/jsbin/issues/2464 https://github.com/jsbin/jsbin/issues/2464
- falcolas 11y agoSafari, OSX
- philliphaydon 11y agoAs someone who knows Angular and Knockout. I found this great. Because react is a different way of thinking IMO that most tutorials I read were not easy to get up and running so I just threw in the towel and forgot about react. Most people make too many assumptions on the skill level of the reader (myself included when I blog) and it can be frustrating. Thanks.
- chibicode 11y agoThank you :) Totally agree, I knew Angular coming into React and it threw me off quite a bit as well.
- noir_lord 11y agoAgreed, I've built some pretty big and complex UI's with Knockout.js and this was an excellent guide into something else. Really well written as well.
- WorldWideWayne 11y agoKnockout.js is my favorite because it doesn't make me hack my HTML documents into pieces if I don't want to, but if I want to, it lets me make web components that work all the way back to IE6. I also like that it doesn't require anything beyond normal HTML to make templates and it doesn't require learning some huge framework just to bind a simple data-set into the page. You can also read through the entire code-base in an afternoon.
- woah 11y agoI worked on a project with around 20 developers using knockout (with two lead developers essentially writing their own framework as we went) and it was a ridiculous mess. I think it can be a good tool for prototyping, but it is horrible on a large app. You're always changing some observable and having something far far away break completely. React with immutable.js is much better because you really can focus on one component at a time in complete isolation.
- gedy 11y ago
- orheep 11y agoI see the point but noone in their right mind would write the javascript like that. When written better it's a good amount shorter than the React solution. http://pastebin.com/wbGZZs7U http://pastebin.com/wbGZZs7U
- chibicode 11y agoI totally agree, in fact I'm going to link this :) The point I wanted to make is that every feature requires a bit of refactoring like this, whereas React puts some structure.
- ups101 11y agotrue, but to be fair, you'd probably also want to introduce variables like $addPhotoBtn, $tweetBtn, $textLengthLbl, etc, to avoid css queries on every keyboard change. That would add to solution length and also introduce a bind-step to avoid stale variables after a dom change. Also, there's the authors very well-placed point that adding a new feature may lead to css query refactoring, eg. when $("textarea") doesn't cut it. I find html refactorings to be nb 1 cause for breaking progressively enhanced solutions like this one, probably bc I suck at naming elements. Lastly, it should be noted that this refactored solution does not contain all the features of the final react solution.
- SlashmanX 11y agoMakes more sense to me to have the "Tweet" button enabled by default and disabled on load by JS. If there's an issue with the JS or it's disabled in the browser or whatever, the button should still work (with server side logic to catch empty Tweets). Right now, if the JS doesn't load you can't Tweet at all. Just a small nitpick I had after thinking about the reasoning behind why the OP had disabled the button in JS rather than the HTML in the first place.
- orheep 11y agoI see the point but noone in their right mind would write the javascript like that. When written better it's a good amount shorter than the React solution. http://pastebin.com/wbGZZs7U http://pastebin.com/wbGZZs7U
- jarnix 11y agoComparing jquery to React (or Angular/Aurelia/etc) is obvious but the article is great for beginners though.
- arenaninja 11y agoI'm excited for ReactJS catching fire. I've been using a lot of it lately, and most recently I had to go back to a set of components I built to add functionality. In total, the front-end took maybe 20 minutes: no fishing around for the right selector or clashing functions. Just "here's a new button, attach this event"
- pjmlp 11y agoMy web experience is mostly custom in-house web frameworks, JSP, JSF, WebForms, jQuery and basic Angular. It was a nice overview of React to me.
- rashthedude 11y agoBeautiful article man.
- ifdefdebug 11y agoMaybe slightly off-topic, but the tutorial page adds entries to my (Firefox) back button as I scroll down. So when I tried to "back" to HN, nothing happened. Second, third back, nothing happened. Opening the back list, a dozen or so entries and they all do nothing. I think this kind of design should really be avoided, it breaks my user experience.
- bbarn 11y agoYeah, I'm really getting tired of this "You just changed pages and didn't know it" pattern I'm seeing more and more. I'm not sure why people want to have this single page app at all costs, but if you want the single page app, than a single click of "back" should work.
- BinaryIdiot 11y agoI think there is value in doing single page apps but mostly for web applications not really for just a website. Still I completely agree that breaking the back button needs to be avoided.
- azernik 11y agoI think a more useful distinction is - mess with back-button history if and only if the user perceives a page transition regardless of if the location bar changed it there was a page load.
- jmkni 11y agoWaow that sucks, they don't even update the URL with anchor links!
- radnor 11y agoIt's a bug with JSBin and/or the browser. https://github.com/jsbin/jsbin/issues/2464 https://github.com/jsbin/jsbin/issues/2464
- pkhagah 11y agoNot really justifying history modification. But, if don't know, you can long click back button and press some random page in history stack to go to.
- Omnipresent 11y agoThat is a truly impressive tutorial. Just curious, how much time did you spend on putting it together? Additional props for doing it being a dad!
- chibicode 11y agoA few hours every night for a week :) But I'm not a dad, haha.
- k__ 11y agoGood article. Needed it two weeks ago :D I did 4 years ExtJS and 1 year Ember. React was totally different but rather nice to work with. The API surface is so much smaller.
- Grue3 11y agoCan React use separate HTML templates? I find this style of mixing markup and Javascript super-ugly.
- jon-wood 11y agoDone right you don't really do a lot of mixing markup and Javascript - you'll have a render method which takes your components current state and turns it into markup, with everything else being straight Javascript. There are ways to avoid it, but I'd encourage you to give it a while before looking for a way out, because almost everyone I know who had that initial reaction has come round to it.
- wangii 11y agoI had exactly same feeling when I first saw it in 1 min: it's ugly and why the hell folks get excited by integrating template into javascript? Please keep reading! It's really more than that! I wasted 2 years by not spending 20 more mins.
- akhilcacharya 11y agoWow, this is exactly what I needed.
- moonchrome 11y agoOK I may be off point here - but why do people who know just enough JQuery need to know about React ? Wasn't React developed as a tool to manage complex data flow patterns inside of a big web app like Facebook ? Why does your average JQuery developer need to know or care about this whole new abstraction layer ? Even though I've seen it a 100 times by now I'm still amazed by how fad driven programming culture is and I feel like this is a perfect example : React - come learn this complex peace of technology to solve problems you never had (and probably never will).
- wil421 11y agoIts aimed at JS beginners, a lot of us started with simple web development picked up some JQuery and are looking for something more powerful. This looks like a great segue to building rich front-ends. In fact if you look at the URL the site is called reactfordesigners.com.
- moonchrome 11y ago>In fact if you look at the URL the site is called reactfordesigners.com. You would want your designers to write frontend code that is complex enough to require React ? The way I've worked with designers is they create sketches and prototypes just to demonstrate the concepts with whatever they are familiar with and then developers turn that in to actual maintainable code with feedback.
- deleted 11y ago[deleted]
- pcr0 11y agoThe title says > React.js Introduction for People Who Know Just Enough JQuery to Get By Unless you're working at a really big shop, designer these days is almost synonymous with UI/UX engineer or front-end engineer. Considering the target audience is JQuery users, React is not too far of a jump and doesn't have to be restricted to "complex" websites.
- Omnipresent 11y agoIs React meant to replace Ember/Angular type of frameworks? Can React also connect with backend APIs to fetch JSON and present them on the frontend? I've been waiting to nosedive into Angular2 (when its out), is React a better alternative to get started with?
- liamzebedee 11y agoReact certainly replaces Angular as a View+Controller framework (idk about Ember, although I know there's been work on integrating the performance benefits of Virtual DOM). In scenarios with complex interactions, something like Flux is desirable, however small web apps work fine with simple JSON REST APIs.
- ergo14 11y agoI'm more interested to see if polymer/x-tag/webcomponents will replace react/angular/other stuff.
- vcarl 11y agoReact will probably just integrate those as they become usable, since React acts as a layer of abstraction between the DOM and your presentation logic.
- k__ 11y agoPeople are already trying it. https://github.com/Wildhoney/ReactShadow https://github.com/Wildhoney/ReactShadow
- marknutter 11y agoNot so. React does not really play well with web components. Currently React has to internally define JSX elements for every known HTML element that's out there, namely to track internal state and respond to events (i.e. input fields). Because they won't be able to do the same for the vast ocean of web components that will be authored in the coming years, it will be difficult to provide clean interop with new custom elements. The React maintainers have even stated that they don't believe web components are the right way forward for web application development. React was never designed to work well with web components in the first place. On the other hand, the main reason why Angular 2.0 is such a drastic rewrite is because they needed to do it in order for Angular to work seamlessly with Web Components. It's no coincidence that both Angular and web components are Google initiatives.
- paaaaaaaaaa 11y agoI have looked at react.js a couple times after reading more and more buzz about how fantastic it is. However I'm instantly turned off of switching to it when I read that HTML (which isn't HTML and is actually something called JSX) goes in your js files. With angular I can keep all my HTML in my HTML files. Is this normal or am I completely missing something?
- mandazi 11y agoI too find that unusual. I feel it's hard to maintain the HTML when it's int he JS.
- zecho 11y agoThis is a good tutorial for people who think the React way is weird. http://courseweb.lis.illinois.edu/~hkim214/lis514/img/Dr_Seuss_Green_Eggs_and_Ham.gif http://courseweb.lis.illinois.edu/~hkim214/lis514/img/Dr_Seu...
- revskill 11y agoYes, i think you miss something important here. It's a tradeoff. You should make your choice based on pros and cons, it's more objective than subjective when you hate something and you don't use it. It's harmful and useless thought:)
- insin 11y agoYes, this appears to be the normal reaction to JSX (it took me 3 months to actually try React just because of the idea of it - more fool me). My advice is to try it at least to the point where you've created a couple of components and rendered one inside the other. A component manages everything to do with how it works with props it's given and the state it manages, and how it renders is just another part of that concern. One of the nice pros you get used to quite quickly is having your editor autocomplete event handler and data variable names, as they're all right there in the same file. JSX is just sugar for React.createElement() function calls, the syntax of which otherwise gets quite unpleasant to write and maintain once you start nesting them to any degree (ask anyone who's used a DOM builder library for a complete app).
- FloNeu 11y agoIf you must compare Angular with React, then at least compare it to ReactJs+Flux+more or Angular-Templates with React-Templates. React is more like the view-lib of a framework. I like them both (also ember, knockout, backbone) and unfortunately think the battle isn't decided yet. Will take some time if ever... Complain to Steve Jobs(1), for killing Flash/Flex, as you could to client-side apps with desktop performance, without the hassle of Cross-Browser testing and so on... In my opinion the concepts of Angular and React+Flux are heavily based on the features this platform provided. (1) IMHO the Only good thing he ever did (for the web), as it forced the proprietary software out... but led to the great Framework-War :) P.S.: Also Actionscript 3 was ECMAScript(Javascript) plus Classes, Types and more... ( I wondered about which Version that was latly and found out they implemented ECMAScript and extended it with features requested by users.)
- starikovs 11y agoBTW, if you use Backbone you can simply use React as a View.
- dahjelle 11y agoShameless plug: I wrote my own React introduction—geared more for people that know some JS and HTML, but not necessarily any other JS libraries. More specifically, it very gradually builds up from rendering a single JSX tag to enough components, state, and props to build React's to-do example. I found React has an unusually gradual learning curve—you can really build up concepts bit-by-bit. EDIT: As per usual, I forgot the link: https://github.com/dahjelle/Programming-Worksheets/blob/master/React.js/IntroductoryReact.markdown https://github.com/dahjelle/Programming-Worksheets/blob/mast...
- thirdtruck 11y agoThanks. I was very much in need of this, especially with so many companies expecting React expertise of new hires these days.
- dahjelle 11y agoGlad to hear it! Very open to contributions/suggestions!
- vezzy-fnord 11y agoSpeaking as someone not intimately involved in the web development community, React looks decent but absolutely not worthy of the obscene amounts of hype it received... unless what web devs had before was really that horrible, because that's the impression I got. Though from what I can tell, jQuery and React are somewhat orthogonal tools, as I have used the former and it goes beyond rendering views. What I cannot figure out is all the harping on about "functional style". The React examples all felt more Smalltalk-ish to me than anything else (I suppose unsurprising given JavaScript's vague influences from Self). The use of closures doesn't really change the conceptual patterns much. Is it because the tutorial can only cover so much ground, or is it that since some of the primary buzz around FP was the management of mutable state, to the point that people now instinctively associate the idea with FP?
- xixixao 11y agoBefore React: to make a transition, let's change this, this and then that, mutating state on every step. After React: have one pure function, which takes as input the current state and produces the desired output. This is the main shift. It's very similar to how imperative programming is done in Java vs Haskell.
- vezzy-fnord 11y agoAre they pure? I don't think JS has any way to guarantee referential transparency, though of course the use of a virtual DOM can mitigate side effects by having well-defined behavior. Furthermore, the input-process-output model can hardly warrant being called "functional" in of itself, unless you really want to overload the term. The React way of independent handlers that trigger events which incrementally calculate state and update views, is, in fact, quite similar to how Smalltalk UI paradigms work, right down to the installation of an event handler resembling a message send operation. If you don't believe me, check out the Morphic framework that Self uses to implement its environment UI. The similarities are striking: http://handbook.selflanguage.org/current/morphic.html http://handbook.selflanguage.org/current/morphic.html
- 11y ago
- curiousjorge 11y agoam I the only one fine with using just jQuery and ajax? I've written a chrome extension with 4k lines of code and I never had any problems. Instead of breaking things into separate classes and components, I just put them in separate files or in logical sequence. I'm sure this can get a lot messy with more than one developer but so far my projects, I almost always just use some jQuery library or plugin that does 80% of what I want to do and hack the rest.
- peacemaker 11y agoNope, you're not the only one I agree completely. I'm tired of what seems like an endless supply of new, mega-hyped frameworks that seem to provide only marginal improvements. I'll take the time to learn something new when it is truly groundbreaking but until then I care more about the end product than what was used to make it.
- BinaryIdiot 11y agoThere are dozens of us! Dozens! In all seriousness I typically work with a lot of designers; asking them to update markup in JSX versus HTML is simply not possible. It's not because they can't figure it out but it makes it more difficult for them to quickly test and they typically break JavaScript in many, unexpected ways. While I'm fine with the UI and business logic separation where UI can contain markup _and_ scripting, I don't think the answer is this awkward solution of shoving HTML into the scripting.
- thoman23 11y agoThis is what worries me. We are using Angular, and my non-technical co-founder knows just enough HTML and CSS that she makes a very useful contribution to our front-end development. Sometimes the contribution is in the form of HTML mockups produced outside of our app that are easy for me to port over, and sometimes it's direct contributions to the codebase. I worry that if I went the React JSX route that it would be much harder for her, or pure designers that we might hire, to meaningfully pitch in.
- 11y ago
- michaelbuddy 11y agoI haven't gone through this page yet, but thank you for at least the attempt at reaching somebody in my state of affairs. Front End work is very hard. The front end design & what I would call the back-end front-end disciplines are supposed to meld together according to job postings and over-zealous recruiters, but it's a good deal more complex than I have been willing to put up with, mostly because of the materials to get started and the unintuitive tools that people who know what they are doing swear by. Imagine being solid at design, pushing pixels, using HTML, CSS. Then suddenly these program frameworks which are created by back-end programmers not visual designers appear and the ramp up for the average technical person is immense. For me it's been enough to turn me off them all together and make it a talking point that "my javascript skills fall off at X,Y or Z" so recruiters and employers know that despite being able to do a lot, I can't suddenly become everything UI and everything back end just because the title of anything "front end" is so versatile.
- thirdtruck 11y agoI feel your pain. Job expectations for front-end work (and, no doubt, other tech areas) have grown terribly incoherent. It seems like a lot of companies expect new hires to train themselves into unicorns on their current employer's time, when they could just hire someone now and give them a decent amount of time to ramp up instead.
- michaelbuddy 11y agoI think for the needs of front end, the recruiting world would be better off targeting back end people heavy programmers, maybe .net or java and their migration to the front end frameworks will be much easier than the designers will be. It sounds awesome for a designer to pick up javascript and just run with it, but I personally see a pretty thick wall between focusing on design, graphics, presentation and then solving all the programming problems to go with it. Again personal experience, it's been easier for me to shut off the valve of code completely, so I'm not distracted by consequences of how it will be built. I know that sounds counter intuitive but just knowing some of the avid javascripters, those who can build apps with it, they don't really have the ability to get out of that mode to design something, they are always living the framework. They will make something nice, but alone their work rarely surpasses the level of beauty or refinement of a really good designer artist. Yes I know those hybrids exist, but unfortunately there aren't nearly enough of them to fill all the positions. Not only that, but I'd argue that a lot of them who are hybrids, you're not going to get their best work from both areas if they are expected to deliver from both disciplines on projects. Not on the deadlines that employers will set at least. And I suspect a similar problem exists in actual building architecture. Yeah some building designers are good at accomodating for all the variables of planning codes, but they aren't going to be (nearly as often) fantastic at aesthetics that somebody who works outside those constraints might be capable of. There's a lot of value in designing first, then put those styles of thinking together (designers and architects) separate people and from that point later in the process of creation you start solving the challenges like plumbing codes, metallurgy afterwards. Part of this is me complaining, but it's my attempt at experience of always being a crossover person and how you never really feel like you're honing a craft, you just feel like you're being left behind and not properly cultivating what you enjoy most.
- sgrove 11y agoAlso interesting to see the pitch on "ClojureScript is a Product Design Tool"[0], written by Precursor's designer. A lot of this stuff can be made more accessible for designers and FE developers who don't want to have to deep dive into all the new-fangled frameworks. [0] https://precursorapp.com/blog/clojure-is-a-product-design-tool https://precursorapp.com/blog/clojure-is-a-product-design-to...
- blhack 11y agoCan somebody explain to me what is so bad about jquery? I use jquery every single day to make web pages do the things that I want them to do. But my javascript hipster friends all claim that this is wrong and stupid and that I shouldn't use jquery because of some abstract reason that nobody ever seems to be able to articulate to me.
- joshcanhelp 11y agoMy $0.02 ... There's nothing wrong with just using jQuery. For many, many applications/projects it's a great tool and does everything you need. What happens as a project/app/site grows is that you add more and more and more jQuery to a single file and it starts to get hard to maintain (hard to find what you want, hard to change something without something else blowing up, hard to navigate the files you're using). Frameworks like React, Backbone, Angular, etc were made to drive large, complicated, often single-page applications where you have massive amounts of interacting code and want to generally simplify what you're writing and how it's architected. So, in the end, these are meant to help you organize code, be more productive, and have a more coherent architecture. That's the idea, at least. The tweetbot example here is simple because you're just learning so, if this is the only thing you're building on a page, it probably makes more sense to just use jQuery. I think the typical road from jQuery-only to using a framework is your apps get bigger and you start to think "this is hard to maintain." Then you see an example of a framework doing something that would really help your process and see how it could improve the code you're writing. You try it out, it makes the process easier/more enjoyable, and you continue learning more. Or it doesn't and you swear it off. AFAICT, these frameworks grow out of a person or team that figures out a more productive way to write code for what they're working on. That becomes a boilerplate they use, then grows into something they think would help others out. Then it gets a name and we all argue about it. In the end, it's just one person's/team's/company's idea of how to write code better, which may or may not work for other people/teams/companies.
- wging 11y agoThere are two arguments that could be made. 1: you can do without jquery, and therefore you should. if all you need is $('#my_id') then it's overkill and it's better to save on download speed by leaving jquery out. See http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ That said, jquery is a powerful tool and it's widely used for a reason. 2: unrestrained use of jquery, if it's your only tool, can lead to code that is hard to understand, and easy to get wrong. if any part of your code can modify any part of your page, then it is a good idea to retreat from that and be careful/organized about what you do, and when/where you do it. that organization is what JS frameworks try to help with. you may or may not find your life is improved by such frameworks, depending on what you're doing.
- hit8run 11y agoSorry but nowadays I feel that jQuery is like php for the frontend: people get results fast but the average code quality is so shitty. Why on earth is jQuery used for things that normal js can do instantly? There are so many libs out there based on jQuery even though this dependency is absolutely unnecessary. I might sound arrogant but people should get an understanding for JavaScript and learn how to use it before stacking layers of abstraction. Ajax with normal JS for example is not so hard. One doesn't need all the fancy angular/jQuery/whatsoever helpers. If one knows the basics it's okay to use some convenience stuff from time to time but I feel that so many low quality devs are solely relying on their precious xxx kb libs just to display a simple hello world.
- eastbayjake 11y agoI'm totally with you that jQuery is a crutch for a lot of devs, but it's also the easiest way to ensure backwards compatibility for IE 6+. If you have enterprise customers who refuse to upgrade it's probably the most stable way to support them while leveraging the power of modern browsers for enlightened users who have them.
- hit8run 11y agoGood that you mention this point. This is for me the main reason to use jQuery in a project: backwards compatibility. I am gladly in the position where I make my own business decisions and so I choose which browsers I want to support. That said I totally refuse to support super-old browsers like IE6. I even refuse to support IE9. If someone has trouble using a site built on modern standards: Go get a modern browser. If it looks shitty on your old IE6 then don't blame me.
- digitalsushi 11y agoI have a friend with a web publishing business. She uses guess and check with text edit copy/paste to build websites for clients. I've shown her the console log countless times and she always rolls her eyes when I extoll its value. She makes 50% more than me, has cash in the bank, and loves her life. All I have is picking on her javascript. And I'm not even really any good at it. I think there's no reason to be correct when your goal is to buy food and pay rent.
- hive_mind 11y agoGreat concept (tutorials for people who know just enough JQuery). Would love more tutorials (for Angular, e.g.) for such people. TodoMVC was a great effort. But unfortunately, the actual Todo creations are not well documented (for beginners to figure out how and why certain things were done).
- sergiotapia 11y agoThis is the first React article I read where it actually compares and contrasts the jQuery approach and the React approach. I feel like React makes sense now, even though writing my HTML inside JS still feels off.
- rashthedude 11y agoWould you be open to the idea of writing something similar for React Native if you are interested and/or find the time?
- marcamillion 11y agoThis tutorial is awesome! I love the tone and how it knows EXACTLY who it is written for. This may be a bit late, but I would LOVE for someone to do this for JS in a Rails App (or even CoffeeScript). I am desparately searching for good tutorials for people that are "borderline-decent" at jQuery but are Rails devs. I can't find any. I understand, in theory, how to render some JS on a view and all this good stuff - but once you go into creating a UI that feels like a modern UI with lots of lil AJAXy elements...it can become a pain REAL quick with a bunch of `...js.erb`s all over the place with no seeming pattern to them. So I would love if someone had a tutorial just like this, for how to create a simple and sexy app that looks like an Angular/Ember app but just using CoffeeScript/jQuery/vanilla JS. Anyone know of any such thing?
- boundlessdreamz 11y agoI think the problem lies in the '.js.erb'. Write javascript in separate javascript files (in app/assets/javascripts/) and use JSON to get data from the rails backend. Have you seen this? http://todomvc.com/ http://todomvc.com/ You can try implementing a backend in Rails for the jquery example. https://github.com/tastejs/todomvc/tree/gh-pages/examples/jquery https://github.com/tastejs/todomvc/tree/gh-pages/examples/jq.... The JS file shows how to organize javascript code - https://github.com/tastejs/todomvc/blob/gh-pages/examples/jquery/js/app.js https://github.com/tastejs/todomvc/blob/gh-pages/examples/jq... Also unless you really like coffeescript, stick with javascript. If the syntax is bothering you, you can write in ES6 (next version of javascript) which has nicer syntax and use babel to convert to ES5 1. https://gist.github.com/danielgtaylor/0b60c2ed1f069f118562 https://gist.github.com/danielgtaylor/0b60c2ed1f069f118562 2. http://justicen.com/#/posts/74046fea9a4c61477db9 http://justicen.com/#/posts/74046fea9a4c61477db9
- marcamillion 11y agoI hadn't seen todomvc but it doesn't quite address my issues. It still feels too disconnected from where I am. Also, I do write JS in separate JS files - but my understanding is that when you want a response to be in JS, don't you have to use a corresponding `...js.erb` file to handle the action/response? How else would you update the DOM after the action has been completed?