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

101–110 of 433 posts

Re: Breaking up with JavaScript front ends

#101

Post by __jem »

_gabe_ wrote: post #27
whatever1 wrote: post #17

Earlier quoted context omitted.

SPAs solved a labor problem I think. It was the reason that front end development grew so fast. It is much faster to train people on a combo js+css framework rather than training someone on backend languages, databases, queues, authentication, scaling + html & css for server side rendering.

We use SPAs and a pretty strict typescript/react stack. And I still have to know: Cloud Tech (AWS) which also includes, lambdas, Iam management, dynamoDB, cdk or serverless, API gateway, S3, secret managers etc. Add to that list the technologies that often get thrown in for extra monitoring testing etc. Jest or mocha/Chai for unit tests. Dynatrace for monitoring. Kibana or something for logs. Some tool for analytics.…

You may work at a company that requires fullstack expertise, but there are plenty of other companies where frontend developers are fully insulated from all those cloud technologies. I'm not sure what your point is here tbh.

Re: Breaking up with JavaScript front ends

#102

Post by satvikpendem »

Looks very similar to what NextJS is doing, especially with their app directory API [0], ie have everything on the server with React Server Components but then stream in client-side JS as necessary. It's basically the "sweet spot" that TFA talks about.

[0] https://beta.nextjs.org/docs/routing/fundamentals

Re: Breaking up with JavaScript front ends

#103

Post by triskweline »

simonw wrote: post #43

What's the accessibility story for Unpoly? I'm always interested in ways of building partial page fetches, dropdown menus etc in a way that is thoroughly tested to work well with common screenreaders. I'd love to see a frontend framework that includes detailed documentation (and ideally video demos) demonstrating how effective their ARIA screenreader stuff is.

Unpoly lead dev here

Unpoly takes special care to always move the focus to the next relevant element in an interaction. E.g. when a link updates a fragment, the focus is moved to that fragment. Or when an overlay is closed, focus is returned to the link that originally opened that overlay.

More details can be found here: http://triskweline.de/unpoly2-slides/#78

