Tag Archives: javascript

Rewriting in Rails 5

I’ve been doing Ruby on Rails work again. Although my indie web projects are all Sinatra, I generally recommend to clients that Rails is the way to go. Rails will be easier for them if someone else ever needs to take over the project.

I don’t like using 2 products that do the same thing, though. That’s why I consolidated my web app hosting to Linode, and my source code to GitHub. Why should I switch between 2 frameworks, especially since Rails has matured so well? I’m enjoying Rails 5.

David Heinemeier Hansson said in an interview on Slashdot, about the rise of JavaScript front-end frameworks:

But it seems like that’s one of the lessons people have to learn by themselves. Just try to string things together on your own a few times and you’ll quickly get an appreciation for what Rails provides as a backend framework. We’ve had tons of programmers try just that and come back for refuge.

It struck home because I’ve had some regrets with choosing Ember.js for my new app. Part of that is my own lack of experience with the framework. But also I’m no longer convinced that the heavily JavaScript-based view layout of something like Ember.js is better than Turbolinks, for example. I plan to rewrite my app in Rails and more classic Ajax at the earliest opportunity.

Two weeks notice: it just works out

John Saddington, who develops the Mac blog editor Desk, pointed to one of my recent posts and wrote:

“It does make me ponder, once again, what I’m doing with my so-called ‘career’ and if it’s the ‘right’ one. Although, every single time I think about that I know that I won’t like the answer… yet it always just works. I can’t tell you why or how I found or discovered this cadence, but, to each his own.”

Which in turn makes me reflect on my own career. I’ve been extremely lucky. The right jobs just seemed to have presented themselves to me when I needed them. I hope that luck hasn’t led to overconfidence as I take these next steps to become more independent. It would be a glorious failure if my luck runs out just when I need it most.

So I’ll have to work harder. I’ll have to better manage my finances, better plan and execute on new products, and better support each app so they’ll form a sustainable business. As I type this, I’m actually a little nervous for the first time since I put in my notice. Lots to do.

Tonight’s challenge: finish integrating CodeMirror into my new app, to provide Markdown syntax highlighting. I had never heard of this JavaScript library before this week. It seems very capable — a big jump forward on a feature I didn’t even think I could provide for 1.0.

Footnotes follow-up (and the Newton)

I expected to get a little more negative feedback on my footnotes blog post than I did. Most feedback was pretty good. Thomas Brand agreed but also wrote:

“That being said, footnotes can be fun when used sparingly. They lend themselves to the kind of personal anecdote common to the tech blogs I read. If you are going to use footnotes to break up your articles, Bigfoot.js is not a bad way to do it.”

Definitely. If you’re going to do footnotes, might as well do them with the best user experience possible.

Thomas has had some really good posts lately. Before it expires off his home page, don’t miss the recent one on the Newton MessagePad 2000:

“I doubt a 25-MHz ARM710 would have been very effective as a laptop replacement, and it the Newton engineering team knew it. That is why the MessagePad 2000 was simultaneously designed with two different CPU architectures and its own form of Universal binary.”

I couldn’t afford a MessagePad 2000 at the time, but I still have my MessagePad 130. Along with my original iPhone, I’ll never part with the Newton — a wonderful device to use and develop for that was way ahead of its time.


Stephen Hackett recently linked to the footnote JavaScript library Bigfoot.js:

“It works great on devices of all sizes and makes reading a long article much easier, as you don’t get bumped to the bottom of the article and back up to the top just to read a witty comment.”

You know what else makes a long article easier to read? Fewer footnotes.

This trend of footnotes in blog posts is out of control. Maybe a couple footnotes work well in a very long Daring Fireball essay, but in recent years bloggers are using footnotes everywhere in places where they’re just not necessary. They’re distracting and take you out of the story.

(Also remember, no amount of JavaScript footnote wizardly will help when I read your article in most web-based RSS readers. If I want to read the footnote right away, I’ll have to scroll down and then scroll back.)

I avoid footnotes in my writing. Often the same effect can be achieved with simple parenthesis. If parenthesis don’t fit well, entire extra paragraphs are also much more readable. And if it can’t be conveyed without footnotes, maybe the text should be cut out completely, if it is of so little importance to be relegated to the bottom of the article.

Footnotes are appropriate in two cases: either as true side notes, with facts or sources that can be looked at later, independently of the main writing; or for a particular style of writing, such as Bill Simmons’ Book of Basketball, which often goes off on long tangents and has footnotes on every page. (No small feat because the book is over 700 pages.)

In this rant I’m not trying to criticize anyone in particular. I read several authors who use footnotes frequently and I love their writing. But that doesn’t mean everyone should adopt that style without making sure it actually fits the context. Consider whether footnotes in blogs might be a fad, and if so, that it’s a writing challenge to find another way.

Using Ember.js

Brent Simmons isn’t totally convinced about the new crop of JavaScript frameworks:

“Part of me thinks those frameworks are overkill (even jQuery), and that writing regular-old JavaScript to do what you want is not that onerous a thing, and will make for leaner, better code.”

This was how I felt when I built Watermark. It uses jQuery and Bootstrap, but otherwise it’s pretty old-fashioned JavaScript. Even the parts that are Ajax just fetch and insert HTML that has been rendered by the server. There’s not much to do in the client.

For my latest project I’m using Ember.js. I want this app to be very fast, and I think putting more work on the web browser is the way to do it. I only know the basics of the framework so far, but already I like it. It feels lightweight to use, even if the actual JavaScript include is fairly large.

And 100k is really not that big of a deal anymore. You don’t want bloat for no reason. But look at a popular site like twitter.com and you’ll see several JavaScript files between 200k and 500k each. They get cached and no one complains about performance.

Searchpath open source and themes

I have big news for Searchpath today. The client-side portion of Searchpath is now officially open source and available on GitHub. While I do think one of the innovations of Searchpath is the JavaScript, CSS, and HTML, it’s really the simplicity of setting up Searchpath that makes it work. A single line of JavaScript adds a search box and indexes your site, and the crawling and storage will of course remain private on my servers.

Now that part of the service is on GitHub, customers who wanted to extend the JavaScript can have a clear path for doing that. Not only is it easier to host the JavaScript yourself, but I’m accepting pull requests to integrate your improvements back into the core product for everyone to use. Special thanks to Brett Terpstra for already submitting some tweaks.

I’m also very excited to announce a simple themes structure for Searchpath. Because in addition to the JavaScript, the second part of customizing Searchpath is the design. While I document CSS class names you can use to override styles, I wanted to make it even easier to design completely new user interfaces and share them with others.

On GitHub you’ll find a “themes” folder. Any sub-folder here will be routinely synced to the main Seachpath server, where you can access it by adding “theme=folder_name” to the JavaScript include URL. To create your own theme, just add a sub-folder with your own custom theme name and submit a pull request. When the theme is added to Searchpath, all your CSS and images will be hosted by my servers. (The first person to use a specific name will effectively become the owner of it, and I’ll only accept pull requests from that person.)

Want to learn more about Searchpath? You can try it out here for free, or sign up for $8/month.

Being a generalist

John Lim of PHP Everywhere:

“I’m actually a generalist. I can code a bit in Javascript, I know some C++, PHP and a thousand other useless languages. A generalist is pretty good thing to be in technology, because computers and software changes so fast and if you spend too much time specializing you’re already a dinosaur before you turn 40.”