Live data from Hacker News

Breaking up with JavaScript front ends

triskweline.de

91–100 of 433 posts

Re: Breaking up with JavaScript front ends

#91

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.

Re: Breaking up with JavaScript front ends

#92
This is where Angular shines Vs React et al. One "batteries included" library that does everything, no external dependencies unless you go out of your way to add them.

I have (and still do) written SPAs that only use Angular and nothing else. I don't even have NPM installed.

Re: Breaking up with JavaScript front ends

#93
post #90
post #73

Earlier quoted context omitted.

You need a backend anyways. Shifting to a server-side codebase is eliminating duplication, and arguably server languages have better DX so win win.

That might sound convincing to someone who already prefers working on the backend, but you can basically invert your statement to describe a typical serverless setup: “You need a frontend anyways. Shifting to a client-side codebase is eliminating duplication, and arguably browsers have better DX so win win.”

Most backend developers are used to maintaining high quality codebases, however. On the other hand...

Re: Breaking up with JavaScript front ends

#94
post #90
post #73

Earlier quoted context omitted.

You need a backend anyways. Shifting to a server-side codebase is eliminating duplication, and arguably server languages have better DX so win win.

That might sound convincing to someone who already prefers working on the backend, but you can basically invert your statement to describe a typical serverless setup: “You need a frontend anyways. Shifting to a client-side codebase is eliminating duplication, and arguably browsers have better DX so win win.”

You still have to connect with data somewhere which often means running an api server connecting to database. There's certainly options to outsource this to managed services, but "serverless" and distributed systems can often be "more complexity" unnecessarily, without any corresponding productivity or functionality gain.

There's a clear trend back to the server to some degree, so on the margin what I'm saying seems to have some basis in many people's experience, where the sweet spot of many apps does not require the added complexity of SPA's or lack of expressiveness of writing so much app code in javascript, building distributed systems, or having to use Firebase style non-relational database services. Moving much of this to the server reduces some of this complexity often with productivity gains.

Re: Breaking up with JavaScript front ends

#95
post #75

Earlier quoted context omitted.

This is not a website. It's a presentation made with reveal.js framework. This has been made as slides for a talk. It is very much feature that people accidentally don't back out of their presentation while they are doing it.

There’s a browser API for preventing people from leaving pages if they are in a context like that. And unlike this method, it works for the first page, works if you try to close the tab, and works if you try to navigate to a different link. And it doesn’t become entangled with browser navigation.

Well my point is that it's a bit unfair to blame the authors of the presentation for this functionality. Reveal.js is pretty much the standard open-source javascript presentation framework. It's used and developed by slides.com. I don't know why it works like it does. But mind you this is 6 year old presentation with reveal.js from 2015.

Re: Breaking up with JavaScript front ends

#96
post #29

Needs a (2016) in the title. The situation is even worse now.

> The situation is even worse now. Is it really? I have the exact opposite opinion. I mean, I feel like the industry has pretty well standardized on React in Typescript for the front-end on web apps. Sure, there are other technologies that do different things (e.g. Svelte, and someone else mentioned Phoenix LiveView), but for the standard "I'm building a CRUD-focused web app", there are simple choices to make and it'…

React is used a lot, but it is certainly not the standard. Angular is still used extensively, especially in enterprise

Re: Breaking up with JavaScript front ends

#98
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.

Why would the story be different than SPAs? The screenreaders read final html in the browser. It shouldn't matter if comes from server rendered template OR javascript template rendered on the client.

Seems like it depends on how you code the html/templates not how they are rendered?

Re: Breaking up with JavaScript front ends

#100
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 functions that make up the websockets API? Do they really need a special framework named after a coffee bean?

This kinda crap is why the gmail tab uses a GB of memory.

Post reply on HN