_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
URI Moving on from React, a year later
est wrote 3 min ago:
I think the key takeaway of the article is:
> Code is not an asset, itâs a liability.
> What is the least amount of code we can write and maintain to deliver
value to customers?
regardless of HTMX/Bootstrap/react, the simpler the better.
temporallobe wrote 33 min ago:
Angular apologist here. Learning curve is somewhat steep but I can be
immediately productive in it and testing is built into the framework as
a first-class citizen. Routing, debugging, state management, SSR,
itâs all there. I like the separation of controllers, HTML, spec
tests, and CSS because it allows the developer to reason about these
separately. DX is damn good.
In fact I recently whipped up a front-end UI in a few days using the
BAEL stack (Bootstrap Angular Electron). You still need the data layer
of course, but this would be true of any UI framework unless you want
to go full monolith like Rails (which I still fully believe is a superb
solution).
And having done Rails, React, Angular, and a mishmash of other
frameworks, libraries, and architectures, I can say that a âpureâ
Rails app out of the box is impressively good for most use cases,
especially now with Turbo.
cyberax wrote 33 min ago:
> One of the arguments for a SPA is that it provides a more reactive
customer experience. I think thatâs mostly debunked at this point
That's not true. You absolutely can make edge applications faster than
anything running server-side. A great example is Linear, it can switch
between issues within 100ms (it even supports hjkl keys for
navigation!).
But this requires you to be EXTREMELY careful. In case of Linear,
they're using a sync engine to replicate the data onto the client side,
rather than doing the request/response model.
ec109685 wrote 40 min ago:
Server rendered HTML is all well and good until you want to add native
apps or a first class API layer. At that point, it makes more sense to
have the web be just another client and move as much business logic
into the API layer as possible.
timr wrote 16 min ago:
There's absolutely nothing preventing you from emitting JSON (or
whatever) API responses from the same controller logic that renders
HTML.
Rails makes it easy.
neeleshs wrote 37 min ago:
Even with react, we have found that having a separate API layer was
more ergonomic.
Maybe with graphql it is different
henning wrote 49 min ago:
I have a 6k monitor. why are you embedding a 1400 px image I can view
fine into a little 640px column which makes it hard to read?
oDot wrote 1 hour 6 min ago:
Unfortunately for many of the HTMX/Turbo people, they did right to
identify the problem but they have the wrong solution.
The way to alleviate those issues is not to bloat the frontend with
things that shouldn't be in it nor is it to fragment the code base with
never ending "sprinkle" of JS.
The best solution is something like Gleam's Lustre, where you use the
right tool for the job, while keeping a coherent code base:
URI [1]: https://blog.nestful.app/p/gleams-lustre-is-frontend-developme...
senti_sentient wrote 1 hour 13 min ago:
The older I get, the more I find myself gravitating toward building
with Express.js, using front-end HTML with a touch of Alpine.jsâand
that covers 99% of my use cases. React is mostly an overkill.
phaedryx wrote 1 hour 16 min ago:
I think the idea of "sprinkling" JavaScript into your server-rendered
HTML is a good one. However, I think that Stimulus is terrible.
1. There isn't a good way to test it. There is nothing in the docs
about how to test it.
2. Keeping state in the DOM is dangerous
3. Messaging between Stimulus controllers is painful
4. They disconnect parameters from functions. The functions have to
scan through the DOM to find what they need which I think is
fundamentally weird
5. Reusability is rare
6. It doesn't try to play nice with the larger JavaScript ecosystem.
I personally prefer Vue.
abhgh wrote 6 min ago:
Reg. #2 - I returned to frontend dev. after years for a hobby project
(and even earlier, my frontends weren't very complex, I could get by
with jQuery in the pre-React days), and I am surprised to see this is
popular (or at least a supported feature everywhere). I would also
think #2 is dangerous, but I am wondering if its just me being
simplistic. Aside from a thin layer of reactive controls, when do
people need #2?
nchmy wrote 37 min ago:
Care to elaborate on #2?
htmxsucks wrote 1 hour 18 min ago:
HN is not real world, just like how Reddit is not real world.
I am a FE with 10 years of experience, and has tried, and tried really
really hard and multiple attempts to make HTMX works well.
Doesnât work. UX is much worse, code discoverability is much worse,
slower to code in, everything is messier than just plain React SPA with
JSON data. Terrible, terrible DX and UX.
Seriously, there is a reason why despite all the rage in going back to
multi page Django/Rails app, very very few people actually take it
seriously. You just donât hear the negativity because most folks just
tried it, saw that it is worse, and moved on without writing a blog
post.
neeleshs wrote 19 min ago:
Can you say more about what didn't work with HTMX? What parts make
terrible DX?
I also think HTMX is meant mostly for backend developers to be more
productive in frontend.
sexy_seedbox wrote 32 min ago:
> HTMX works well
Yes, this is a fact. HTMX / Unpoly are just lighter solutions and
much easier to debug.
J_Shelby_J wrote 32 min ago:
Can you share an example of a large react SPA that you would consider
a good UX? One that doesn't have that react, not very reactive
feeling, jank?
zsoltkacsandi wrote 34 min ago:
> Doesnât work.
It worked for us, one of the most visited websites in my country,
migrating away from Vue.js based âmodernâ frontend stack.
It was a huge success in terms of productivity, developer experience,
and cost.
nchmy wrote 40 min ago:
Check out Datastar ( [1] ) . It's similar to htmx, but far more
powerful AND simpler.
URI [1]: https://data-star.dev
henning wrote 47 min ago:
your feelings are not facts.
kopirgan wrote 50 min ago:
If I understood correctly the author of original post is also talking
from real world experience, not running university research lab.
cvdub wrote 53 min ago:
What kind of stuff have you been building?
Epskampie wrote 53 min ago:
I'm a freelance webdev with 15 years of experience, and recently I've
made some new projects with Symfony Stimulus & Turbo to great
success.
A few thoughts:
I tried just htmx too, too limiting. Stimulus/Turbo combination is
much better.
Use the right tool for the job. Highly interactive app, like an
editor? Use react or similar js framework. Mostly page/document
website? A backend framework is much faster and easier to develop,
and much simpler to test.
Use what you know yada yada.
insane_dreamer wrote 1 hour 36 min ago:
> Many interactions are not possible without JavaScript, but that
doesnât mean we should look to write more than we have to.
PREACH. And many site actions can be handle server-side without
degrading the user experience.
arvindrajnaidu wrote 1 hour 59 min ago:
Do you also have a native app? How do you plan on using your current
setup with Swift?
stephenhuey wrote 1 hour 44 min ago:
How about Hotwire Native? [1]
URI [1]: https://native.hotwired.dev
URI [2]: https://pragprog.com/titles/jmnative/hotwire-native-for-rail...
overstay8930 wrote 2 hours 2 min ago:
Watching Meta rewrite Messenger twice without success was enough for me
to never touch React for any large project, especially after that
botched e2ee chat rollout.
cwalv wrote 1 hour 18 min ago:
You think the major complicating factor of rolling out e2ee was that
they used react?
sc68cal wrote 2 hours 8 min ago:
I was worried that an application I was building in Django, with a
frontend built with Bootstrap and some LIGHT jquery was making me look
like an old curmudgeon but the part about testability of the frontend
really resonated with me. It was MUCH easier to structure everything as
pytest unit tests and completely rely on Django for all the business
logic rather than trying to put state in the frontend and deal with
synchronizing states between FIVE distinct systems (remote devices, the
Django application, the database, an event stream, AND the front end).
I recognize that I'm not hip or with it, because I really fell out of
front end development at the peak of jQuery where it was mostly about
fixing browser incompatibilities, but it's nice to see that maybe it
went too far in the other direction and we're overdue for a bit of a
swing back towards server side.
willsmith72 wrote 2 hours 28 min ago:
> p75 at 350ms
Is this really that impressive if you're prefetching? Surely a cached
response is <50ms always. What's the prefetch cache hit rate?
If it's anything like remix/react router prefetch caching, it's also
useless on mobile. Depending on your target market, that's a huge
difference
andrewmcwatters wrote 2 hours 33 min ago:
I removed all of our React and replaced it with Web Components, and I'm
not missing anything.
I'm sticking to cached static resources, and just sending data over.
Not rendering from the server, but not writing single-page apps,
either. The more you render from the server, the larger your caches end
up. Not doing that for HTML.
Just HTML, CSS, and JavaScript. No tooling. No building. Web Components
and fetch(). No frameworks on the client-side. Express still on the
server.
I'm trying to optimize for not swapping out dependencies on a several
year scale, and it's working out pretty well so far. I removed React
because they're not interested in UMD builds anymore, and I'm not going
to jump through hoops to make it work on my end, either.
morganherlocker wrote 1 hour 16 min ago:
Same, and I've found this works quite well with a C++ backend. Just
send over binary data as struct-of-arrays, load it into typed arrays,
render components. Your app will be bottlenecked only on bandwidth,
as it should be, even for heavy 3d applications.
There's nothing fundamentally stopping react apps from being fast
like this, but the dependency snowball has a way of hiding
accumulated dynamic memory allocations and event listeners. Instead,
we should be intentionally grouping allocations and events, keeping
them contained to a few well understood pieces of code. Without this,
these apps could be ported to native C++ or rust and they would still
be nearly as slow because there is no magic language that can make a
slop of millions of tiny dynamic allocations fast and low overhead.
kopirgan wrote 52 min ago:
C++ backend? Could you elaborate please?!
forrestthewoods wrote 2 hours 34 min ago:
The only UI framework Iâve ever used that I didnât absolute hate is
DearImGui. I realize it doesnât produce polished, professional
looking UIs. But my god is it the only thing that doesnât suck.
JavaScript and ReactJS are at least 10 times less efficient to write
than C++ Dear ImGui. Thatâs so crazy.
andrewmcwatters wrote 2 hours 32 min ago:
Dear ImGui isn't for end-user facing UI.
forrestthewoods wrote 2 hours 0 min ago:
Did you read my whole comment? It feels like you didnât read my
whole comment. Because I said âI realize it doesnât produce
polished, professional looking UIsâ.
I donât think thatâs an intrinsic quality of a DearImGui type
API design. Iâm reasonably confident it could produce a
professional end-user facing UI. And that it would be perfectly
performant and battery efficient.
lmz wrote 1 hour 18 min ago:
Good luck making that immediate UI accessible.
forrestthewoods wrote 14 min ago:
Why is immediate-mode fundamentally incompatible with
accessibility?
elchief wrote 2 hours 43 min ago:
Went all in on the BALL stack (bootstrap, alpine.js, laravel livewire)
and couldn't be happier
uncomplexity_ wrote 2 hours 0 min ago:
> BALL Stack
Remove the T, it's cleaner.
65 wrote 2 hours 48 min ago:
I got so sick of having to deal with thousands of dependencies with a
React project, I manually implemented JSX to string components (e.g.
building with ESBuild then writing the createElement and fragment
functions as my own package, which would return a string to render
server side), added Alpine.js, and it's just as, if not more productive
than standard React.
So many fewer packages to deal with (especially if you want to SSR your
app), and my site is way faster. And I get to use JSX which is my
favorite templating engine and requires little porting from my React
app.
I suggest people really take a look at Alpine.js, you can do everything
in it as you can with React and it's a significantly smaller, simpler
package that runs right in your browser.
jack_pp wrote 2 hours 33 min ago:
Can you provide more details about the project you are talking about?
I somehow doubt that a website like facebook would be easier to write
and manage in a minimalist framework. I'm not sure the only project I
have written React for would compare to something like facebook but
it was a pretty complex SPA that I seriously doubt would've been
better written in something like alpine.
Sure React may be overkill for a personal blog and no one is saying
it isn't but I wish people that have ported from React also assess
honestly the complexity of the app we're talking about
65 wrote 2 hours 13 min ago:
I have a website I use to host all my personal software. This
includes a front end portfolio with various somewhat complicated
data applications, I have a personal notes app, RSS reader, content
feed algorithm, games, e-book reader, and S3 file manager. You are
definitely right that complexity isn't as big in terms of number of
users (for me, it's one), though I'm still making functionally
complex applications.
Facebook is obviously going to have a ton of shit going on all at
once, though for the vast majority of sites it's mostly just some
form or another of CRUD with perhaps some somewhat complex front
end UX.
You can build many web apps without React. To me the secret is with
JSX, which makes everything way easier to manage.
Realistically the only issues with using a more minimalist
framework instead of React is global state management and
persistent components on page navigation. Global state management
in Alpine can be done with Alpine.store and persistent components
can be implemented with either Hotwired Turbo, Alpine AJAX, or
HTMX. Are these things better than React Context/Redux and React
Router/Next Router/Some other router? Probably not. But it does
work.
I wouldn't recommend this approach for actual businesses, mostly
because devs will already know React and thus be more productive.
But I think it's genuinely a viable approach for building web apps.
lelanthran wrote 15 min ago:
> I wouldn't recommend this approach for actual businesses,
mostly because devs will already know React and thus be more
productive. But I think it's genuinely a viable approach for
building web apps.
That's just the thing. Businesses chose a specific stack because
the campaigning for that stack won out amongst any competing
stack, not because that stack most closely aligned with their
requirements and needs.
Boring Anecdote Time:
I do contract work. All current frameworks have a velocity for
new API/endpoint creation (with DB schema modification) of
between 4hrs - 8hrs (spread out over 3 - 4 PRs)[1], assuming all
the PRs come back with LGTM.
My home-grown b/end framework cuts this down to between 5min -
20min (one PR only) for the same API/endpoint addition.
However, I only use my home-grown b/end stack for full webapp
development, when a client wants a new system, and only when
that client is not a technology company, or doesn't have an
in-house development team.
That's because most businesses are using what their tech teams
mandate, which IME is either Java, C# or (not as common around
here) a Python or Node b/end.
Once(!) I had a dev manager agree that velocity for MVP and
velocity for maintenance is a higher priority than conforming to
any of the current b/end languages, which included but was not
limited to C++, Java, Kotlin, Python, Node, React, Ruby, MSSQL,
MySQL ... etc.
A few months later, on a call with him he expressed how fast his
dev team was iterating on my stack when extending the system.
Currently they are stuck on a lot of legacy that has to be
extended, but they are definitely thinking about b/end in a new
way now.
[1] Assuming the usual workflow of PR for ORM changes, then PR
for data object layer + unit tests, then PR for domain object
layer + unit tests, then PR for business logic + unit tests.
bloomingkales wrote 2 hours 53 min ago:
Maybe itâs the changing interest rates or political winds, but I
think the âfat clientâ era JS-heavy frontends is on its way out.
This is just not going to be true. Itâs an AI world and we need to
funnel so much high velocity text and dynamic UIs to provide a high
fidelity experience.
Investing in static server rendered pages is just a surrender, the long
surrender that people desperately seek from the onslaught of
JavaScript.
But it wonât happen, it will either be JS or another language, but
server side pages is the wrong bet.
remram wrote 1 hour 0 min ago:
This comment looks generated by AI. It must be too high-velocity for
me because I don't understand any of it. At least the text was
high-fidelity on my laptop screen.
SrslyJosh wrote 1 hour 13 min ago:
> Itâs an AI world and we need to funnel so much high velocity text
and dynamic UIs to provide a high fidelity experience
Are you on drugs?
thomasfromcdnjs wrote 1 hour 59 min ago:
I can't agree with the quoted sentiment either. Even I attempt to
remove all my bias, most of the tools I use to work (app developer)
are fat javascript clients.
bloomingkales wrote 1 hour 44 min ago:
Yeah. Thereâs been a little bit of a puritanical pursuit back out
of SPA on HN (it might actually be isolated to here honestly,
almost like a local band that plays in the neighborhood), but
itâs an emotional over correction (imho) to the exhausting JS
climate.
Nevertheless, the facts on the ground are the facts on the ground.
kellysutton wrote 2 hours 38 min ago:
I'd encourage you to spend an afternoon kicking the tires on
Turbo/StimulusJS, HTMX, Laravel Livewire, or Phoenix LiveView!
tyre wrote 3 hours 40 min ago:
> Letâs assume that making a JS change costs twice as much time a
Ruby change, which I think is being generous to JS.
Everyone's mileage varies, of course, but this is quite the assumption.
It feels like a lack of familiarity/comfort with the frontend or poor
tooling.
With typescript and a basic UI library like MUI, this really shouldn't
be the case for UI changes. If you're using raw JS and manipulating the
DOM, maybe?
kellysutton wrote 2 hours 41 min ago:
The original post could have been a bit more precise on this point.
Basically, this math assumes something where the server-provided data
changes in concert with the frontend.
If we're using jsonapi, GraphQL, Thrift, or any other protocol that's
not HTML, we need to do the following:
- Make the change on the server to support the new functionality.
Deploy.
- Make the change on the client to adopt the new functionality.
Deploy.
- Remove the old functionality from the server (optional)
Because the client is a separate application, it becomes riskier to
deploy those changes together. I need to think about it more as a
developer.
With server-authored HTML, this separate client + server deploy is
not required.
leptons wrote 2 hours 7 min ago:
>With server-authored HTML, this separate client + server deploy is
not required.
SSR has been a thing in react for a long time.
runako wrote 1 hour 47 min ago:
If the app has a backend, aren't we still talking about modifying
two distinct apps (React + backend app) vs a single one?
Obviously unless the team has committed to React SSR + React
backend (is this common?)
silversmith wrote 1 hour 20 min ago:
Not necessarily. Most of Rails+React apps I have worked on have
had the frontend code live in the same repository, and get
deployed during the same step.
Yes, you have to keep API compatibility in mind when doing
changes, because long-lived sessions might still exist. But has
not been that much of a big deal in my experience.
erikerikson wrote 1 hour 33 min ago:
Not necessarily. We write Typescript for front and back ends,
using statically rendered SolidJs, skipping SSR, and hosting
the corresponding Typescript in Lambdas.
marcus_holmes wrote 3 hours 16 min ago:
I think the author was talking about React specifically.
I've worked in JS, TS, React, and RoR, and yeah I'd say making a
change is probably twice as quick in RoR as in React.
The thing is that Rails is an opinionated framework. If you do things
that the framework is designed to do, then it's very very easy. If
you go off-piste and have to fight the framework to do the thing you
want it to do, it gets very hard very quickly.
React is less opinionated (about most things) so the converse is
true; it is slower to write stuff in, but there's less constraint.
ajmurmann wrote 1 hour 37 min ago:
I feel the comparison is really hard. Rails really is a framework
that solves anything but the business logic for 80% of your app.
React is really a library for rendering components and everything
else is your decision to pick or build from scratch. E.g. Rails has
opinions on how to build forms while React, a supposed frontend
framework, doesn't have anything baked in specific to that. Sure
the community has opinions about it but React doesn't like Rails
does.
mvdtnz wrote 3 hours 18 min ago:
My experience with very highly paid frontend developers is they like
to spend hours and hours (and thousands and thousands of dollars)
building out little libraries and components and frameworks that will
enable other teams to be faster. Except this never eventuates because
things rarely turn out to be reusable along the right axis so a new
component or library or framework is developed to solve the problem.
On top of this UI developer propellor-heads love to spend time (and
money) pontificating on abstract theories about functional
programming and homomorphisms and endofunctors so they can render
some text inside a tag. It's how we wound up with utterly ridiculous
pieces of code like the "hooks" API in React.
zsoltkacsandi wrote 32 min ago:
I have exactly the same experience.
JOnAgain wrote 3 hours 2 min ago:
Canât get promoted pumping out 10 great pages. But a library that
you can claim will enhance the productivity of 100 other engineers?
Now thatâs IMPACT!!
Except youâre at a company where everyone has figured this out so
now you have 4 competing libraries with their own teams which are
all 1/2 done making every engineer less productive cause they all
have bugs and slightly different priorities.
ctkhn wrote 2 hours 46 min ago:
this is exactly the frontend team from a previous role. we were
losing millions a month and had 2 major cuts within 4 months -
and instead of cleaning up or simplifying our bloated frontend,
the teams responsible for it started building new component
libraries for the rest of the org to use on future pages
goosejuice wrote 3 hours 5 min ago:
I also get the feeling that modern frontend is a massive money pit
but this seems to be a leadership problem. I wouldn't go so far as
to blame the IC. There are developers over-engineering in every
ecosystem.
stevage wrote 3 hours 41 min ago:
Never thought about SSR making your code more testable. That sounds
pretty appealing.
Also, does p50 mean median?
SrslyJosh wrote 1 hour 14 min ago:
It's much simpler to not write an entire second application in the
fucking browser, which is what React et al frequently entail.
kellysutton wrote 3 hours 36 min ago:
Yes
abc-1 wrote 3 hours 43 min ago:
I was apprehensive at first, but it seems like it works for them and
they make some interesting points.
kellysutton wrote 3 hours 55 min ago:
A friend mentioned this made the front page. I'll try to answer any
questions on our approach at Scholarly. Thanks for reading!
evanmoran wrote 3 hours 30 min ago:
Thank you for writing this all up. Just curious if you ever
considered switching away from Ruby? I think many people are living
in parallel stacks (TS, Go, Python, Rust) and it would be interesting
to hear how itâs been going more recently in that ecosystem from
your perspective.
As to rendering, Iâll be honest and say that my code has moved more
towards client-side (using ConnectRPC and my framework
ojjs.orgâ-shameless plug :), but I love that you have had success
with a different path. Super interesting, and thanks again!
kellysutton wrote 2 hours 56 min ago:
I don't have a reason for switching away from Ruby at this point in
my career. Things can always change down the line. Maintaining
multiple languages at the same layer sounds like a personal
nightmare to me. I'd rather learn to write PHP and have that be the
only language, than to write Ruby+another language on the
server-side.
We're building our company on Rails because we think it's the best
choice for a young company, since it allows us to respond to
customer feedback more quickly. That's what we're optimizing for
right now!
Swizec wrote 3 hours 48 min ago:
> Letâs assume that making a JS change costs twice as much time a
Ruby change, which I think is being generous to JS
I donât grok this part. Based on my experience with RoR and JS/TS,
making changes in TS-land is much easier and quicker than dealing
with Ruby.
Is this just a preference/experience thing in the end? For you and
your team RoR is faster/easier, so that makes it the better choice.
For a different team JS/TS may be faster/easier, so that makes it the
better choice?
kellysutton wrote 3 hours 36 min ago:
Haven't written much TS, so can't speak to that.
I should have made the distinction between client-side and
server-side JS/TS. Familiarity and expertise will be a main driver
of productivity for a team, regardless of language/framework. For
us, that's RoR.
Client-side JS however has a multiplying property, where we often
need to write more server-side code to accommodate the growth in
client-side code. If the client-side code is providing
undifferentiated value (e.g. authoring HTML), we now have more
pieces in our system to accomplish our goal (author HTML). What's
been surprising to me is that you don't need to author HTML
client-side to have a reactive experience. With Turbo, Stimulus,
and server-rendered HTML, a great experience is possible with fewer
layers.
Swizec wrote 2 hours 57 min ago:
Great answer. Thanks!
I think the power of fat clients comes when you have different
consumers of the same APIs/logic. Like a browser app or two,
maybe backend services, a few task queues, etc. Then having a
clean separation between client code and business logic becomes
super valuable.
In my experience with SPA we got to a point where my team could
go weeks, even months, without having to make changes in server
code. Whole new features that were fully supported by our
existing APIs because they were written as reusable APIs. If
youâre having to write a bunch of Rails to support the growing
client code, you probably didnât need a separate client yet.
But when your codebase gets to that point even Rails is just a
frontend really. So itâs mostly about which tradeoffs you
prefer. Unfortunately I left Rails right around the time Turbo
was becoming a proper thing you could use so I donât have the
best feel for what itâs like.
DIR <- back to front page