pweissbrod

I'm curious if anyone else is advocating for HTMX as a mechanism to simplify bloated front end code bases

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.

That's the thing. It doesn't really matter. It's sort of like asking what backend tech you pair with jQuery

Not for large DOMs. And for websites which Don't require support for low internet bandwidth this is optimizing for the wrong problem

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

Select N+1 is a fundamental anti-pattern of relational database usage. Reducing the latency per round trip doesn't change this fact.

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

Agreed! I'm surprised at the comprehensive work going into researching the history of state management in this article while completely missing MobX.

What problem does MobX not already solve?

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.

I think this is what Snowden referred to as the concept of "TurnKey tyranny".

Agreed. It's a cool idea. It's not really computer science as much as a penetration test involving humans and processes.

Of course without any semblance of prior consent it isn't quite sabotage but definitely outside the realm of ethical

"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!

So let me get this straight. I make a theme. In order to actually use that theme I must sign up with azure DevOps create my own organization then get a personal access token then publish it to an open marketplace with my information on it then and only then can I get it into my IDE.

Does anyone else see that as ridiculous?

I've been using an almost stock installation of spacevim both in gvim and terminal for the last couple years. It's sort of like a distro of vim plugins dialed in to play nicely together.

Isn't this article essentially what terragrunt accomplishes

I never appreciated the popularity of redux. My impression was astonishment at the amount of boilerplate I needed for what I felt was a vanilla web ui use case. Then the required voodoo of hooking this up to someone else's clever thunk creation to make it work for common use cases. Compare this with mobx where we trust the developer to responsibility maintain state and just give them an object. I'm sure it's useful for some folks with an unweildy amount of state to maintain but for most designs the overhead is too high

This really hits the head of so many nails. Similar to you I think I grew up in deep north. Our generation can not subside in the economy of factories and Timber Mills.

Most of the jobs are seasonal and pretty much all of them directly or indirectly depend on money from greater Boston area. This applies to me as well.

From my perspective the resentment stemming from a northern way of life and values changed by influx of bostonians is understandable.

Most folks moving up from Massachusetts generally don't appreciate that.

Is anyone aware of a respectable security rating system for android apps we can look up before installing something from the play store?

Is there some sort of a security site which rates android apps by their level of respecting privacy, something above and beyond the quality gates of the play store?

Oh no! Some of my sites are still using bootstrap v3! I have so many bootstrap service packs to install, thanks for the heads up.

I dont understand arguments like this. It reads too closely to the anti-immigration narrative I hear all to much in USA lately. If you're hard working, critical thinker, creative then you deserve the opportunity to join us and lowering barriers to all these folks is not something we should perceive with skepticism. Discouraging opportunity so you can have more market share is just plain selfish and bad for society, not to mention the fact that if youre highly qualified you shouldnt be concerned with a growing field of tech workers.

"IMHO redhat deserves its money". I agree. But the vast majority of people employ CentOS which is redhats derivative.

Oracle engineers work hard on java and deserve their money but the vast majority of people employ OpenJDK which is OracleJDKs derivative.