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

111–120 of 433 posts

Re: Breaking up with JavaScript front ends

#111

Post by Waterluvian »

omnimus wrote: post #95
Waterluvian wrote: post #85

Earlier quoted context omitted.

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.

Who blamed the authors and what did they blame them for?

Re: Breaking up with JavaScript front ends

#112

Post by triskweline »

Erikun wrote: post #76

Am I missing something? They say to "Start classic" or "Start enhanced" on the first page of the demo app but neither is there for me.

Author here. The link is a 6 years old presentation. The demo app has since been rewritten.

The old demo app focused on the downsides of classic multi-page apps (MPAs), i.e. the reason the world moved to SPAs all these years ago. In an MPA clicking a link loses all transient state, like focus, scroll positions and unsaved form state. This can all be solved with updating fragments instead of full pages, while still keeping rendering logic on the server.

Re: Breaking up with JavaScript front ends

#113

Post by nicoburns »

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…

Gmail is just poorly written. The old version of Gmail was still an SPA, and it was perfectly quick.

Re: Breaking up with JavaScript front ends

#114

Post by spideymans »

grishka wrote: post #77
jokoon wrote: post #45

Why can't anybody talk about the fact that HTML was not designed for being dynamic? Isn't there any format that is a real alternative to HTML, which is truly interactive, lighter than the DOM, use text as a mediu, is multi usage and platform agnostic, can use whatever scripting language, and be easily rendered? It's not another new format, it's just that a new format is needed to make things simpler. I have zero pati…

Whenever I build something on the web, I can't help but feel like I'm dealing with a word processor. A very advanced one, but nevertheless still a word processor at its heart. Coming from native apps, I despise the idea of text just being out there without a TextView or something. I also miss Flash.

That’s exactly what it feels like. A word processor distorted into an application development platform. With nearly 30 years of technical debt as well.

This is becoming untenable. The web has only gotten more and more difficult for novice users and developers alike to publish onto. That spells doom for the web in the long run.

I wish we had a clear path out of this trap.

Re: Breaking up with JavaScript front ends

#115

Post by dougdonohoe »

Sort of sounds like Apache Wicket (https://wicket.apache.org/). I used it for a few projects in the mid-late 2000s. I really liked it being server side and the concept of having object-oriented HTML (code paired with HTML snippets). I haven't had a need to use it since 2014, so haven't kept up with the project.

Re: Breaking up with JavaScript front ends

#116

Post by dmix »

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…

The way it componentized the different ‘cards’ or fragements with URL-style lego blocks seems to be the primary novel feature that’s layered on top of HTMLX.

This is already the direction that Remix and Deno’s Fresh framework seem to be taking, at least spiritually. Isolated server-rendered-first approach and only bare minimum JS loaded for fragments/islands that need to be interactive beyond what can be loaded on pageload.

The html attributes vs JSX style templates is really a matter of taste IMO. Although I haven’t used htmlx I get the feeling it would be limiting for more complex cases and involve a lot of hackery or pigeonholing complexity better served by straight up Typscript.

Re: Breaking up with JavaScript front ends

#117

Post by kyleyeats »

dajonker wrote: post #72
kyleyeats wrote: post #58

This is so overdue. I'm ecstatic to see this finally happening. The frontend framework bloat trend honestly went on ten years too long. It was like the thin client and thick client debate turned into the thick client and thicker client debate. People will roll a gigantic create-react-app mess for the tiniest of frontend projects. Yes, it's an instant codebase! But that's all code you have to maintain. Stuff like hotw…

The project is originally from 2014 and the presentation seems to be from 2016.

Hence the 'finally'!

Re: Breaking up with JavaScript front ends

#118

Post by neoberg »

nicoburns wrote: post #113
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…

Gmail is just poorly written. The old version of Gmail was still an SPA, and it was perfectly quick.

As a side note; iirc the old version of Gmail was the first big scale example of SPAs.

Re: Breaking up with JavaScript front ends

#119

Post by bottlepalm »

poisonborz wrote: post #81

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.

Yep started a new project after a month of getting up to date with all frameworks old and new.. Next.js really is the best option right now it seems.

Re: Breaking up with JavaScript front ends

#120

Post by ostenning »

The biggest problem facing the front-end space today isn't so much of complexity of a particular library, rendering technique, or view/model architecture, but rather lots of bad ideas glued together, creating nightmare scenarios for companies trying to maintain products.

A micro dependency system with never ending breaking changes to glue different tools and libraries together - bad idea.

Using un-opinionated "libraries" that don't scale well, but at scale - bad idea.

Technology organizations trying to stay relevant by simply adopting every next hyped fad out there, rather than stepping back to get a bigger picture of what the front-end space actually needs - bad idea.

The list goes on, for quite a long time.

And all of these issues are further exacerbated by an army of junior developers entering the front-end development space, along with recruiters subscribing to buzzwords to hire them.

Post reply on HN