np-uh-oh
I recently had a discussion with a friend regarding the state of front-end web development. Within the last couple years, the prevalence of single-page applications has introduced layers of abstraction that have muddled getting things done. Superset languages have lived and died. Choosing a framework for a non-trivial app has become an anxiety-ridden exercise, with the primary concern being the stability of development in a framework. It takes entire days to set up a tool chain and many more to learn archaic features unique to particular abstractions.
And then there are the npm packages. Framework writers love modularity, but when one module does barely anything or has a bazillion dependencies, it's hard to see what is breaking and what is working. The real kicker is that the individual authors of the packages are continually upgrading packages and breaking your work. It's a real cluster fuck.
Thing is, single-page applications are amazing. Real-time updates, internal linking, and dynamic routing on the client-side makes me giddy. Based on the discussion I mentioned before, I settled upon Ember.js, an opinionated framework that makes the mundane choices so you don't have to sweat npm so much. It's also popular, robust, and the upgrade to v2 won't break much of anything.
And for the backend, I've decided to avoid node for the backend of my next major project. It is with a heavy heart that I can't develop everything in JavaScript, but the stability of the .NET environment is pulling me in. If you know me well, working on anything Microsoft is heretical, but the company has it's act together, recently open sourcing the platform and introducing the Kestrel server. C# is better for the CPU-bound processes I'm shooting for. It's all under wraps right now, but I'll be writing posts about the hurdles I've had to overcome as I build a scalable and performant web application.