Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Breaking up with JavaScript front ends

triskweline.de

Post reply on HN
Print view View original

371–380 of 433 posts

Re: Breaking up with JavaScript front ends

#371

Post by aristofun »

0xblinq wrote: post #176
aristofun wrote: post #97

Breaking up with JavaScript frameworks by creating another JavaScript framework, really?

C’mon, put a minimum effort to understand what it’s all about before making useless comments. It is not a framework to organize your own JavaScript (like react, vue, etc). It is a framework so that you don’t have to write JavaScript in the frontend. Of course it is written in JavaScript, because that’s the only thing that can run on the browser.

C׳mon, put a minimum effort to realize, that it was the same kind of original intention behind any js framework - so that you don’t have to write something unnecessary.

This is absurd statement.

It doesn’t mean that the OP framework is bad or that SPA idea is not generally abused etc and doesn’t call for some changes etc.

It’s just a ridiculous and somewhat arrogant way to promote your yet another fancy js thing.

Re: Breaking up with JavaScript front ends

#373

Post by ttfkam »

Throwaway23459 wrote: post #272
t8sr wrote: post #100

Earlier quoted context omitted.

Alternatively, web developers could calm down and just write mostly HTML with some plain javascript where warranted. I've recently done some web development for the first time in 12 years, and I was horrified at all these pointless frameworks that break every usability win web browsers have made in the past 20 years, cost extra bandwidth and have atrocious performance. Like, why? Can web devs really not learn the 4 f…

React and Angular are both blazing fast, and are definitely not pointless. Open create react app, spin up a page with 50000 buttons, compare that to a plain js version, then come back and tell us about the atrocious performance.

Apparently you've never heard of event delegation, which has been around for at least twenty years? (I could swear I was using it on IE6, but I might be misremembering.) At any rate, the plain JS way of handling 50,000+ HTML buttons efficiently is a long-solved problem.

https://javascript.info/event-delegation

Re: Breaking up with JavaScript front ends

#374

Post by afavour »

sph wrote: post #311
afavour wrote: post #271

Earlier quoted context omitted.

> This kinda crap is why the gmail tab uses a GB of memory. It isn’t. Ironically things like memory leaks are why pages use a ton of memory and in my experience everyone coding from scratch results in more of them, not less.

Memory leaks, like bugs, tend to scale linearly with code size. You better believe your 100k line framework has more leaks than my 1000 line script.

Strong disagree. Frameworks are almost always going to be better profiled, better tested and have more eyes than any home crafted code. The number of lines isn’t really that relevant.

Re: Breaking up with JavaScript front ends

#376

Post by jerrygenser »

pagekicker wrote: post #370

Switched to Streamlit, haven't looked back.

From what I've seen streamlit seems to be very focused on data science interactive dashboard type apps. Have you been able to develop much more extensive that power e.g. multiple pages and user interface driven workflows with streamlit?

Re: Breaking up with JavaScript front ends

#377

Post by jerrygenser »

I originally tried using htmx a couple of times because I was a stubborn backend engineer that needed/wanted to build some frontends. The idea of partially swapping subset of DOM made a lot of sense especially as a way to make old school full page reload style more modern.

However, I migrated to react-router 6.4 and it has a very similar concept of embracing web technologies and partials can be defined as an outlet of another page where only the data for the partial and dom for the partial is loaded if sub sub-tree is navigated in. They say they took this idea from emberjs.

I felt the same way as the authors of unpoly and many in this thread looking at most UI frameworks until I stumbled on react router 6.4, and it very much enabled me, a primarily backend engineer, to be productive in the frontend. I highly recommend it to people who are trying htmx but want something that is more IBM "No one ever got fired for picking react"

Re: Breaking up with JavaScript front ends

#378

Post by ttfkam »

wruza wrote: post #347
the_gipsy wrote: post #336

Earlier quoted context omitted.

Nobody cares that you can build up a DOM differently, that's decades old. What matters is: how do changes behave? Your example shows nothing of the complications of lifecycles or state-render loops.

Respectfully, that isn’t decades old. The example above is brief due to forum limitations, so yes, it doesn’t include lifecycles or the whole implementation of a rendering loop. But the context of that comment was using one or more languages for building interactive hierarchies of widgets, and not the topic you brought up, so it didn’t even have to.

Java Swing is decades old (1998?) and does everything you list above. Was even embeddable as a browser applet in all major browsers at the time.

Re: Breaking up with JavaScript front ends

#379

Post by pmarreck »

The cost of maintaining up to date JS (security patched, fixing breaks in functionality afterwards, etc.) seems larger than any boutique site with 1 dev could handle. I’ve been exploring ripping all my JS out and using LiveView instead for this reason.

Re: Breaking up with JavaScript front ends

#380

Post by recursivedoubts »

boxed wrote: post #324
recursivedoubts wrote: post #250

Earlier quoted context omitted.

htmx is focused on hypermedia exchanges in the mode of normal HTML, so client-side stuff is out it does, however, have an extensive event model to hook into, including pre and post request processing: https://htmx.org/reference/#events as well as an extensions API: https://htmx.org/extensions/#defining for client side scripting, I think you are talking about hyperscript, which is definitely more speculative than htmx…

The hooks are very limited unfortunately.

can you be more specific?

there are a large number of events

and the extension mechanism has enabled a diverse number of extensions:

https://htmx.org/extensions/

generally I consider htmx to be on the high side of JS libraries when it comes to events and hooks that can be used

Post reply on HN