Recently I've completed a number of small dynamic website projects, and I want to discuss my view on the way to choose to implement these sites.

This is to be read as an opinionated essay. YMMV.

SPA, a Single Page Application

Here are a few sites I completed recently:

• Rorschach™ Inkblot Coding
• Tangram Viewer
• Randall Train Status 

They all have in common that they are “Single Page Application” websites. What days does that even mean? In short, that means it’s a single HTML web page that uses JavaScript to implement a “full” web site by simulating several pages.

Let’s take an example: we want to create a small e-commerce site. We'll structure our site as different pages, each rendered by their own HTML file:

• http://example.org/mysite/index.html    -- the main entry point
• http://example.org/mysite/about.html    -- a page “about this company”
• http://example.org/mysite/catalog.html  -- the catalog browser
• http://example.org/mysite/product.html          -- a page detailing a single product
• http://example.org/mysite/purchase.html -- the purchase form

Instead an SPA web site uses a single file:

• http://example.org/mysite/index.html    -- the sole page of the web site

However, using JavaScript, we’ll change the content of the page to simulate showing the “about” page vs the “catalog” page, etc. One way to know which one to render is to encode the desired “page” using the hash portion of the URL:

• http://example.org/mysite/index.html
• http://example.org/mysite/index.html#about
• http://example.org/mysite/index.html#catalog
• http://example.org/mysite/index.html#product/{id}
• http://example.org/mysite/index.html#purchase

From the web browser point of view, it's always the same page being rendered (index.html) yet JavaScript is used to read the hash name and decide how to fill the page -- when the page loads, we use JavaScript to literally inject the content we want in the web page at runtime. If you were to read the “source” of the main index.html, you’d find it basically empty (or more exactly having just a single <div> container).

The mechanism above using the hash is called a “hash router”. There are other ways to do it, that's just the one I prefer.

It’s all about the frameworks

In this kind of web app, we rarely write “vanilla Javascript” (e.g. “code every by hand”). It’s just too tedious. Instead we use a framework to help us write the web page. There are a ton of frameworks out there, but essentially there are 4 that I consider the most popular and important:

• React JS, with code written in JavaScript or TypeScript.
• Angular JS.
• Vue JS, with code written in JavaScript or TypeScript.
• Flutter, with code written in Dart.

I believe that also more or less represents their level of popularity. My opinion on them, in a one line summary each:

• Flutter is my favourite one, but… We’ll discuss the “but” later.
• React JS. I started that way, and honestly I hated it. Ironically it’s only after switching to Flutter that I finally properly understood React.
• Vue JS. I tried this one for the sake of trying it. It’s said to be more approachable when starting than React. I can see why. Still I’d prefer React for the long run.
• Angular is a mastodon. It’s made to build large sites that scale. It’s a very complex framework, and it seems like it would scale very well. But for a single little SPA, it’s totally overkill IMHO.

Languages: JavaScript, TypeScript, and Dart

I’ll put this upfront to avoid repeating it below.

React, Vue, and Angular can equally be coded using JavaScript ES6, or TypeScript. In my option, JavaScript is always the wrong choice, no matter what the question is. Period. It’s an absolutely terrible language. Yes we can hand-code it without a compiler, and yes it runs directly in any web browser. Well, mostly. But it’s kind of flying without a net. Working with JavaScript is trying to admit that “hope is a strategy”. It’s not. Kids, just learn to say no to JavaScript.

TypeScript is the “sanity” version of JavaScript. It forces us to use a compiler (since it compiles to JavaScript after all), and that’s a good thing. It forces us to understand the types we’re using -- as the name of the language implies, it’s JavaScript with actual types, not just “whatever I can randomly put in a variable and hope it’s the right thing”.

The only drawback of TypeScript is that it’s essentially “JavaScript with lipstick”. Nothing prevents us from doing all the crappy things that JS allows us to do. However, TypeScript comes with a linter tool which tries to catch us on exactly the common mistakes that everybody makes. Don’t ignore the warnings, they are here to help us.

Flutter is coded in Dart. That’s its strength. That’s also its main hindrance. We have to be willing and make the jump to learn one more language just to write that small SPA thingy. That actually has dragged me down, and I avoided Flutter for a long time just because of that.

But… once I jumped into it, I realized that the TL;DR for Dart is “Java meets TypeScript”. Seriously. And if, like me, you find the Java syntax to be actually quite agreable, then Dart almost becomes “TypeScript has it should have been from the beginning”.

Flutter

I'm not going to try to give you a coding example of a Flutter app here - there are many examples out there already. Instead I'll try to explain why I liked it.

One thing you need to know upfront is that Flutter does not pretend to be a web framework. It is first and foremost a cross platform toolkit designed to create apps for mobile and the web (and likely desktop too).

As such, it will look foreign and weird to an HTML designer. We're not coding an HTML app with div and span and CSS. Not at all. We're coding screens using views (named widgets) and layout managers. Exactly like we would do in Java AWT or the Android view system.

--]

---