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
Breaking up with JavaScript front ends
91–100 of 433 posts
Re: Breaking up with JavaScript front ends
#92I 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
#93Earlier 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.”
Re: Breaking up with JavaScript front ends
#94Earlier 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.”
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
#95Earlier 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.
Re: Breaking up with JavaScript front ends
#96Needs 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'…
Re: Breaking up with JavaScript front ends
#97Re: Breaking up with JavaScript front ends
#98What'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.
Seems like it depends on how you code the html/templates not how they are rendered?
Re: Breaking up with JavaScript front ends
#99And the solution was to turn their website into a powerpoint presentation?
Re: Breaking up with JavaScript front ends
#100Seems 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…
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.