I've been setting up a new greenfield project, and wanted to use not exactly a new stack, per se, so much as an "all-star" stack that'd capture the lessons I've learned coding recently. For me, that means it needs to be pretty straightforward, minimal dependencies, and minimal compilation. The fewer libraries and snowflake server requirements, the better.

On first take, after bypassing Node, which really is the winner,1 my guess was that my all-star stack would be...

  1. ASP.NET Core
    • C# with no OS limits.
    • Deploy inexpensively to Linode, eg, if you want.
  2. Web API on ASP.NET
    • No Razor templates (not that I hate Razor; just one less tech to maintain)
    • No direct interaction between server and views/html/client.
    • Keeps concerns separated perfectly, exchanging only JSON between tiers.
  3. Statically served html (with JavaScript packages, natch)
  4. jQuery 3.x slim
    • Slim means no ajax; it's more efficient to roll your own.
    • Every time I've used $.ajax, we've wrapped that with our own error handling, etc, anyhow.
    • Learn to spell XmlHttpRequest. ;^)
  5. Bootstrap
    • The cheapest mobile client is a responsive web client.
    • I realize native is better. But responsive is, give or take, free.
    • Also gives a decent basic theme.
  6. VueJS
    • This was probably the most difficult to decide on ahead of time
    • Will discuss more below.
  7. PostgreSQL or MySQL

VueJS was difficult to pick. I've used React, and almost solely React, for the last year. I like it. But I believe it contributes to monolithic source that's not necessarily factored well. The more interdependencies your code has, the more maintenance is an issue. And doing good React essentially requires, at this point, using Babel, and as soon as you're transpiling, well, the surrounding tooling and library dependencies skyrocket. Not to mention that debugging transpiled code either means you're wading into transpiler-generated muck, or you've got to maintain yet more tooling to step through things in something that's not the browser.

I was originally going to use Handlebars, which I've liked for years for its exceptional thinness & the way it encourages minimal business logic on the client, but caught Shawn Wildermuth on Jesse Liberty's Yet Another Podcast, and heard him talk about VueJS. VueJS is essentially Handlebars with, afaict, a few more recent lessons baked in. The syntax is actually very similar to Handlebars in many ways.

Here's what eventually won me over:

Unlike other monolithic frameworks, Vue is designed from the ground up to be incrementally adoptable. The core library is focused on the view layer only, and is easy to pick up and integrate with other libraries or existing projects. On the other hand, Vue is also perfectly capable of powering sophisticated Single-Page Applications when used in combination with modern tooling and supporting libraries.

It looks like we've got good room to grow using VueJS' conventions if we want to do a full SPA in the future.

I also debated not using Bootstrap, but I don't think it's worth the time to roll your own responsiveness when Bootstrap does it so well. It's over 200 KB total, but if you have it cached, that's a one-time hit that's smaller than most images. You're fine.

jQuery was also debatable, since you can handle DOM manipulation fairly well by wrapping vanilla JS with some convenience wrappers to check for DOM existence, but at 69 KB? Come on. It's well known, rock solid, and has good industry support. Use jQuery.

This looked nice. Simple, API-only and REST convention compliant server. No licensing fees. No JavaScript transpilation required, which will pay for itself in spades when you're debugging. Thin client. Clean separation of concerns.

I was going to go through my headaches setting everything up here, but I'll split that into a new post later. The quick version? Because of a wack nuget configuration I didn't realize was an issue (command line nugget didn't pick the "right" nugget server; I had a local one set up in VS2017 as well), I'm using SQL Server for now, though I will probably give PostgreSQL another look before I settle on a dbms.

1 If you want the cleanest stack, there's nothing more advantageous than using the same language on the server and the client. Node lets you do that. There's some overhead (learning & setup tedium) standing up a web server -- do you just use Express everywhere, or serve from Nginx? -- but nodejs is The Right Answer, imo. But I'm a C# guy "professionally", and there still seem to be more opening for C# devs than node, so I think there's an argument that a C# server-side should be easier for a customer to have maintained going forward.

Labels: , , , ,