small_Fcsqb5pWQAAzPIK.jpeg

thumbnail_Fcsqb5pWQAAzPIK.jpeg

Adobe acquires Figma, cue the memes 🤪

large_Crossover Series NFTs.png

medium_Crossover Series NFTs.png

small_Crossover Series NFTs.png

thumbnail_Crossover Series NFTs.png

From Photography to NFT Art: Twisted Digital Landscapes with Nate Hill

Still can’t get a UX job? Give up.

large_featuredImage

medium_featuredImage

small_featuredImage

thumbnail_featuredImage

Sticking to UI/UX trends is a losing strategy

<a href="http://ift.tt/2oSQ7q8">CSS-Tricks</a> | Chris Coyier 
You know when a project needs HTML and CSS, because it&#8217;s all of them. When you reach for JavaScript is fairly clear: when you need interactivity or some functionality that only JavaScript can provide. It used to be fairly clear when we reached for libraries. We reached for jQuery to help us simplify working with the DOM, Ajax, and handle cross-browser issues with JavaScript. We reached for underscore to give us helper functions that the JavaScript alone didn&#8217;t have.
As the need for these libraries fades, and we see a massive rise in new frameworks, I&#8217;d argue it&#8217;s not as clear when to reach for them. At what point do we need React?

I&#8217;m just going to use React as a placeholder here for kinda large JavaScript framework thingies. Vue, Ember, Svelte&#8230; whatever. I understand they aren&#8217;t all the same, but when to reach for them I find equally nebulous.
Here&#8217;s my take.
<h3>✅ Because there is lots of state.</h3>
Even &#8220;state&#8221; is a bit of a nebulous word. Imagine things like this:
<ul>
<li>Which navigation item is active</li>
<li>Whether a button is disabled or not</li>
<li>The value of an input</li>
<li>Which accordion sections are expanded</li>
<li>When an area is loading</li>
<li>The user that is logged in and the team they belong to</li>
<li>Whether the thing the user is working on is published, or a draft</li>
</ul>
&#8220;Business logic&#8221;-type stuff that we regularly deal with. State can also be straight up content:
<ul>
<li>All the comments on an article and the bits and bobs that make them up</li>
<li>The currently viewed article and all its metadata</li>
<li>An array of related articles and the metadata for those</li>
<li>A list of authors</li>
<li>An an activity log of recent actions a user has taken</li>
</ul>
React doesn&#8217;t help you organize that state, it just says: I know you need to deal with state, so let&#8217;s just call it state and have programmatic ways to set and get that state.
Before React, we might have thought in terms of state, but, for the most part, didn&#8217;t manage it as a direct concept.
Perhaps you&#8217;ve heard the phrase &#8220;single source of truth&#8221;? A lot of times we treated the DOM as our single source of truth. For example, say you need to know if a form on your website is able to be submitted. Maybe you&#8217;d check to see if <code>$(".form input[type='submit']).is(":disabled")</code> because all your business logic that dealt with whether or not the form could be submitted or not ultimately changed the disabled attribute of that button. So the button became this defacto source of truth for the state of your app. 
Or say you needed to figure of the name of the first comment author on an article. Maybe you&#8217;d write <code>$(".comments &gt; ul &gt; li:first &gt; h3.comment-author).text()</code> because the DOM is the only place that knows that information.
React kinda tells us: 
<ol>
<li>Let&#8217;s start thinking about all that stuff as state. </li>
<li>I&#8217;ll do ya one better: state is a chunk of JSON, so it&#8217;s easy to work with and probably works nicely with your back end.</li>
<li>And one more even better: You build your HTML using bits of that state, and you won&#8217;t have to deal with the DOM directly at all, I&#8217;ll handle all that for you (and likely do a better/faster job than you would have.)</li>
</ol>
<h3>✅ To Fight Spaghetti.</h3>
This is highly related to the state stuff we were just talking about. 
&#8220;Spaghetti&#8221; code is when code organization and structure has gotten away from you. Imagine, again, a form on your site. It has some business logic stuff that specifically deals with the inputs inside of it. Perhaps there is a number input that, when changed, display the result of some calculation beside it. The form can also be submitted and needs to be validated, so perhaps that code is in a validation library elsewhere. Perhaps you disable the form until you&#8217;re sure all JavaScript has loaded elsewhere, and that logic is elsewhere. Perhaps when the form is submitted, you get data back and that needs logic and handling. Nothing terribly surprising here, but you can see how this can get confusing quickly. How does a new dev on the project, looking at that form, reason out everything that is going on?
React encourages the use of building things into modules. So this form would likely either be a module of its own or comprised of other smaller modules. Each of them would handle the logic that is directly relevant to it. 
React says: well, you aren&#8217;t going to be watching the DOM directly for changes and stuff, because the DOM is mine and you don&#8217;t get to work with it directly. Why don&#8217;t you start thinking of these things as part of the state, change state when you need to, and I&#8217;ll deal with the rest, rerendering what needs to be rerendered.
It should be said that React itself doesn&#8217;t entirely solve spaghetti. You can still have state in all kinds of weird places, name things badly, and connect things in weird ways. 
In my limited experience, it&#8217;s Redux that is the thing that really kills spaghetti. Redux says: I&#8217;ll handle all the important state, totally globally, not module-by-module. I am the absolute source of truth. If you need to change state, there is quite a ceremony involved (I&#8217;ve heard it called that, and I like it.) There are reducers and dispatched actions and such. All changes follow the ceremony.
If you go the Redux road (and there are variations of it, of course), you end up with really solid code. It&#8217;s much harder to break things and there are clear trails to follow for how everything is wired together.
<h3>✅ Lots of DOM management.</h3>
Manually handling the DOM is probably the biggest cause of spaghetti code.
<ol>
<li>Inject HTML over here!</li>
<li>Rip something out over here!</li>
<li>Watch this area for this event!</li>
<li>Bind a new event over here!</li>
<li>New incoming content! Inject again! Make sure it has the right event bindings!</li>
</ol>
All these things can happen any time from anywhere in an app that&#8217;s gone spaghetti. Real organization has been given up and it&#8217;s back to the DOM as the source of truth. It&#8217;s hard to know exactly what&#8217;s going on for any given element, so everybody just asks the DOM, does what they need to do, and crosses their fingers it doesn&#8217;t mess with somebody else.
React says: you don&#8217;t get to deal with the DOM directly. I have a virtual DOM and I deal with that. Events are bound directly to the elements, and if you need it to do something above and beyond something directly handle-able in this module, you can kind of ceremoniously call things in higher order modules, but that way, the breadcrumb trail can be followed.
Complicated DOM management is another thing. Imagine a chat app. New chat messages might appear because a realtime database has new data from other chatters and some new messages have arrives. Or you&#8217;ve typed a new message yourself! Or the page is loading for the first time and old messages are being pulled from a local data store so you have something to see right away. Here&#8217;s <a href="https://twitter.com/mjackson/status/849636985740210177">a Twitter thread</a> that drives that home.
<h3>❌ Just because. It&#8217;s the new hotness.</h3>
Learning something for the sake of learning something is awesome. Do that. 
Building a project for clients and real human being users requires more careful consideration. 
A blog, for example, probably has none of the problems and fits none of the scenarios that would make React a good fit. And because it&#8217;s not a good fit, it&#8217;s probably a bad fit, because it introduces complicated technology and dependencies for something that doesn&#8217;t call for it.
And yet, gray area. If that blog is a SPA (&#8220;Single Page App&#8221;, e.g. no browser refreshing) that is built from data from a headless CMS and had fancy server-side rendering&#8230; well maybe that is React territory again.
The web app CMS that makes that blog? Maybe a good choice for React, because of all the state.
<h3>❌ I just like JavaScript and want to write everything in JavaScript.</h3>
People get told, heck, I&#8217;ve told people: learn JavaScript. It&#8217;s huge. It powers all kinds of stuff. There are jobs in it. It&#8217;s not going anyway.
It&#8217;s only in recent web history that it&#8217;s become possible to never leave JavaScript. You got Node.js on the server side. There are loads of projects that yank CSS out of the mix and handle styles through JavaScript. And with React, your HTML is in JavaScript too.
All JavaScript! All hail JavaScript!
That&#8217;s cool and all, but again, just because you can doesn&#8217;t mean you should. Not all projects call for this, and in fact, most probably don&#8217;t. 
<h3>☯️ That&#8217;s what I know.</h3>
(There are decent emojis for YES and NO, but MAYBE is tougher!)
You&#8217;re learning. Awesome. Everybody is. Keep learning. The more you know the more informed decisions you can make about what tech to use. 
But sometimes you gotta build with what you know, so I ain&#8217;t gonna ding ya for that.
<h3>☯️ That&#8217;s where the jobs are.</h3>
Not everybody has a direct say in what technology is used on any given project. Hopefully, over time, you have influence in that, but that takes time. Eden says she <a href="https://twitter.com/edenthecat/status/849640183360352257">spent 2 years with Ember</a> because that&#8217;s where the jobs were. No harm in that. Everybody&#8217;s gotta get paid, and Ember might have been a perfect fit for those projects.
<hr>
<a href="http://ift.tt/2oSQ7q8">When Does a Project Need React?</a> is a post from <a href="https://css-tricks.com">CSS-Tricks</a>

When Does a Project Need React?

When Does a Project Need React?

Top Stories