I won't try to guess the industry trajectory as a whole. But I can speak from personal experience. I've been on teams jump on the single page application bandwagon. React in particular.
It's been 5 years since initiating that investment. Reflecting on it I'm frankly amazed at the amount of technology that we don't need. The standard type of UI we build really hasn't changed but the time code and overall cost continues upward.
Looking back to 2018 we might have been collectively beguiled by the self-perpetuating marketing machine of single page application technology. We've decided unless there's a very clear and specific justification to write a thick client on a web page we're avoiding it going forward.
Tools such as HTMX are perfectly effective substitutes at far lower cost. At least for what we need
When you have a team with predominantly back-end knowledge expertise using a templating language they are familiar with plays to their strengths. MVC applications were written for over a decade. Perhaps it is a subjective thing because I don't see any logical difficulty in a web page that exchanges partials instead of JSON. I was programming that way for over 10 years.
Svelte really sounds compelling from what you're telling me. I'll check it out. But unless it is a drastic simplification it brings with it the fundamentals of effectively writing a thick client in JavaScript or TypeScript and all the things that come with it. React and angular have left a very bad taste in my mouth. The time and code cost for building basic user interfaces should go down not up. We should be spending less time talking about how to do something and more time talking about what to do
Recently we went through an exercise where we built a to-do simple app using react and rewrote it using HTMX.
The functionality was identical between the two apps. The amount of tooling code and duplicative logic was massively higher because of SPA and all the fundamental things it demands.
Now if you really need an SPA for your requirements because you have an intrinsically complex front end and you've mastered the hoops to jump through good for you! There's nothing wrong with that. But there is something seriously wrong with building the same user interfaces we've needed for decades but the time code and complexity drastically increasing for no justifiable reason.
By choosing an SPA. You must choose a dedicated static site hosting which is separate from your web application. You may already have this but you may not. In most cases you must choose a framework for routing. Also a framework for state management. You also dedicate to duplicating validation and security trimming logic both on the client side and the server side. More often than not you will find yourself including hundreds of NPM packages as dependencies which you must continually update and maintain. Also the requirement for unit testing on the front end is common. Which brings in the need for things like jest and enzyme. This complexity inevitably trickles into your build and deploy processes. Perhaps in larger teams this is a burden you can absorb. In smaller teams however you start to see division of responsibilities. One person only knows front end but not back end and vice versa. Common knowledge of the application as a whole can become fragmented. Perhaps the day comes where you want to take a partial of a user interface posted in a peripheral application and place it inside your web page. Because you have a virtual DOM this is now a security risk. You must build a component which duplicates the user interface which already exists. If the user interface needs to be shared among many applications you must build a commons code base to host your components. You start shouldering the burden of maintaining component libraries instead of just HTML and CSS. Again this is all very general and hypothetical but it feels worth pointing out some of the common implications that simply choosing an SPA can have in the longer run.
Plus this is not an all or nothing sort of choice. For decades we have used Ajax to perform partial updates on a web page. Consider alternatives like HTMX as a comparison.
In more cases than not I've noticed the choice of single page app itself is pure overhead.
SPA technology brings some key advantages but also a whole new realm of cost and complexity. It's my experience that SPA popularity has convinced many folks to use it when they really don't have a practical reason to justify it.
How would this work from a fault tolerance perspective? For example the listening application happens to be offline but the database is inserting records. How would the application catch up?
Perhaps the overhead of chatty queries is diminished in this special use case.
But it doesn't change the fact that standalone database server processes are designed to support specific queries at lower frequencies. This is one of the main points of The SQL language is to load precisely the data that is needed in a single statement.
Relying on this is a design pattern would only scale in specific use cases and would hit hard walls in changing scenarios
What's the point of this article? An attention getting headline followed by some bombastic claims followed by walking them back later in the next paragraph. It's like generating debate for the sake of debate.
I get the impression these things exist just to keep engagement numbers up
I look at it differently. If vim is a useful tool in your daily workflow then it's probably worthwhile to invest time into customizing it and enhancing it with plugins.
The open source landscape of plug-in development is under constant evolution and it can be quite a time sink staying on top of the latest and best tooling.
I see SpaceVim as something similar to a Linux distribution. The maintainers offer the work of selecting various packages inversion combinations that harmonize into a consistent system.
And just like any Linux distribution you can agree or disagree with the packages they choose or the default configurations it comes with.
I end up using a somewhat heavily customized SpaceVim that I personally like but it's my opinion the distribution is a very productive foundation.
I used to think the same thing until I considered that single page app development is really just a reinvention of thick clients.
When you look at an SPA as a thick client state management is a natural thing as it was in Java swing and WPF and Windows forms and other stacks beyond my knowledge
If your team is comfortable writing in pure python and you're familiar with the concept of a makefile you might find Luigi a much lighter and less opinionated alternative to workflows.
Luigi doesn't force you into using a central orchestrator for executing and tracking the workflows. Tracking and updating tasks state is open functions left to the programmer to fill in.
It's probably geared for more expert programmers who work close to the metal that don't care about GUIs as much as high degrees of control and flexibility.
It's one of those frameworks where the code that is not written is sort of a killer feature in itself. But definitely not for everyone.
"Please provide to the public, in an expedited manner, all information necessary to identify all proposals of known-vulnerable code from any U of MN experiment. The information should include the name of each targeted software, the commit information, purported name of the proposer, email address, date/time, subject, and/or code, so that all software developers can quickly identify such proposals and potentially take remedial action for such experiments."
That sounds more than reasonable as a request to make amends.
The article said that finding all this code is a real problem. If UMN and the students involved are contrite that should be easy to fulfill.
Thanks! It's still a lot of hoops to jump through coming from visual studio perspective where all settings can be imported or exported to a file. But this is workable!