25 November, 2016
I’ve explained it enough times that I feel like I have a rather good patter down so let’s try to the whys and whats out there for all to see. I highly recommend reading this article in order as each section builds upon concepts in the previous to explain not only what but why the various tools under discussion work the way that they do.
29 October, 2016
My coworker and friend Emad Ibrahim blogged recently about how he doesn’t really get the hoopla around ReactJs. (Are pingbacks even a thing anymore btw? They were a great way of keeping track of multi-blog discussions.)
This is the key paragraph
I responded in the comment section but want it written up here as well as I’ve seen similar sentiments even from React fans.
What the conversation is missing is that React is not a single thing.
What React is
When people talk about React, they’re really talking about two or three distinct things depending on how you’re counting.
This does not include Jsx. In fact, the default way of working with virtual-dom direct (this particular library was extracted from React, there are a few others) is to use hyperscript notation which…is just awesome and is basically what the last 10 years of template language evolution has been aiming towards.
hfunction is wierd, but look at how clean that is! Do you want components? Just make a function! It all looks even nicer in languages that support lightweight symbols like Clojurescript with Hiccup
(defn render  (let [other-systems '(haml pug emmet)] [:section [:ul.other-systems (for [name other-systems] [:li "Even more like " name " then before!"] )]]))
I actually strongly recommend for people to play around with the virtual-dom library directly to solidify the concept and distinguish it from React overall.
This is the other part of React-standard that people talk about when they talk of React.
ReactJs includes a very thin layer of Facebook-specific conventions around how to work with the virtual-dom system. This includes
- Their component structure, lifecycle and optimizations around this
- State, props and context distinctions
- The propTypes checker
- The way that React captures and routes DOM events
And thats about all that I can think of.
I think this is the area that contains the entirety of Emad’s complaints. And that’s fine, maybe Facebook’s conventions are not for you - I also do not care for most of these things (component optimizations and DOM event handling are cool, the rest can jump off a cliff) but this is only one part of React, and frankly its usually not the part that people are talking about when they say they love it.
It should be mentioned that most of these are lightweight enough that you can work in your own technique in fairly easily. For example Jsx can be supplanted by wrapping your components in
The Redux Thing
Finally, if you consider the React community as a whole, one of the big things that people will hail is this whole Redux/Flux/Reflux uni-directional dataflow thingy.
This is fine. I personally, think people love it because its different and they’re being introduced to a whole new paradigm that many haven’t really explored previously. Eventually it will become overused and we’ll be able to admit to ourselves that it’s not a great idea absolutely everywhere and that modelbinding and forms all have their place as well. But I’m perfectly willing to admit that its a great concept and possibly even one that should be considered the default.
Now, I am not super into Redux. I have no problem with the project itself, and I actually quite like the team’s messaging around it, but there’s just too much fanboyism around a library that can be implemented in like 5 lines of code for my taste. Personally, I would probably lean a bit more toward event-sourcing in an implementation, keeping around and aggregating all events on any interaction and using mementos to boost performance. I also feel like certain variations on this concept such as clojurescript’s re-frame tend to cut down on boilerplate and be easier to work with.
It’s About Concepts Not Syntax
So that’s what I think Emad is missing. I doubt very much that he dislikes virtual-dom, and it seems unlikely he unilaterally dislikes the entire concept of Redux. Sure, Facebook’s conventions might not be to his liking. And that’s fine. The category of React-style-system is a lot more than that and I don’t think that Facebook has necessarily hit on the best abstractions. In fact it seems doubtful that a single one-size-fits-all abstraction is even possible.
When people rave over React, they’re likely focused more on the broader ideas and not really talking about the React specific conventions. Of course these conventions might be all they know and they have no scope of reference for what else is possible within the arena, but it seems quite possible that they might not be talking about React in the same context as you are.
And this also explains the other part of Emad’s complaint. Why does every single React example look different? Well here we get this now-old chestnut
And now it almost even makes sense. The above isn’t a framework so much as a set of concepts that are useful for assembling your own framework. Yes there are some conventions that get you half way there, but you still have to complete the other half, and if you don’t like these conventions you’re free to pick and chose your own. So if you want true parity to compare with something like Angular or Ember you have to look beyond simply “React”.
But here’s the thing
And that’s the power and elegance that people are talking about and the thing that you might be missing if you don’t investigate the community further.Comments
7 August, 2016
Recently I gave a talk at SQL Saturday Baton Rouge on the history of the Web. This was a version of a talk I had given many times before, largely to codecamp classrooms of novice developers. In sexing it up for a professional technical crowd, I ended up rewriting it completely - going back to a lot of primary sources, reading the www-talk archives and the various books written by people who were there at the time (Side note: a surprising amount of these individuals feel a need to include sections in their articles on the particular type of food and entertanment had at w3c conferences. It’s…weird.) In doing all this research to get an understanding of how it is that we got where we did, I ended up forming some opinions on where we’re probably going.
In this blog post series I’m going to make some hopefully non-obvious predictions about the future of the world wide web and how it is that we got here.Comments
15 July, 2016
So we want a fully functioning tab system with url navigation. Lets figure out how to do that.Comments
14 July, 2016
During an interview, a candidate - a smart guy just at the start of his career - asked me the following (paraphrased)
I feel like the biggest hole in my understanding at this point is how applications work at scale. How does one put together a large application with millions of users and hundreds of thousands of data connections? How does one process big data and use map/reduce. How do I advance myself in that area?
I’ve heard similar questions before. Heck, at some point I probably asked them myself. So let me answer this here, in blog format.
That is not your biggest hole. Honestly, it’s hardly a hole. Hardly anyone actually has to work with applications “at scale”. Maybe if you work at Netflix, and even then, the only person who really works at that level is named Magnus, has an office on the top floor and can read bit streams raw.
That’s not going to be you in the near future and, chances are, not going to need to be your skillset at all. It is simply not where you should invest your time.
You, my dear codecamp graduate, need practice working with others.
Not in an interpersonal sense (although maybe), but in the sense of how to write your code so that others can read it and maintain it. And that’s not just code comments. That’s design patterns, software architecture, project management, and just plain ol’ experience in getting-things-done. You need experience estimating, selecting proper technologies, and helping clients figure out that what they think they want is not what they need, and talking them into allowing you that extra week of refactoring.
In short you need practice coding. And coding with other people. Lots and lots of practice.
It’s hard of course. You’ve been focused on learning for so long with a side of implementation and now its time to see-saw in the other direction. The easier route is of course to just keep taking lessons and schooling and learning, but what I’m saying is its time to start getting those ten thousand hours in.Comments
- 14 Feb This can easily be the most important OSS thing I've done
- 18 Oct Why width 50% inline-blocks don't display side-by-side
- 12 Sep Talk Roundup - Be the Es6iest
- 27 Aug Automated Testing Venn Diagram
- 03 Jul Learn reduce
- 08 Jun Color Mixing Demo App
- 06 May Some self-indulgence from the nolatech chat
- 01 May Why Not MsTest
- 20 Apr Stop teaching h tags
- 19 Feb node-gyp won't install on Windows
- 31 Oct Use Simple Modules To Fix Up Your Ugly Brownfield App 1
- 29 Apr On this and new
- 09 Oct Open IIS Express to the Network
- 26 Sep Setting Up RequireJs
- 29 Apr Stop that = this'ing
- 16 Jan Error Handling and the Message Repackaging Anti-Pattern
- 12 May QuickTime and a TIFF (Uncompressed) decompressor are needed to see this picture