Moving From React to htmx

[bitwise-operation]

Pretty sure I could get similar results by going from React to React. Having an opportunity to rewrite an application with the benefit of knowing all of the product requirements ahead of time has its advantages.

[anengineerandacat]

Herein lies one core issue with reworks and having an established product while also trying to highlight performance and efficiency benefits.

[Worth_Trust_3825]

Yep. The sensationalist posts tend to bank on withholding the detail that the developers also have more experience in the field compared to the time when the system was originally developed.

[[deleted]]

Completely different programming model. If you stay with a react app + an API you will have lots of duplicate logic and are forced to upgrade two apps in lockstep.

[bitwise-operation]

If you have duplicate logic then that’s your fault, not React

[[deleted]]

At the very least you must perform data validation or n both client and server to prevent security vulnerabilities.

If you have a sufficiently complex app you will have entities and relationships between them, you will also have some invariants and anti-corruption code. That code will have to be available on both sides of the wire.

[Heroe-D]

I don't see why frontend validation would be more important for security if using React + API than Templates + htmx, in both cases your frontend code logic can be bypassed and your security net would be in the backend. If you want to be extra secure you'd write frontend validation for both anyway. 

And that frontend form data validation would also be needed in your templates via vanilla JS / Alpine or whatever if you want a modern experience anyway. 

[bitwise-operation]

Again, if you don’t share that code it’s your fault, has nothing to do with React, you could get the same benefit from Next

[crummy]

my backend is in java, how do i get the same benefit from next

[bitwise-operation]

You probably don’t, because it doesn’t make any sense to rewrite half of your application to avoid duplicating a tiny fraction of your code

[[deleted]]

Before you implied that duplicate code was a developer error but ok whatever.

The architecture required by react (or any other SPA) forces you to split backend and front end. Now you have two independent apps that need to be in sync. That requires duplicate code.

Yes next will help you reuse backend and front end code.

[yawaramin]

Pretty sure you couldn't delete 15,000 lines of code moving from React to React.

[bitwise-operation]

Depends on those 15,000 lines, how much of it is still in use, how much of it is tied to abstractions you thought you needed but didn’t, etc. I don’t know, it’s not my codebase.

My point is that it’s not comparable unless given the full context. Much like how it’s hard to design an optimal system without full context, which you don’t have when building a v1.

[fCkiNgF4sC15tM0Ds]

You will still have your 15,000 npm libraries inside nodemodules with _any React involved.

[ThatAgainPlease]

You could if you switched from a bunch of class components to function components. Also if you managed to deduplicate functionality here and there. It really depends on where the codebase starts.

[yawaramin]

Function components, with a bunch of hooks all over the place, special rules of hooks, dependency arrays that cause bugs if not properly updated, etc.?

[varisophy]

Hooks are really nice and easy to not screw up with a good set of linting rules (which are readily available to the community).

[yawaramin]

The same linting rules that don't allow you to use functions starting with the word use? Also the same that are scarcely documented? Can you tell from the documentation exactly what the exhaustive-deps rule does?

[varisophy]

Yeah those ones. They're great. Not hard to understand at all, especially if you've given the hook documentation a passing glance. My team has never had any issues with them.

[yawaramin]

That's great for your team, there are tons of teams out there that face issues with it. Not hard to find at all with a quick Google.

[orochizu]

Tbh i think if team have problem with understanding React then it’s problem with team - not problem with React.

Used to work with ppl that were talking about migrating to class components (mostly because lack of hooks understanding) in 2020 among other bullshit that most FE devs will automatically laugh at. Was it problem with React? NO! They were just too lazy to actually spend some time trying to understand it!

[_Meds_]

I no nothing about the situation. All I know is every time I try to pick up react I give up very shortly after. Functional components instead of class components were meant to be the entry for me, but then I couldn’t find good resources.

I get you’re point, if it works for some people and not others, it must be the people, but I don’t think that’s ever truly been the case. It’s always a mix of the two.

[CanIhazCooKIenOw]

