Hacker News: pweissbrod

New comment by pweissbrod in "Things you forgot (or never knew) because of React"

pweissbrod — Tue, 15 Aug 2023 11:35:45 +0000

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

New comment by pweissbrod in "Simple Modern JavaScript Using JavaScript Modules and Import Maps"

pweissbrod — Fri, 17 Feb 2023 14:56:26 +0000

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

New comment by pweissbrod in "Virtual DOM is pure overhead (2018)"

pweissbrod — Wed, 01 Feb 2023 22:59:08 +0000

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

New comment by pweissbrod in "Virtual DOM is pure overhead (2018)"

pweissbrod — Wed, 01 Feb 2023 21:22:59 +0000

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.

New comment by pweissbrod in "Virtual DOM is pure overhead (2018)"

pweissbrod — Wed, 01 Feb 2023 19:59:32 +0000

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

New comment by pweissbrod in "Virtual DOM is pure overhead (2018)"

pweissbrod — Wed, 01 Feb 2023 18:08:23 +0000

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

New comment by pweissbrod in "Virtual DOM is pure overhead (2018)"

pweissbrod — Wed, 01 Feb 2023 18:07:02 +0000

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.

New comment by pweissbrod in "Virtual DOM is pure overhead (2018)"

pweissbrod — Wed, 01 Feb 2023 17:33:18 +0000

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.

New comment by pweissbrod in "Push-based outbox pattern with Postgres logical replication"

pweissbrod — Fri, 28 Oct 2022 14:39:25 +0000

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?

New comment by pweissbrod in "LiteFS"

pweissbrod — Thu, 22 Sep 2022 21:03:33 +0000

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

New comment by pweissbrod in "LiteFS"

pweissbrod — Wed, 21 Sep 2022 18:47:45 +0000

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

New comment by pweissbrod in "The self-fulfilling prophecy of React"

pweissbrod — Thu, 08 Sep 2022 13:06:11 +0000

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

New comment by pweissbrod in "SpaceVim 2.0"

pweissbrod — Thu, 07 Jul 2022 13:02:26 +0000

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.

New comment by pweissbrod in "The new wave of React state management"

pweissbrod — Sat, 02 Jul 2022 16:02:45 +0000

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

New comment by pweissbrod in "The new wave of React state management"

pweissbrod — Sat, 02 Jul 2022 15:59:40 +0000

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?

New comment by pweissbrod in "Lessons learned from running Apache Airflow at scale"

pweissbrod — Mon, 23 May 2022 19:14:28 +0000

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.

New comment by pweissbrod in "Firefox DNS-over-HTTPS"

pweissbrod — Fri, 08 Apr 2022 14:11:23 +0000

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

New comment by pweissbrod in "Linux Foundation’s demands to the University of Minnesota"

pweissbrod — Tue, 27 Apr 2021 22:33:21 +0000

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

New comment by pweissbrod in "Linux Foundation’s demands to the University of Minnesota"

pweissbrod — Tue, 27 Apr 2021 14:00:46 +0000

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

New comment by pweissbrod in "Show HN: I built a VS Code Theme Creator – easily make VS Code themes in browser"

pweissbrod — Wed, 31 Mar 2021 17:49:01 +0000

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!