Much of this and more was achieved with NextJS. Yes, javascript, but you have absolute control of what you want to render server- or client-side. You don't have to write APIs. And you still have the massive Node or React catalog at your fingertips. I don't think there is a better realisation currently for what they aimed for in this presentation.
Breaking up with JavaScript front ends
81–90 of 433 posts
Re: Breaking up with JavaScript front ends
#82I got very excited at the premise and the first few slides, thinking someone was going to talk about what a secret weapon vanilla JS is for productivity...only to find out they're advocating use of a front end library much larger than react or Vue.
At this point I'm getting a bit tired of backend people claiming that the cure to the frontend mess is a big library that pretends to be html.
Re: Breaking up with JavaScript front ends
#83Seems 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…
To me it looks like the opposite. It’s more batteries included, easier to use and has been around for longer. I like htmx too, but too me it’s only better on the marketing side.
Re: Breaking up with JavaScript front ends
#84[deleted]
Re: Breaking up with JavaScript front ends
#85Warning: if you want to look at the content of this page, say goodbye to your back button.
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
#86Earlier quoted context omitted.
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…
Yes "app-like-ness" when that's appropriate. But a lot of the web isn't that. Yet devs / agencies are using a sledgehammer (e.g., React) when a Phillips head screwdriver is what's need. Users get experiences they don't need (nor want). Site owners gets a maintenance dependency they don't want (nor need).
I think the basic divide is something like "CRUD forms" vs "interactive applications".
I've built basic CRUD forms with ASP.NET MVC. I've built them with Rails. I've built them with React (+ a hundred random libraries). I've also built interactive "apps" in those languages.
Looking back, the amount of "interactivity" that React adds to a CRUD form is NOT worth the added complexity. But! Right now my dayjob is creating an _insanely_ complex app that you could not have done five years ago with Rails (or, like this presentation is about, something like Unpoly).
I think a problem is that React is just more _fun_ to work with than basic server stuff so devs want to work in it. The added complexity is worth it to have more fun. Maybe that's just me, though. I know a lot of people see React as a hammer to hit every nail with, and I was like that for a long time, but I'm starting to come back around to more server-driven use cases for simple sites.
I've been messing with Fresh a lot lately and it's a nice middle ground of defaulting to rendering _most_ stuff on the server, but you can have "islands" of interactivity that get sent to the client as JS. I'm not sure if it will end up gaining traction, but it's pretty nice.
Re: Breaking up with JavaScript front ends
#87Warning: if you want to look at the content of this page, say goodbye to your back button.
Yeah found that out the hard way. Horrible design
Re: Breaking up with JavaScript front ends
#88It's interesting that they appear to plan to use with Rails as a back-end (they mention Rails bindings), as Rails 7 release corresponded with a solution which appears somewhat similar to me, turbo/stimulus. (I want to provide a link to it, but I honestly don't know any great docs for it!) But I haven't used stimulus/turbo myself. I'd be interested in a compare/contrast between Rails' Stimulus/turbo and "Unpoly" cover…
It's worth noting that this presentation is from 2016, so it is over 6 years old now
Re: Breaking up with JavaScript front ends
#89Earlier quoted context omitted.
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.…
I wouldn’t say modern web dev is simpler, I just think it is more decoupled. This helps with training for & staffing the more specialized roles that emerged.
[deleted]
Re: Breaking up with JavaScript front ends
#90Earlier quoted context omitted.
I don’t see the difference. Isn’t backend code code you have to maintain too?
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.”