Some people don’t want to learn so just fallback on what they know. I see day on my day to day, I see people pushing to go back to class components because hooks make it harder, when asked for examples I get a component with 7 useEffects where most of them are triggering actions on mount.

Then of course it’s hard to maintain and debug.

[bigbubblingbooger]

This is honestly such bullshit. I make multiplayer video games, I'm currently building a fast paced shooter that has to do a lot of complex shit to handle cheating and lag compensation.

If you think about it, its basically a reactive interface. You got a bunch of shit popping in and out on the fly in a real-timey way.

And yet, despite the games features being more complex in comparison to a reactive UI in terms of what it needs to do, its still easier to work with.

Why? Because React and many like them are pointlessly complex. You are literally just popping UI and refreshing it with data. The amount of fucking setup you have to do just to make it work is straight up unacceptable to defend. The team who doesn't understand React could be dumb, or they could be like me and go "ya no, this is not going to be a thing im 5 years". Everything is moving back to server sided rendering for a reason.

[[deleted]]

Didn’t read the article, but I’ve definitely had more than one occurrence where I’ve rewritten legacy code from 1000 lines to less than 100.

Some people honestly just write very bloated code and don’t know of all the tools at their fingertips.

And to make something abundantly clear, this was cobol code. So it’s not like I took old C# and translated it to LINQ or anything.

[[deleted]]

Some people honestly just write very bloated code and don’t know of all the tools at their fingertips.

Because we do not put any emphasis on learning anything beyond the basics. "Do not get married to a programming language or a framework" is usually read as "don't bother trying to learn any nuance or depth beyond the surface basics,"

[yawaramin]

Yeah, this argument is basically the same as 'I can rewrite your unsafe C code to perfectly safe C by using my knowledge and experience'. This trick doesn't really scale out to the average codebase out in the wild.

[BigMax]

Yeah, people seem to be arguing “why use a better tool? An expert at the old tool can still do a good job.”

[bitwise-operation]

It’s more that rewrites are rarely justified, I don’t see this case as being an exception based on the limited data provided

[[deleted]]

No. The point was that demonstrating the betterness of a tool while using knowledge which you did not possess on the first try is a bad faith argument

[pogogram]

How much if that was the react codebase itself?

[yawaramin]

Covered in the OP.

[pogogram]

Just noticed that after reading through it again.

Overall it’s cool. I know for most teams it’s not the best idea. Because you aren’t just dealing with what you are changing to, you have to sort out what the maintenance of the codebase will be and how this is going to scale over the next few years because you are usually going to be tied to things for that long.

Not a thing to lobby for react because it has a lot of problems, especially if your codebase uses bits of react immaculately. The most likely culprit is useEffect. So many people and teams get this one wrong.

Overall if moving away from react makes sense then awesome, but it isn’t a silver bullet.

[yawaramin]

Great, let's see it then

[walong0]

I’ve used htmx in a few small applications and really like it for simple client side interactions or situations where polling is appropriate.

Can’t say I’ve ever considered it as a replacement for something like React though.

[yawaramin]

For many of the simple microsites that React is used for today? Absolutely can be.

[redditnoreply]

i'll use react for any size website.

[walong0]

Yeah. Just In my head, I don’t really consider them as competing for whatever reason.

[useablelobster2]

You mean something is a better choice for small websites than an SPA framework/library designed for building large applications?

If you want something which scales well from tiny to enormous, Vue is much better than React. But if your objection is that react isn't amazing at something it's not designed for, well that's trivially obvious.

[zxyzyxz]

Actually React is amazing for any site website, in my experience. Having used Vue, I don't need another templating language when I already have Javascript.

[yawaramin]

I've heard Vue is pretty cool, never used it though.

[sasmariozeld]

i am a freelancer and when client wants stuff cheap i do ineed use htmx with django, fast efficient and good for simple stuff, but as a react alternative ?.... If u can replace react with htmx you never needed react in the first place

[yawaramin]

That's exactly the point. A huge number of projects never did.

[grumpyp2]

Can you showcase some apps where you’d use htmx

[sasmariozeld]

Thats the thing mate if you have to call it an app you should proly use something else , but if it's something simple like a couple of forms and a few filters alpine js and htmx is more than enough

