|
What's frustrating to me is that even though a lot of these frameworks and tools keep advertising themselves as making you more productive and letting you write less code in the pursuit of better client experiences -- ie, creating an "SPA", a single page application -- they keep adding more tools your way and more required boilerplate for you to write. You can argue that it's inevitable as they "mature", but then someone comes along a year later with a fix to those problems and you're forced to relearn everything to keep up. This cycle then starts over anew for the next 2-3 years as more tools and required boilerplate are added and someone gets frustrated enough to provide a new framework and tooling. I've gone through this, in turn, as I've developed applications from plain old JS, to jQuery, to Backbone.JS/Marionette, to AngularJS, to Angular, and most recently to React, along with the similar change in tooling through Grunt, Gulp, and Webpack. Each time as the amount of boilerplate I'm forced to write begins to frustrate me, a new framework conveniently rolls around and convinces me to switch. I haven't looked at Vue.js yet, but a co-worker on a different team showed me a React/Redux project and I ran away screaming -- figuratively, not literally! -- from the boilerplate involved (if you're wondering, so far I've been pairing React with MobX but the applications haven't been particularly big). The dev experience has been better each step, but it's not been an easy ride and it's obvious that these frameworks don't represent the end of the chain. All this time I thought this was just the required tax for providing a nice front-end experience, but recently I've been diving heavily into Blazor Server-Side and Phoenix LiveView on some personal toy projects to see what the server-side landscape is like, and it's a breath of fresh air. It's surprisingly quick and easy to write code that provides an SPA experience where changes on one connected client immediately propagate to other connected clients, and with so little code to boot. They have their pros and cons, but the dev/productivity experience has felt so much better. Because C# is such a great language, Blazor is super easy to jump into and immediately understand what's going on, and since it's part of ASP.NET you're not going to lack in good libraries/documentation/examples/support. However, it doesn't really have a good reload-on-changes functionality yet even while running under dotnet watch, as you'll have to manually reload your browser tab after changes. Phoenix LiveView on the other hand has a great reload-on-changes functionality for fast iteration, but its drawback is that it has a much steeper learning curve and initial hurdle. Fortunately it's offset by the fantastic documentation it provides, but it is something to keep in mind as it makes on-boarding people not used to Elixir/Phoenix a bit difficult. Honestly, if the OP article resonates with you, I recommend giving one of those two server-side frameworks a spin. It's nice to temporarily escape from the craziness of the modern JS landscape, and to not have to write your models twice. |