Behind the Scenes: Rebuilding LaudableApps

LaudableApps is a site originally started by Benedikt as a Tumblr blog. I took over the project in 2012 and started to maintain it as a free time project. My goal was to build an independent showcase for beautiful iOS apps without distraction. No ratings, no reviews, no comments. Just apps, screenshots and App Store links.

The new look of LaudableApps

A new design

The first big redesign was back in 2012. Another refresh happened late 2013. Now, 4 years later, it was time to move away from the initial branding. It has done its job, but started to look outdated.

The original design from 2014

I tried to redesign the site several times, but was never satisfied with the result. You sometimes need to put a project aside to collect new inspiration and fresh ideas. It thankfully worked out: The main part of the final design happened in only few hours. I was super happy with it and took it directly into development 🦊 Bright and light colors, whitespace and abstract forms dominate the new design. Concept and layout stayed.

No CMS

Kirby was my CMS of choice for a long time. It still is, but as a developer I’m able to maintain code without any UI or level of abstraction. Especially as I’m the only one working on LaudableApps. There was no reason for me to use a CMS, again.

Static website generators are a big thing and they make hosting simple. You can upload your sites anywhere and don’t need to worry much about security and performance.

Harp.js is a fantastic solution, but limited to its build-in preprocessors. I’ve developed a similar generator called Rosid to solve the issues I had with it. Rosid invokes functions before serving files to the browser. This allows you to transform anything, without saving. And the best: You decide what the function does.

React and SSR

React is my framework of choice when it comes to user interfaces on the web. There’s not much interactivity on LaudableApps. Using a JS library to render HTML for it is unnecessary… but fun 😎

I’ve ensured that all the code I’ve written was isomorphic. This makes it possible to run the JavaScript on both server-side and client-side. Or with other words: The back-end and front-end share the same code. Why? Because I don’t want to send an empty site to the user that then gets filled with HTML when the JS has loaded. When both sides already share the same code, why not pre-executing it on the server? The magic keyword is SSR 💫 Server-side rendering means that we send a filled site to the user that then gets re-rendered when the client JS kicks in. When the used library is smart enough (and React is), it only re-renders what’s necessary.

I previously mentioned that I’m using a static website generator, which means that there’s no server-side. I instead execute the server-side once and save the output to static HTML files. Lets call it pre-executed SSR and pretend it’s a thing…

CSS in JS

It’s crazy. Now that everyone has started to write HTML in JS, people got over-motivated and try to squeeze as much as possible into one language. To be honest: I was skeptical about this, but I thought I should give it a try.

Glamor looked like a good library to get started with. I can’t tell if it’s the best in its class, but it worked fine and I got no trouble with it. And yes, writing CSS in JS has its advantages:

• JS is all you need. You can throw away your SASS workflow.
• Generating CSS based on props you pass to components is delightful.
• All the power of JavaScript is usable, including everything from npm. kowler is one great example of modules you can use. The possibilities are endless.

But it’s not all fun and games 😒

There’re many libraries. Finding the right one takes a while. Some of them don’t even support pseudo classes and media queries. Others don’t allow to extract CSS files. You will run into problems which haven’t existed before. I claim that you never thought: “How can I save the damn CSS into a file?”. Now you will.

Another disadvantage was that glamor uses objects to define styles. Objects are powerful in JS, but it can get pretty ugly when you start to use :hover or @media in them.

css({
  display: 'flex',
  justifyContent: 'space-between',
  alignItems: 'center',
  background: 'rgba(0, 0, 0, .04)',
  ':hover': {
    background: 'rgba(0, 0, 0, .08)',
  },
  [`@media (max-width: 800px)`]: {
    flexDirection: 'column',
    textAlign: 'center'
  }
})

Template strings are an alternative. They are easier to read and some libraries support them, too. It depends on the library and you should take this into mind when choosing one. There’s also a way to use them in glamor, but it’s considered as buggy.

css`
  display: flex;
  justify-content: space-between;
  align-items: center;
  background: rgba(0, 0, 0, .04);
  :hover {
    background: rgba(0, 0, 0, .08);
  }
  @media (max-width: 800px) {
    flex-direction: column;
    text-align: center;
  }
`

Conclusion

I’m happy that I finished the project without getting lost in new libraries. I tried a bunch of new stuff and had some trouble getting SSR and CSS in JS right. The hardest part was the rethinking. How to write JS that works on server and client? How to style elements without a real CSS file?

Let me know what you think and feel free to ask me further questions on Twitter.