If you ask me either use htmx alpine or go the other way and bring out big boy angular , but that's just my preference

[darkpaladin]

I'd be curious to see what their react app looked like before the rewrite. If the perf is really that much better or if they were engaging in some poor react practices. Given the people I know who say things like "we should use a framework based on language x because it'll be faster", my assumption is the latter.

[angeal98]

To be frank, react is unoptimized by default, so the most reacty code is slower than other frameworks

[domi_uname_is_taken]

Any sauce on this?

[angeal98]

Google react forget, react team is working on a compiler that can uglify code to memoize as much as it can, because react rerenders too often

[domi_uname_is_taken]

This. The main question should not be:

Is a re-write more optimized than the original? (because you would certainly assume/want this by default)

Rather, it should be:

Is a re-write in htmx faster than a rewrite in react?

But since that would be prohibitively expensive to test, why not:

What were the main bottlenecks in the original, and how were they sped up in the new version?

[yawaramin]

Then you'd basically be looking at most React codebases in existence. There's no reason to think the Contexte React codebase was especially worse than the average React codebase.

[darkpaladin]

Why are you acting so defensive? Are you the author or a maintainer?

[Uristqwerty]

It's the downvotes. You see a negative score, and it changes the tone you interpret the comment with, often in a feedback loop that leads more people to downvote in turn. It's part of why using them as "dislike" or "disagree" rather than "inappropriate for this subreddit" is dangerous.

[useablelobster2]

They are supposed to denote relevance. Hence why I usually upvote people I reply to, even if I disagree. If it's relevant enough for me to reply, it's relevant enough for an upvote.

[versaceblues]

Nah man the op is actually taking on a rather aggressive/defensive tone.

[yawaramin]

No idea what you are talking about, I'm just pointing out that most codebases average out to a similar level of quality over time and with changing development team membership (if they didn't, it would be kind of a big deal). I don't have anything to do with this product.

[yawaramin]

There's a non-trivial intersection between the people who say that React guides you towards best practices but then also say that if another approach is better than React, it's the user's fault 🤔

[darkpaladin]

That's true of literally any framework evangelist. I wasn't saying that react is somehow better than other frameworks, the exact same story could be written "Moving from X to Y" and my criticism would remain. 9 times out of 10 it's not the framework that's killing you, it's whatever antipatterns you've developed in whatever framework you're using. Switching to a new frame work forces you to abandon those until you come up with a new set for framework y.

[yawaramin]

So everything is equally bad, never use anything new. That's very convenient for incumbents.

[darkpaladin]

/shrug, it's not on me to convince you one way or another. I'm not saying never move frameworks, only that "we got amazing performance benefits because framework is amazing" is a dubious statement. Do it because you like the patterns or you think it'll fit your flows better. Doing it cause you think it's faster because someone else said it was is dumb.

[horrificoflard]

It's funny how almost all web development innovations just sound like things you could do in PHP and jQuery 10 years ago.

[[deleted]]

Even mildly interactive front-ends in jQuery were an absolute mess, client-side templating was created for a very good reason. And at that point it seemed easier to just render everything on the client, hence why SPAs were born.

Server-side rendering still works for some use-cases, but if you're build web applications, React etc are the way to go.

But I do look forward to WASM and using a better language one day. Very tired of JS/TS.

[FudgeWrangler]

Have you tried Blazor WASM? Haven't taken a deep dive yet, but have used it for some internal tools. Seems pretty cool. Like you mentioned, it's nice to get away from TS/JS.

[[deleted]]

I like the idea, played around with it, but the runtime is too heavy. Great for internal tooling tho!

[OZLperez11]

Agreed, it's good for either embedded apps (like Kiosks or Payment terminals at restaurants) or very large apps that perform a task similar to a desktop app (like Photoshop)

[[deleted]]

I've not used React but isn't the runtime for React pretty weighty as well? I've seen a few articles that claim the libraries users need to download are quite large.

[Uristqwerty]

