17 April, 2017
Because I’m sometimes a glutton for punishment, I chose to reply in depth
Which is the better language? C#, I have no qualms about saying this. It’s not even a contest. Just examine their origins.
C# was designed at Microsoft, a huge and very successful company with a ton of resources, as a part of one of their flagship engineering efforts; the introduction of the .Net Framework. Its chief architect is Anders Hejlsberg - one of the top language designers in the world - who had previously worked on two successful languages: Turbo Pascale and Delphi. The C# team has lead the language with a steady hand, developing an ecosystem and fully integrated tooling, including the ubiquitous-in-the-space Visual Studio IDE. In addition they’ve had two incredibly powerful programming models to draw on: Java, which C# was patterned on and which had serious deficiencies which C# has arguably fixed; and F#, a fantastic academic language based on OCaml that serves as a sort of “minor league” for C# features, trying these out before rolling many into C#.
Oh and also LINQ. LINQ is amazing and far too few people understand how insanely powerful it can be. If you’re learning C#, it is not strictly necessary at first, but at some point take the time to learn how LINQ providers work and how to write your own. You will up your game several times over.
It then sat on the shelf, barely used for anything beyond calendar widgets for nine years until Gmail introduced the world to the possibility of Ajax (they did not invent the term nor the concept, but credit where due for popularizing the technique and showing what was possible). It then tried to change way too much stuff at once, failed, and has only recently settled into a reasonable pace of gradual evolution. Just in time for WebAssembly to slowly start killing it off. Its freaking shocking that any of this worked at all!
C# is the better language.
But the language is not the whole story. There is also the community.
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 Jul You don't need to learn map/reduce
- 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