Feel free to install a screen reader and play with the demo app (https://demo.unpoly.com/).

Re: Breaking up with JavaScript front ends

#104

Post by t8sr »

qrohlf wrote: post #19
ramesh31 wrote: post #16

Earlier quoted context omitted.

>I'm actually very intrigued by the whole "let's take a step back and move a lot of our logic back to the server" approach to modern dev, What's old is new again. There's an entire generation of developers now who have no concept of the old world. They started with React/Angular/Vue and have no idea that SSR was the standard default for decades. And now it's a "new idea" that is held up against JS development with no…

I both agree and disagree with this take. I started out hand-coding static html pages, graduated to Drupal and Wordpress php stuff circa 2009 (glad that's over!), then worked on a largely server-rendered Rails SAAS in the APM space that I guarantee you've interacted with if you've been in the web game for more than a couple years. These days, I may sling React for my 9-5 but a lot of my personal projects and internal…

> However, it's also true that the baseline expectation for web experiences is a lot higher in 2022 than it was in 2009 in terms of the level of responsiveness, interactivity, and overall "app-like-ness", to the point where I think that even with the massive improvements in bandwidth, latency, and web protocols...

What? The exact opposite is true: the average web app (including ones like gmail) is far less responsive, slower and heavier than it was 10 years ago. On my M1 Pro, gmail renders at about 20 fps and takes 2-3 seconds to load on gigabit fiber. The web has never been shittier than it is today.

Re: Breaking up with JavaScript front ends

#106

Post by waboremo »

t8sr wrote: post #100
qrohlf wrote: post #11

Seems like a half-baked agency-built version of htmx[1], no? I'm actually very intrigued by the whole "let's take a step back and move a lot of our logic back to the server" approach to modern dev, but IMO when you need more than statically rendered pages, it should look a lot more like htmx or Phoenix LiveView (if you're using a framework) or something ultra-minimal like Slimvoice[2] if you want to go the bespoke ro…

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…

Tools like htmx aren't the reason the gmail tab uses a GB of memory. You'll find the majority of cases where pages are using way more resources than it should, are due to reasons forced on web developers, like a billion different trackers and several different ad networks, and workarounds to ad blocking to sell more subscriptions, etc.

This is what is so shocking to me when HN spends such an absurd amount of time rallying around this idea that frameworks are the reason sites are bad. Mind you, I do think a lot of them are misused, but 99.9999999% of poor websites aren't because of the framework chosen.

Re: Breaking up with JavaScript front ends

#107

Post by olingern »

Like others have mentioned, this seems to be from ~2016. The lack of HTTPS on the provided link ages this some for me, but the use of coffeescript really dates this[1]. I even thought coffeescript had been deprecated, but it does seem that the project is being kept alive[2] which is really cool.

Perhaps, what is most interesting is that it took nearly 4-5 years for the front-end community to collectively come to the conclusion that SPAs are not _always_the answer. I don't think the zeal for SPAs came from a bad place either. I can remember how poorly ASP.NET and other frameworks of the 2008-2012 era packaged an overcomplicated way to pass data to view layers. There's lots of curmudgeon-ining from non-frontend folks but, in my opinion, the lack of performance and ergonomics with existing frameworks, combined with the newness of Node.js is what brought about the explosion of tooling and frameworks.

There is a place for SPAs, though. VS Code, Spotify, and other apps that need a desktop / browser experience to feel like a mobile app are great candidates. Twitter, for example, shouldn't be a SPA or SPA-like application. I find that it frequently over-caches content and will randomly refresh my feed at times while I'm browsing. It feels as if a simple web page that needs to deliver more JSON responses as I scroll is trying to do too much.

1 - https://github.com/unpoly/unpoly

2 - https://coffeescript.org/#changelog

Re: Breaking up with JavaScript front ends

#108

Post by omnimus »

oblak wrote: post #91
synergy20 wrote: post #79

I still think separating frontend from backend makes life easier even though frontend has been chaotic for a decade, and it shows no sign to slow down

Depends on what you're doing. There is great value in SSR but how does one even make anything dynamic/interactive without JS? You can't, so you start adding pure non-spa tainted js. Then you add features until your amazing purist solution is an unworkable mess stuck in the mid 2010s.

This is just problem of structure. I am not convinced that there is particularly higher chance to end up with "unworkable mess" with SSR compared SPAs (of course most projects end up being a mess).

If you look at the hottest trend of the "island architecture". New frameworks like Astro (https://astro.build/) and Fresh (https://fresh.deno.dev/). They are basically what are you describing. All SSR but with dynamic parts. Seems like these "islands" by their nature are less entangled than full SPA.

Re: Breaking up with JavaScript front ends

#109

Post by satvikpendem »

awesomegoat_com wrote: post #57
artursapek wrote: post #46

You should break up with web based front ends and write them in Rust. :-) https://iced.rs

That's the correct answer! Btw, client can run rust in WASM, so no reason to keep javascript in there either!

Soon Flutter will have WASM support too, so it'll be a great time. I've been looking into stuff like Iced, Yew, Tauri etc but the multiple client situation for cross platform isn't too great, unlike with Flutter.

Re: Breaking up with JavaScript front ends

#110

Post by t8sr »

strife25 wrote: post #56
whatever1 wrote: post #17

Earlier quoted context omitted.

SPAs solved a labor problem I think. It was the reason that front end development grew so fast. It is much faster to train people on a combo js+css framework rather than training someone on backend languages, databases, queues, authentication, scaling + html & css for server side rendering.

Labor wasn't the issue, it was UX. Users wanted responsive UIs and Gmail showed the power of AJAX in the browser. In the mid-2000s, server power, network latency, and maintaining state were the challenges. The UX was more powerful when the client tracked state, only requested the data it needed, etc. Things have flipped. SPAs became bloated as abstractions were introduced. Network latency and server power is not an i…

AJAX in early Gmail was a massive improvement. It was mostly hand-coded javascript in a relatively thin page and it was the sweep spot. Today's version of gmail is the most bloated pile of spaghetti framework code imaginable and is far less responsive and usable than the plain HTML version.
Post reply on HN