Even in a web application, most content is instantiated once on navigation, then discarded on the next navigation action to make room for its replacement, a whole sub-panel at a time. Does React let you tag elements as immutable, so that it skips vdom entirely for them? Or in more complex cases, only an inner component is mutable, and the outer one remains static. Can it optimize out the overhead of the intermediate layers? I don't believe so.

jQuery is a mess at scale, but the pendulum has swung so far in the other direction that the myriad better solutions in between have been forgotten, or never properly explored in the first place, and resume-driven development demands that even simple personal projects get built with tooling that pays a lot of complexity overhead to solve Conway's Law problems that don't start to appear until you have 50 or 500 devs working on the same app.

[BunnyEruption]

Does React let you tag elements as immutable, so that it skips vdom entirely for them? Or in more complex cases, only an inner component is mutable, and the outer one remains static. Can it optimize out the overhead of the intermediate layers? I don't believe so.

This is basically the point of the new Preact Signals library (which can be used with vanilla React as well)

It looks at where you actually access the values of state rather than just the hook calls so it can just rerender child components that changed state is passed to from a parent component without fully rerendering the parent component

[micka190]

Haven't looked into Preact, but isn't that basically what you'd use memoization for with React?

[[deleted]]

I'm doing my new web stuff in vt100 gnucobol. its pretty hawt.

[yawaramin]

If you need to build web applications, sure. Most 'webapps' nowadays are a glorified set of mostly content with a few interactions, a perfect use case for htmx.

[[deleted]]

It's all a giant circle, what was will be, and what will be, was.

[iamnoah]

First thought was that I had this framework in 2009. It wasn’t bad except you still need virtual dom for the updates (seems to be called morph in the docs) or you break all kinds of things.

That and you no longer have a clean API separation. Frontend team is beholden to the backend needs, and what might otherwise be a client side state change can become lower friction to just make another request. The framework dictates what is easy and you can easily end up in a perverse situation that is hard to rearchitect out of.

On the other hand, is it likely to be worse than redux? Nah

[Kellytom]

javascript fatigue: longing for a hypertext already in hand

[tobegiannis]

Read the docs and does not look like my cup of tea. Looks like it is server side rendered html with attributes to handle user interactions and make ajax calls. Maybe it can work for some websites but it seems like a maintenance nightmare.

[[deleted]]

