/legacydirectory for anything that seems worth bringing back. If you're reading one of my legacy posts, please keep in mind that it may not represent my current beliefs or perspective. Also, the process of porting content over introduced some formatting errors.
don't save sprockets
The good folks at Arkency recently got in touch and asked if I wanted to include my book Rails As She Is Spoke in their Rails Book Bundle. I was delighted to say yes, and big shoutout to Arkency for that. It was a fun coincidence: I had actually been reviewing this book, with the goal of rewriting it, for a few different reasons.
First, Gary Bernhardt's Destroy All Software, in its first incarnation, included a ton of Rails content which I felt kinda put my book to shame, and I wanted to upgrade the whole book as a consequence. Second, I had realized that my book had accidentally downplayed the role of Kathy Sierra in the design of Rails. When Rails was new, Sierra's Creating Passionate Users blog was a centerpiece in the ongoing discussions about how to build the Web, not just in general among the Web community, but specifically on David Heinemeier Hansson's blog. DHH frequently linked to Sierra's blog, and frequently discussed how both Basecamp and Rails were founded on and/or in line with Sierra's thinking. But I left that out of my book, and when I re-read my own book, I realized that I had not only done Kathy Sierra a disservice there, but also made the story less coherent in the process.
Third, when I wrote the book, Rails was all the way back on Rails 3. It's now on version 5. So I also had some updating to do. In the original book, I had kind of skipped over the asset pipeline, and today it's one of the major hassles in Rails development, so I felt that this was a minor deficiency that had turned more serious. So I set out to find a definitive answer on that.
Which is how I ended up watching @schneems's talk Saving Sprockets. In this talk, @schneems explains why he's maintaining Sprockets, and why it's a lot of work. TLDR: the code base is a mess, it overuses modules, and ultimately, Sprockets is a single God object with 105 methods.
Saving Sprockets is an important talk. A lot of people need to see it. Programmers all over the world need to remember that open source is free; that filing a ticket means asking somebody else to do work and solve your problems for free; that open source maintainers do not owe you that free work and are not bad people for having lives beyond their GitHub Issues. I was really enjoying the talk, until there came a point when @schneems referred to Node.js as "the technology that shall not be named," and I nearly threw my computer out the fucking window.
Not only that, the Rails culture has had a problem with Node.js hate since Node.js was invented. For me personally, this has been a severe source of caremad since about 2011. For instance, here I am arguing with Avdi Grimm about it in 2012:
Ruby caremad is very durable for me. Rails itself might not even be the best tech for my needs any more, but Rails gathered a community around principles like beautiful code and programmer happiness. I think those principles are very important.
A little before I got into Ruby, I started going to Python meetups, but I stopped because I got sick of hearing them hate on Perl. It was constant; no Python meetup was complete without somebody saying something about how terrible Perl was. Perl is by no means a perfect language, but I'm just not the kind of person who likes to join groups who use hating another group as their key organizing principle. I consider that very unhealthy. I don't know if Python ever got over that shit, but I am very sad to see how sick the Rails culture has become.
So I started trying to figure out what went wrong, and I think I know.
Let's start by getting our terms right.
When people talk about Ruby programmers as a group of people, they usually say "the Ruby community." I often prefer Gary Bernhardt's term — "the Ruby culture" — but it's really a diaspora. Ruby originated in Japan, and most of the Ruby core team is Japanese to this day. Japanese Rubyists and Western Rubyists form distinct local cultures which share a common language and a common origin. That's a diaspora.
When programmers in the West discovered Ruby and told each other about it, they formed a distinct local culture of Western Rubyists. (Being Western, of course, they just called themselves Rubyists.) Every culture needs a story to tell about itself, and Western Rubyists were no different. But the story they came up with was so weak that the culture's current sickness was made inevitable.
The story was "Matz is nice, and so we are nice."
They abbreviate it MINASWAN.
ruby is 和
Just for the record, MINASWAN is at least half true. Matz is nice. I met him, and he's nice. I went to dinner with him, several other Rubyists, and the late, terrific, and much-missed James Golick at MountainWest RubyConf.
But there are several problems with MINASAWN. It's simplistic hero worship, and it's so vague it inevitably leads to hypocrisy. "Be nice" is really general advice, and some of the people who say it don't actually do it.
I think there is a much, much better way to understand Ruby.
I've been studying Japanese for a few months, and one of the other students in my class brought in pictures of a Buddhist temple that he visited in Japan. One picture involved a Shinto shrine, even though Shinto and Buddhism are two completely different religions. This Buddhist temple simply included a space for Shinto worshippers, like if a church in America included a small corner that had been constructed as a tiny mosque. Our teacher told us that this is a characteristic of Japanese culture; where in America, you have a church over here and a mosque over there, in Japan, it's very common to find people reconciling or combining disparate elements in a harmonious blend.
I wasn't there when MINASWAN was first said. But what I imagine is that there were two people disagreeing with each other, and Matz, who is Japanese, looked at their points of view and sought to combine disparate elements from these two points of view in a harmonious blend. And all the American Ruby programmers looked at that and thought, "oh, he's nice." Like that was all there was to it.
In reality, this is a fundamental thing about Japanese culture. And Ruby comes from Japan. This is not a coincidence. The Japanese language even has a word for it: 和, which is roughly pronounced "wa."
It should hopefully be very obvious how hating on Node.js, or any language, is fundamentally irreconcilable with 和, and fundamentally inappropriate for any event or group of people organized around Ruby, if you regard Ruby as a product of 和.
I see Ruby that way. In fact I think we should go further, and say that Ruby is 和.
I hate to say this, but I believe this is a situation where we Western Rubyists are simply being very bad guests. Ruby was created in a spirit of 和. It should be used in a spirit of 和. It's just a matter of courtesy.
MINASWAN implies that Ruby on Rails does not exist
Now let's think about one of the major, glaringly obvious contradictions in MINASWAN.
By far the most famous Rubyist in the world is DHH. I would not call DHH nice. I think he wouldn't describe himself as nice either. In The Rails Doctrine, he describes Rails as "a deeply narcissistic endeavor." In 2006, at the first Rails conference ever, Canada on Rails in Vancouver — about a month before the first RailsConf — DHH gave a talk where he quoted some critics of Rails who had described him as arrogant, and he agreed with them.
A few years later, when someone else delivered a Rails conference presentation which contained porn in its slides, DHH defended them, saying this:
I've found that the fewer masks I try to wear, the better...In other words, "I'm just being honest." The thing that only assholes say.
You're bound to upset, offend, or annoy people when you're not adding heavy layers of social sugarcoating...
What I'm not going to do, though, is apologize for any of these preferences and opinions...If you can deal with that, I'm sure we're going to get along just fine.
So, according to DHH, DHH is arrogant, doesn't mince words, and regards his own life's work as a narcissistic project. That's what this guy says about himself.
So if MINASWAN is really a basic truth about the Ruby culture, then how does DHH fit in at all? MINASWAN would predict that DHH was not involved in Ruby, since "we are nice" is a statement which probably cannot be made about a group of people which includes DHH. But MINASWAN's prediction is false.
DHH isn't just involved in Ruby, and he isn't just a very important figure in Ruby. He's also a huge Ruby fanboy. Half of The Rails Doctrine is just all about how much DHH loves Ruby. He wrote a long essay about the ideas behind his massively successful web framework, and despite it being a narcissistic project by his own admission, half of this essay just reads like a love letter to a programming language. And it's probably not a coincidence that his Ruby reads better than most people's Ruby.
Rails also fundamentally embraces 和. Think back to the example of a Shinto shrine within a Buddhist temple. Another way to describe 和 could be as a spirit of inclusive compromise. DHH famously hates RSpec — and I've recently come to understand his point of view — but you can not only use RSpec with Rails,
rails new has a built-in
--skip-test option which allows you to use RSpec more easily. There's a
--skip-whatever option for nearly everything DHH thinks you should use in your Rails app; consider also the "no one paradigm" section of The Rails Doctrine.
Ever since DHH came along and transformed Ruby, in the West, from an esoteric hobby into a thing you could actually do for a living, MINASWAN's been this weird, illogical thing about pretending DHH doesn't exist. Which is already a weird red flag. But if you say "how can we carry forward Ruby's spirit of 和?" then DHH poses one answer. In his communication style, he's Western to a fault, individualistic and utterly uninterested in getting along with anybody, but when it comes to naming variables and methods, he's obsessed with balance and harmony. In other words, he chooses 和 when he's writing code, and he chooses a Western individualism when he's arguing on the Internet.
(And, sadly, when he's architecting systems, which is the core problem with the asset pipeline.)
DHH's answer might not be the best answer. It's certainly not the only answer. But it's an answer. MINASWAN implies that DHH just doesn't know what Ruby is about, as a culture, and that's a ridiculous position. It's the (Western) Ruby old school sticking its fingers in its ears and yelling "la la la I can't hear that Danish guy."
If we say "Ruby is 和," then we can acknowledge the obvious reality that DHH understands Ruby pretty well. You can still disagree with what he's chosen as the balance of Western individualism and Japanese 和, but that's fine — speaking as a Westerner myself, I feel like that's his decision to make — and you now have a sane, coherent, rational model of the Ruby culture. The model for itself that this culture has chosen instead, MINASWAN, implies absurdities. You can't structure a conversation around something like that. MINASWAN was simple enough when Ruby was a tiny scene of hobby programmers only, but when DHH made it a serious professional thing, MINASWAN should have evolved into something more nuanced. Instead, some Rubyists forgot about it, others never even heard of it, and others took it as a joke because it ignored DHH.
Still others employed it as a sort of snooty, superior, tragic thing. That's the old school Rubyists who tried to use MINASWAN to inhabit the moral high ground. But MINASWAN fails as an attempt to occupy the moral high ground because it implies DHH has no "real" place in Ruby. He's literally the only reason most of you have jobs! So it's not only terribly entitled and ungrateful, it's also passive-aggressive, since nobody ever addresses this huge contradiction that DHH somehow is just a footnote. But if you're passive-aggressive, entitled, and ungrateful, then you're not nice.
MINASWAN is garbage. It'd be more accurate to say, "Ruby showcases the Japanese value of 和, but we are arrogant Americans, so we reduce this to a really basic American idea, harshly compressing it in the process to a state where it cannot possibly mean anything any more, instead of bothering to learn something about the outside world for once." But MINASWAN was already a long acronym, so I guess they had to draw the line at RSTJVO和BWAAASWRTTARBAIHCIITPTASWICPMAAMIOBTLSATOWFO.
Instead of advocating this acronym myself, I have a simpler suggestion: shitcan MINASWAN, and say instead "Ruby is 和." That's pronounced, "Ruby is wa." Now you may be asking yourself, 和t the fuck? It's not enough that newbies have to learn OOP and some FP concepts, now we have to tell people that if they want to understand Ruby, they have to learn Japanese?
Well, every Japanese programmer has to learn English to program in Ruby, which was invented in Japan, so I don't really think that's as demanding as it might sound. I think it's actually pretty reasonable to ask that programmers be good at languages. But I'm not asking you to learn a whole language. I'm literally saying you should just learn this one word. It's a really important word.
Ruby's artful blend of disparate paradigms is not a fluke; it's just the most recent step in a tradition which stretches back at least a thousand years. This blending already has a name, and if you want to reason about it — say, for example, you're writing a new language, which aims to achieve a similar balance, as Jeremy Ashkenas did when he created CoffeeScript — then it makes sense to refer to it by name.
Alternatively, I suppose you could just say "Giles felt like his ideas were too obvious, so he started blogging in Japanese." But that would miss the point, because プログラマーはトランスレーターです. "A programmer is a translator." In other words, translation is inherent to programming.
Around the same time I watched the Saving Sprockets presentation, I saw this (shorter) video too:
Take a second to watch it. It's just fantastic.
I also saw this remark on GitHub:
Since illuminating this murk was a major goal for my Rails As She Is Spoke rewrite, I dug into this some more, and found a great blog post about migrating from Sprockets to Webpack. It said:
This is the answer to all the confusion around the asset pipeline: don't fucking use it. Sprockets is poorly designed abandonware which causes endless problems. This is an easy choice.
Plus, according to @searls, Ruby is still the best way to test browsers on a Node.js project:
Maybe it would be easier to sell Node programmers on a polyglot approach here if Rails itself hadn't turned its back on polyglot programming, aka Ruby's spirit of 和. Here's one way you might sell Node programmers on using a Ruby project: "hey, we talk shit about you all the time, but our Selenium wrapper is better than your Selenium wrapper, so suck a dick, dumbshits." Here's another way: "hey, we use a Node front-end compiler, because we're an open-minded, polyglot community, and we have this really good browser testing API, so why not be polyglots too?" @searls showing up twice like this doesn't imply an endorsement from him, it just shows that he's freaking everywhere.
Also, Webpack is amazing. If you've read Ilya Grigorik's book on front-end performance — and frankly, if you have any opinion at all about Sprockets, then you should have read this book already — Webpack is a dream.
require_tree directives in the comments of your
application.js with actual
Webpack 2 has tree-shaking, and the Webpack team is looking for ways to integrate Rollup-style scope-hoisting as well. Could this ever happen with Sprockets? Can Sprockets solve CSS's namespace problems? How many refactors until this legacy code acquires an API clean enough to support third-party sunburst graphs? And how soon is Sprockets going to get its real-time dashboard?
Unless, of course, you happen to believe that Ruby is a beautiful language which is good at some things but bad at others, in which case you might conclude that it's maybe not reasonable to be writing compilers in Ruby for anything other than a teaching example.
ok, save sprockets a little
At this point in the blog post, you might be expecting a caffeine-induced, fist-shaking rant, foaming at the mouth with impotent rage, but that's not what comes next. First I did a bunch of passive research, i.e., reading blog posts and watching videos. Then I did some active research, i.e., building stuff. Then I did a little bit of work on a few Sprockets tickets. We're not talking about a ton of work here. I answered a few questions, investigated a few bugs, and created a few example apps (which @schneems had requested, in the Saving Sprockets presentation).
But I did these things. I made a contribution of effort to Sprockets. Because Ruby is 和.
Although the anti-Node.js bigotry in Saving Sprockets annoyed me, and although I disagree with the fundamental premise — that Sprockets is worth saving — the presentation was a great presentation. The work of open source volunteers has made my life better, which is the real point of Saving Sprockets, and I feel grateful for that, partly because @schneems convinced me in his presentation that I should feel grateful for that.
Remember, one of my theories re 和 is that it explains DHH way better than MINASWAN can. I think this theory is obviously correct and nobody but an utter dipshit could possibly contest it. And that's something DHH himself might say, in his Western, non-和 mode. And my idea here is that his Ruby code, and his many writings about how to write Ruby code, display a very classically Rubyist 和. And that this is the balance he strikes between the two cultural currents in the Ruby diaspora.
His balance isn't the only balance. I decided to strike a different balance. Although I think Sprockets is the wrong direction overall, I decided I would show a little gratitude and respect for all the free hard work that other people have done on Rails, and Webpack, and so many other technologies, because it's made it possible for me to do stuff. Even though I think that Sprockets's time is ending, that piece of technology's been something useful which I got for free since 2009. @schneems said in his presentation that we should help the projects that have helped us, and that all programmers should do that, and I agree. So I contributed a tiny bit to this project even though I ultimately believe it should be wound down and retired. I feel this is 和.
When I cloned Sprockets, I even named my directory
~/code/和, but this caused 44 spec fails, all with error messages like
URI::InvalidURIError: URI must be ascii only, because Sprockets builds its testing URLs from your directory name. I didn't file a ticket for this; I felt it was an unusual and inconsequential edge case. I just created another directory with a more run-of-the-mill name.
But I kind of hope @schneems uses his powers of persuasion in the service of a more current project next time. Because how on earth can Rails say it exalts beautiful code and optimizes for programmer happiness when it's keeping really bad legacy code alive on the spare time of volunteers?
It kinda feels like watching a bunch of mean teenagers telling lies to a younger kid. "Fix this legacy code, dude! You'll be a hero!" You might as well tell him that the Spanish word for "friend" is "pendejo" while you're at it. ("Pendejo" literally means "pubic hair," and if you use it as a term of address, it's not taken as a compliment.)
(Although, to be fair, a lot of these projects were inspired by the Google Closure Compiler, too.)
rails new or scaffolding, but it's not the same. A couple gems integrate Webpack and Rails, which is a step in the right direction, but really, gem wrappers need to die, preferably in a fire so hot and intense they melt to their component atoms. Imagine if Rails presented a nice, clean wrapper around Webpack, or something like it, in a uniquely calm corner of npmjs.com, which people could trust and consider authoritative. If Rails did that, instead of clinging to its legacy code, it'd be a tremendous public service.
Somehow, the Rails culture looked at this landscape and instead saw an opportunity to get talented people to mire themselves in legacy code for free. In my opinion, that's dysfunctional, and it won't end well. And it's not the only dysfunction involved.
Hating on Node.js might just be evil sexist bullshit
I hesitated before posting this rant, because of a tweet from Wes Bos:
And especially a blog post by Aurynn Shaw:
Please be careful before you write a medium think piece and say ____ is dead/anti-pattern. Lots of newbies take it as gospel— Wes Bos (@wesbos) September 5, 2016
when I started programming in 2001, it was du jour in the communities I participated in to be highly critical of other languages. Other languages sucked, the people using them were losers or stupid, if they would just use a real language, such as the one we used, everything would just be better...With apologies for the pedantry, I'm fairly certain Ms. Shaw is using French incorrectly here, and that the phrase she wants is de rigeur rather than du jour. Du jour can mean trendy, which would imply that programmer tribalism was a thing of the past, which I would disagree with, although I would also wish it were true. De rigeur means something required by etiquette, which I think is what Ms. Shaw intended to convey.
This sort of culturally-encoded language was really prevalent around condemning PHP and Java. Developers in these languages were actively referred to as less competent than developers in the other, more blessed languages.
And at the time, as a new developer, I internalised this pretty heavily...
[but] I was asked to consider who and what I was criticising... starting with Wordpress-based design backgrounds and moving from more simple themes to more complex themes where PHP knowledge is required, to plugin development is a completely valid narrative, but a path that is predominately for women.
So first, yes, OK, the asset pipeline works. I think a company which wants performance, and an asset pipeline that is easy to reason about, will have less trouble if they
--skip-sprockets and install Webpack instead, but if you're learning Rails at a code bootcamp, by all means, Sprockets will get the job done.
(Also, Webpack is easy to use with Rails, and I've literally written a book which will show you how to do it, but we'll get to that.)
Second, I'm pretty damn sure @schneems had no sexist intent. He didn't even seem to hate Node.js himself, he seemed like he was apologizing for acknowledging the existence of Node.js, because other people hated it. That's not necessarily on him, that's on the audience. And I've already discussed why this alarms me.
But consider what Ms. Shaw said about the WordPress -> PHP path being a path which brings a lot of women into programming. Is it possible that a lot of women come into programming via front-end work, which in Silicon Valley's parlance is often considered nothing more than "making the app pretty"? Who might be tasked with the work of making things pretty?
It's obvious that "Matz is nice and so we are sneering a lot" just plain does not make sense, but before I read Ms. Shaw's blog post, I assumed the cognitive dissonance was based on insecurity. I assumed it was about Rubyists being mad that they weren't the hot new flavor any more.
This happened a long time ago, and I thought it was the main reason Rubyists hate on Node so much:
But now I have to consider an interpretation which paints the Ruby culture as more discriminatory than I had imagined it to be.
And by the way, that too has roots in Japan, although, again, not necessarily in a malicious sense.
why ruby has no code of conduct
Ruby's had a very difficult time establishing a code of conduct, and Ruby core's Japanese contingent have been staunch in their opposition to it. There might be some sexism to that, and there might not. But there's no ambiguity on one crucial point: 和 emphasizes working out differences via compromise, while codes of conduct tend to set relatively stringent rules, and use ostracism and exile as modes of punishment.
This is a sensible strategy in the West. Exile is a mild punishment in an individualistic culture — more a safeguarding mechanism than a punishment at all, really — but a harsh one in a culture like Japan's. One of the more important aspects of 和 is that you're supposed to work for the good of the group, not just yourself. Imagine that's how you're raised, how everyone around you was raised. If you get exiled, what do you even do with your life? In a culture where children are taught that helping your group is the whole point of doing things, ostracism is not a mild punishment. It means no longer having any reason to do things, or to exist.
和 is so fundamental to Japanese culture that 和 was the Japanese word for Japan about a thousand years ago, and still functions as an adjective meaning "Japanese" in many older words. As Michael Carr wrote in The International Journal of Lexicography, "[t]he notion that Japanese culture is based upon wa 和 'harmony' has become an article of faith among Japanese and Japanologists."
Unsurprisingly, Japanese members of the ruby-core mailing list, Matz included, were especially opposed to the ostracism aspect of a CoC. If you understand 和, the Japanese Rubyists' response to a CoC not only makes more sense, but sounds almost aghast at American barbarism.
Matz said, for instance:
The CoC contains banning members from the community as a punishment. This does not mean anything but hurting individuals... Besides that one can regret the previous act and change the attitude.Matz's implied solution — atonement — is virtually never seen in discussions of code of conduct. It's not a coincidence that in Japanese, there are at least 11 different ways to say "I'm sorry". Let me tell you how that looks to me personally. I'm a first-generation American with roots in England — which, like Japan, is a formerly imperialist island nation, which has notoriously idiosyncratic etiquette, which is fond of compromise, and where the average resident apologizes constantly, frequently for things that are not even their fault. From my point of view, there's an evangelical, absolutist zeal to codes of conduct which I find distinctively American.
I support CoCs, in general, but I sometimes find it unsettling how certain CoC advocates are of their own righteousness. Likewise, perhaps again as a quasi-English person, the weirdest thing about CoCs to me is that virtually nobody ever even raises the possibility of apologizing, atoning, or learning anything. (Sorry to lean so hard on my tenuous claim to Britishness, I realize it's a bit disingenuous.)
Of course, most CoC discussions involve communities which are predominantly American, so this perspective might not even matter, overall. But the Ruby culture is a diaspora, and MINASWAN isn't worth shit if you're using it to decipher the drama around the failed attempt to adopt a Ruby Code of Conduct. "Matz is nice and so he is opposed to requiring that Rubyists be nice to each other" makes no goddamn sense at all, whereas "Ruby embodies the Japanese principle of harmonious balance, aka 和, and convincing Japanese Rubyists to abandon that spirit of inclusive compromise is exceedingly difficult" makes perfect sense. Let's say MINASWAN served its purpose, but it's time for a more nuanced point of view. Ruby is 和.
btw, buy my stuff
This blog post started out as a new chapter for the Rails As She Is Spoke sequel/revamp that I have planned, but along the way, I decided to write a new book entirely. It's a book about bringing modern front-end code to Rails applications. The TLDR will probably be "use Webpack, use Elm," but (as with many things) it's the journey, not the destination. The book starts out with a very simple, run-of-the-mill Rails app, with a front end using CoffeeScript and jQuery. I then carefully rebuild the front end for this app several times — in ES5, ES6, React, and ClojureScript (using Om) — to demonstrate modern front-end development and explore the tradeoffs that you have to consider when doing it. I also show you how to replace the asset pipeline with Webpack. These chapters are all written; I've also got a chapter on Elm which I'm still working on. (The code is written, but not the prose.) The book's working title is Modern Front-End Development with Ruby on Rails and Puppies, because there's going to be a puppy on every page.
btw, if you're like, "wait, Giles accused the entire Ruby community of sexism to sell a book," well, sure. I'm not above picking a fight now and then. Which reminds me: @schneems absolutely deserves his recognition as a Ruby Hero, but where's my recognition as a Ruby Villain? I know I'm not Lex Luthor, but I figure I'm at least that gorilla with a light bulb on his head. I don't even need an award ceremony, just throw me a t-shirt or something.
Anyway, my underrated villainy is actually kind of relevant to this discussion, because DHH isn't above picking fights either, and anybody who thinks otherwise is living in a dream world. Consider what Getting Real, a book DHH co-wrote, has to say on the subject:
Pick a fightThis could have been titled "The Troll's Guide To Marketing." Obviously, this is DHH in a Western mode. "Pick a fight" is not 和, but it's not MINASWAN either, is it? MINASWAN wants us to agree that Matz is nice, which is easy, but it also wants us to pretend DHH doesn't troll people all the time, which is ridiculous. The Rails Code of Conduct defines trolling as unacceptable behavior, which means Rails has to ban DHH from Rails, and Tenderlove as well! So the bad news is I guess I'm banned, but the good news is I'll be in excellent company.
Sometimes the best way to know what your app should be is to know what it shouldn't be. Figure out your app's enemy and you'll shine a light on where you need to go....
One bonus you get from having an enemy is a very clear marketing message. People are stoked by conflict. And they also understand a product by comparing it to others. With a chosen enemy, you're feeding people a story they want to hear. Not only will they understand your product better and faster, they'll take sides. And that's a sure-fire way to get attention and ignite passion.
I hate to provide MRAs with fuel for their arguments, but is there anything more ridiculous than the fact that the Rails Code of Conduct bans trolling? There are really only two elements to the Rails culture: trolling, and the color red.
One problem is that Internet generations are much shorter than regular generations, and "trolling" today means death threats, doxing, and harassment, while many Rubyists come from an Internet generation where "trolling" meant playful sarcasm like this:
But perhaps a much deeper problem is that sometimes people adopt a Code of Conduct in the spirit of lip service, and don't care too much about this kind of contradiction. Maybe they should.
Moving on, just because I'm saying it to sell a book doesn't mean it isn't true. In general, I like my books to contain true statements. I'd even go as far as to say that if you want to sell a book, telling people things for free is a good way to start, and those things you're saying for free should be true things.
I saw my first Haskell talk at a Ruby conference and I saw my first Clojure talk at a Ruby conference too. Western Rubyists once had a magpie subculture, with lots of interest in other languages, and Ruby itself being a blend of many different ideas and influences. This is 和.
What the fuck? No. Just no. Use the best tool for the job, and acknowledge the obvious fact that the best tool for the job might be written in another language. Get over this ridiculous Hatfields and McCoys bullshit. Otherwise, if we don't put a stop to this shit, the Rails culture is going to turn into an asshat pipeline.
We all know Rails is omakase.
And sure, omakase is all well and good, but here's a very related Japanese word: 旬, which I think is spelled しゅん. (My Japanese spelling is frequently wrong.) It's transliterated "shun" but it sort of rhymes with "moon." Its meaning is sort of like "freshest," except it also implies "most seasonal." Like you wouldn't serve a winter salad in July, no matter how fresh the ingredients were, because even if they were fresh, they couldn't be しゅん.
Sprockets isn't fresh, but it could be; @schneems is trying to make it fresh again, and even though I think it's a mistaken goal, he's having some success with it, and I respect that work. But today, Sprockets cannot be しゅん. That's just not possible any more. Whether we save it or not, its season has passed. When Sprockets was first written, I think only the Google Closure Compiler existed as a serious alternative. It couldn't handle CoffeeScript or CSS, and I don't think you could run it from the command line either (or if you could, you had to use Java, so it was painfully slow at best). Sprockets was a great innovation at the time, but that time is over. And if something is neither fresh nor しゅん, it doesn't belong on an omakase menu.
Let's just think about the real stack, the stack that every Rails app except Basecamp is using. The omakase concept might be arrogant, but it's not tyrannical. That
--skip-sprockets option is right there, and the smart move is to use it.
And by the way, my new book shows you how to set up Webpack where Sprockets used to be.
Let's talk about this book
Here are a bunch of old tweets where people said nice things about my first book:
I've been doing this for a while, but recently, I decided to upgrade the design of my products. So I've created a new home for my books:
truthindustri.es is a new brand, and its goal is to signify a new standard. For example, in the past, I put no energy into design at all. Here's some screenshots from my old books:
And here are some design sketches for my new book:
In addition to a higher standard of design, this new book is longer than my other books, has more puppies than my other books, and ships with two git repos.
One repo is a quick overview of Flexbox, which simplifies a complex topic, while the other is the app I mentioned earlier, which teaches you all about the modern front end. It's a simple Rails app, with the same simple UI recreated in several different front-end technologies, including ES5, ES6, React with JSX, Webpack integration, ClojureScript and Om, and even a sprinkling of ES8 experimental features. (And with an Elm branch on the way quite soon.)
I also build a checklist of elements to consider when assessing the tradeoffs between each of these different front-end strategies, and run these different implementations through this checklist. The purpose is to make it easy for people to pick up new front-end technologies and evaluate them, because people who are new to front-end coding often have difficulty with that. This book aims to make that a lot easier.