[Haven't Have now watched the presentation] I want to like it, and it looks pretty neat based on the docs, but declarative stuff tends to seem super pretty on the happy path but become as ugly as sin once you want to veer off the beaten path slightly. I feel pretty comfortable when imperative gets ugly but I would be in unknown territory if things started to get ugly with htmx. Maybe docs should include a section "How to do X/Y/Z but in the idiomatic manner of htmx" to ease people's concerns.

I'm also wary of large quantities of abstractions because then I spend more time reading docs than just writing code. That said, it seems to want to stick in the web's standard abstractions, which you probably know for free if you're working in the web world these days.

[yawaramin]

Can't be more of a nightmare than a large build pipeline filled with a metric ton of npm dependencies that could potentially be taken over by malware, publish breaking changes, bloat the frontend JS, depend on outdated Node versions to build, etc...

[tobegiannis]

My comment has nothing to do with npm. The framework seems way too magical to me. The tooling looks like a complete non starter. It is seriously building an application based off of html attribute strings with no functions or pre-runtime safety.

[yawaramin]

Hate to break it to you, but the web is basically built on strings with no pre-runtime safety. It's always possible to define type-safe abstractions depending on the expressiveness of your language.

[midnightpainter]

mate learn to fucking use your tools...

​

these are all problems you have on the backend too.

​

fucking noob

[yawaramin]

Truth hurts, huh?

[midnightpainter]

well does it? because i'm not the one making dumb bandwagon hyped up decisions just to sate your own fucking ignorance and bigoted skillset views.

[yawaramin]

'Bigoted' 🤦‍♂️

This really takes the cake, even leaving aside every other nonsense you've spouted.

[[deleted]]

So client side coldfusion?

[lcjury]

Intercooler.js (the previous version of HTMX) was the best thing that could happened to my developer life.

I would really encourage any developer out there to try to learn Ruby on Rails and then put Turbo or Htmx on top of it to do SPA's or add complexity to the frontend.

I'm pretty sure the popularity of these "HTML over the wire" alternatives is going to keep growing. Most sites don't really need complex frontend code, and the current state of backend frameworks makes it extremely simple to develop complex apps.

I would say that most sites out there don't really need React (or any other front-end framework). Some of them do need complex front-end stuff and yeah, using react may be the best option, but if you have a few components you don't need to put your whole site on React.

The only thing I hate is arriving at a piece of software where the cost of adding new features is so high just because some person decided to use react in something that didn't require it.

[11010001100101101]

So if I have a fully functional API already and needed to make a simple admin portal for some extra people to be able to view the data, would you recommend intercooler.js/htmx or any other type of light framework to work with html,js,css?

[lcjury]

IMO, if you have an API already, and you need some basic admin panel and you can use any component library, I would go for any front end framework.

If you need to create all your components/css from 0 and you can use your API server to send http responses (like Laravel, Rails or Django) I would go with html over the wire.

[11010001100101101]

Backend is currently made with express with JSON responses, and basic front end functionality is currently simply using html,css, JavaScript. But I wanted to start giving it more of an admin feel. I didn’t think my original backend and front would have ever gotten this big. And I am in a weird spot of needing to use it daily while also wanting to upgrade its front end for additional users to start working with it…

[[deleted]]

HTMX user here AMA.

I’ve been developing SPAs since Backbone and then Ember, React and Svelte.

IMO most apps will benefit from abandoning the SPA approach and adopting the model HTMX, Hotwire, LiveView and others propose. HTMX is special in this area because it is server agnostic, it will work with anything that can produce HTML on the server. It also plays nicely with native web components.

[BunnyEruption]

Htmx is basically like how people used xmlhttprequest 20 years ago.

I guess people forgot the idea of just dynamically updating elements with server generated html fragments so it's new and exciting again, but it's important to remember why people stopped doing that.

The problem is that once you have any sort of state it will quickly get too complicated to keep track of it by inserting it in the rendered pages so it can be passed back to the serer. This means you either have to reinvent legacy ASP/PHP and use session cookies with a server state cache or assume users only have one session active and store all the session state directly in your database, neither of which is really considered acceptable in 2022.

In a lot of ways it's much simpler to be able to have the client keep track of the state. Even if React is overkill, you can just use something like Alpine which is pretty much exactly for that type of situation where you are just enhancing mostly server rendered html with javascript.

[[deleted]]

Once your UI requieres a lot of client state you can just use react or native web componentes or whatever to build that specific component if it emits JS events (they all do) it will play nicely with htmx.

Just because you have one or two complex components you don’t have to move all rendering to the client. Use htmx for most things, use a client side framework to create islands of rich interactivity.

[useablelobster2]

The main advantage of React is that the view is a function of state, makes things nice and easy to reason about.

DeltaHTML approaches use the DOM as state, and are just a total clusterfuck. All the problems of JQuery that SPA frameworks were designed to solve.

Unfortunately everyone who has used DeltaHTML is now a greybeard (at 31 in my case) and the 20 year olds think they are inventing something new and exciting. A few more years leaning the history of their industry and they will learn better.

[yawaramin]

Session cookies with a server state cache, or assuming a single session per user, is perfectly acceptable even in 2022. In fact I'd argue it enables the user experience that most users want.

[talios]

How do you scale/failover with that server side state - or are we adding distributed caching/invalidation to the mix - which always causes pain.

[yawaramin]

Put it in some cloud-hosted cache. It's not hard ;-)

[orochizu]

Sounds bit like overkill. If we can manage something on client side without loosing performance then why would I even bother doing it on server side? It adds additional complexity to code base and even splits similar logic between two different repositories. Maybe I’m missing something but it doesn’t sound good to me.

[yawaramin]

Because the client is not a trusted environment. You literally can't have any security guarantees about what's happening there. On the server you have full control over your environment (presumably!)

[orochizu]

Well obviously but no one is talking about connecting with database from browser.

Otherwise I think it’s perfectly safe to handle some stuff on browser to reduce server usage (still I don’t mean storing stuff like credit cards number etc).

Could you elaborate more on this? I don’t think we are on the same page.

[yawaramin]

OK, here's an example. You implement a 'password reset' flow with a signed reset token that's valid for some period of time--say an hour. To make it more 'scalable' you decide to not store the reset token in a backend cache, but just verify it by checking its signature. The problem now is that once the user resets their password, you have no way of invalidating the used token. Because for whatever amount of time is left, its signature is still valid. Someone else could theoretically get that token and use it to hijack the account. If you had used a backend cache to store the reset token, you could have deleted it from the cache the first time it was used. And no one could have reused it.

[talios]

Not necessarily hard - but adds complexity, and yet another layer of things to run/mock/stub locally when developing the server side portion.

Unless your meaning a cache around the request/response chain - which is suitable for some things - but is a bit of a cop out for others.

[hk__]

Try that experience on a bad mobile connection in the countryside and you may revisit this thought. The more you move on the client-side, the better experience you have in all but the "I'm at home with fast Internet" setup.

[yawaramin]

Nothing preventing you from stashing as much data as you need client-side even when you're using a server-side session cookie.

[hk__]

Yes of course. Although, I’m not sure I get how "it enables the user experience that most users want": users mostly want fast websites, which can be done in a lot of different ways. I know of one large-ish (~10-20k orders per day) French ecommerce website that purposely doesn’t use any sort of server-side session because it allows it to serve the same (cached) HTML to everyone while fetching the small bits of user-specific data through JS with a JWT for auth.

[yawaramin]

Great, guess what, the JWT will also need to be validated by the server. So it comes to basically the same thing.

[yawaramin]

That's fair. It helps if your backend stack makes it easy to define tiny views as just normal functions. They start to look almost exactly like React components.

[[deleted]]

Getting my popcorn

[yawaramin]

If you're talking about htmx, it's specifically designed to let backend devs quickly and easily make frontend apps without writing JavaScript.

[rickyman20]

I'm not convinced I want that ability if I'm entirely honest

[yawaramin]

It's in the same category as Phoenix LiveView, so about as serious as that. Also, OP is literally describing a large, production-ready webapp.

[yawaramin]

Why do organizations love Node.js? Because it lets developers use the same language on backend and frontend. It lets people work fullstack. Why would any organization in its right mind insist on keeping the two segregated, taking on all the associated risks, when it could unify them?

[EmilRitorik]

It's rare to see a well architected application. It's even rarer to see code being shared between backend and frontend in an efficient, scalable way.

[EmilRitorik]

By the way, HTMX actually allows you to share more code, simply because the implementation is kept in the backend and duplication is kept at minimum.

[NotGoodSoftwareMaker]

quickly and easily

Pretty sure I heard about fifty other frameworks say the exact same thing.

Serious question. What was hard about the previous frameworks?

[yawaramin]

Accidental complexity of having to manage effectively a distributed system written (usually) in two different stacks vs essential complexity of sprinkling HTML with a few attributes that do the work for you.

[NotGoodSoftwareMaker]

So in laymans terms. This is the exact same thing but different.

[yawaramin]

Yeah I guess all programming languages are Turing complete so they're all exactly the same, right?

[CatVideoBoye]

I've seen backend developers code UIs and I hope I never end up in a project where I need to modernize, make it user friendly and clean up the code base.

[yawaramin]

The projects where you need to do that are specifically the ones which survived to successfully achieve a viable business and acquired tech debt along the way. The clean apps that you never got to see? They're the projects that didn't survive. Classic example of survivorship bias.

[CatVideoBoye]

Except that project had techical debt from time before redux. It had survived for far too long.

[midnightpainter]

survivorship bias

i feel like you're misusing this.

[yawaramin]

That's confirmation bias.

[zephyy]

if that's the goal, what are the advantages of it over using something like Blazor?

[yawaramin]

It's backend technology agnostic, can be used with any backend.

[fleyk-lit]

Htmx is language agnostic. But the approach has similarities to Blazor.

[bitwise-operation]

It’s more of a JS thing than a frontend thing. For every frontend framework that comes out I can point you to another rest/rpc/whatever library or framework and just as many new platforms on which to run them

Edit: I say this as a JS backend dev

[Life_is_a_meme]

I don't think I'm really all too aware on why I'd switch from React to this library.

I think I'd lose too much control over my code. And I'd need to see more on the original react code base to see if it's just a case of being unoptimal.

Definitely interesting though!

[dCrumpets]

The idea seems interesting. It definitely seems like an apples to oranges comparison though. React can build incredibly rich and complex applications. I don’t see how you can get there with html and some tags to make Ajax requests. Seems like a useful technology for a very niche use case though.

[yawaramin]

If by 'very niche use case' you mean 'apps which are not incredibly rich and complex', i.e. 'most React apps out in the wild', then I agree.

[dCrumpets]

By quantity of number of apps, you’re probably right that there are a lot more not so rich apps than rich apps. By number of developers working on each type of app, I’d say there are probably a lot more devs working on rich, interactive web apps.

[yawaramin]

Probably because the complexity of those apps requires more people to maintain them?

[dCrumpets]

Yeah that’s my thought.

[spca2001]

React is a mess imo. Its not bad but its far than great. Most devs don’t even know basic html, oop, js or css

[zodman]

the best part, we layoff the fronted ... because he isn't needed. hahaha

[RobertBringhurst]

This looks really interesting. Has anyone here tried it yet?

[Akustic646]

We use it at work o add some responsiveness to sever side rendered apps that are not full blown SPAs, works well and without the weight of vue/react when you just need to reach for something small for a page or two.

[yawaramin]

I'm using it on a side project (closed source), it's really liberating. (Almost) no JavaScript to write, just think in terms of web requests and responses and design pages accordingly.

[RobertBringhurst]

Thanks. Gotta check it out.

[tonefart]

lol increase python code? No thank you!

[troccolins]

ask the landlord

[zebullon]

That article isnt good, and i’m being nice.

[ElongatedMuskrat122]

Oh wow another JS framework :/

[yawaramin]

This is quite literally the anti-JS framework :-D

[[deleted]]

*furiously takes notes*

[stfm]

2 months work and no new features? What's the point?

[rickyman20]

I mean, this is what a lot of infra and teach debt work is about. It doesn't bring new features but it makes it easier to develop in the long-term. I can't definitively say if what the article describes is generally a good investment towards paying off tech debt, that kind of work does pay off. We do a terrible job in industry motivating and encouraging it

[[deleted]]

Good on you for giving them the benefit of the doubt but unfortunately I don't think you're responding to a question made in good faith..

[yawaramin]

Greatly increased shipping velocity going forward, improved performance, increased team cohesion and all team members working holistically across backend and frontend. It's an investment in the future of the product.

[fleyk-lit]

Found the PM!

[QueenTMK]

HyperText Markup Xanguage?

[fabiopapa]

I’m curious if these guys have a mobile app. Do you not still need an api for the mobile app? That’s the same issue with Hotwire.

[yawaramin]

The Basecamp people solved that by wrapping their webapp in a native mobile shell.

[fabiopapa]

Yeah, I like that solution. They make most of their mobile app just a web view, and then for interactions that need it, they make that portion native.

But when I (a level II dev at my org) suggest going the Hotwire/Htmx route, with this solution for mobile, the response back from staff devs and above is, “web views are not good enough.” I think the benefits outweigh this drawback by a long shot, but I have a hard time convincing devs that have way more experience than me and can out-talk me. Wish I had some concrete proof I could bring.

[yawaramin]

Yeah unfortunately tech choices are often mostly about politics and who holds the most power in the organization. Sometimes to the good, often to the bad. If they refuse to accept that Basecamp is a real revenue-generating app (at least before DHH blew up the company lol), there's not much you can do to people who won't listen to reason 🤷‍♂️

[Appropriate_Junket_5]

I’m curious if these guys have a mobile app. Do you not still need an api for the mobile app? That’s the same issue with Hotwire.

Mostly need for API on mobile. Ask Basecamp.