Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If Not SPAs, What?

macwright.com

Post reply on HN
Print view View original

171–180 of 456 posts

Re: If Not SPAs, What?

#171

Post by Aeolun »

dfabulich wrote: post #21

IMO, TurboLinks + service workers are the way to go. Not many people know this, but a service worker (previously called "local server") allows you to run a little web server in the user's browser that intercepts requests to your own web site. (There's no open IP port.) The service-worker web server can proxy requests to the remote server, and even build/store entire pages on the client side, enabling offline support.…

I have literally never had a worse experience developing than with serviceworkers.

Accidentally cache your index.js file? You are now stuck with your serviceworker forever (unless you do some chrome voodoo).

The promise is there, but it’s just a gigantic footgun.

Re: If Not SPAs, What?

#172

Post by hnick »

It's interesting to me that in video games we talk less about frameworks than we do engines. Doing a few tutorials, I was shocked at how little code I had to write these days with something like Unity or Godot.

Breakout indie success stories are often lead by artistic types, since it seems harder to teach a typical programmer to draw than to teach an artist enough code to get by. And I think the scene is richer for it.

Is there a good reason the web isn't like this? Engines, rather than frameworks, that have done the hard optimisations and made the best practice decisions for us?

Re: If Not SPAs, What?

#173

Post by lexx »

banashark wrote: post #66
lexx wrote: post #60

I think there is another layer to that conversation. Frameworks become bureaucratic and boring because they are developed by large teams for large teams. Most developers are working on small projects and need more fun and less maintaining huge amount of boilerplate code that recreates the browser. The framework that I feel makes development less ugly is svelte. But still, I really don't like the idea of heavy client…

I went down this route recently. There are a couple of different options depending on your preference: • Write the glue code yourself if you only need svelte on a few pages • Inertiajs if you want to replace your view layer with svelte

I agree with you. I did give a look at Inertiajs just because Laravel was friendly towards it. Looks sweet.

Right now the "glue" I came up with is a silly connection between the server side router and the "Entry" component of Svelte. It works, it's 10 lines of code, it's clean and the website is super fast. But, both Inertia and my solution feel somehow "hackish". Not a proper pattern.

But really, anything to avoid client side routing, state management and auto-magic code splitting.

Re: If Not SPAs, What?

#174

Post by ehnto »

cateye wrote: post #37

I've always felt this problem from the first time I touched Angular. It was just so much more complex and fragile without actually a lot of benefit unless you wanted to make a really interactive async application like Google Docs or Facebook Chat. When SPA's became the norm and even static web pages needed to be build with React, developing became more and more inefficient. I saw whole teams struggling to build simpl…

Everyone looks to the bigger companies for tech trends, not realising that they have none of the problems ultra scale companies are trying to solve.

Re: If Not SPAs, What?

#175

Post by 1ark »

pier25 wrote: post #151

The fundamental problem is not that the SPA pattern is bad, is that it takes a lot of skill and effort to make a proper SPA. Obviously, skill and time are scarce resources and the result is that most SPAs are crap. OTOH all these component based frameworks have definitely brought us a much better way to produce interactive experiences compared to the jQuery days. This is not related to SPAs at all. You can use React/…

Recently I got to work with hybrids.js (webcomponents) which makes the hydrate part nice. Because it is normal markup with whatever data you have on your SSR-pages. It simplified quite a bit.

Re: If Not SPAs, What?

#176

Post by solipsism »

hnick wrote: post #172

It's interesting to me that in video games we talk less about frameworks than we do engines. Doing a few tutorials, I was shocked at how little code I had to write these days with something like Unity or Godot. Breakout indie success stories are often lead by artistic types, since it seems harder to teach a typical programmer to draw than to teach an artist enough code to get by. And I think the scene is richer for i…

How often do you deal with blitting textures into vram when working on your web applications? If not very often, that means you're building on top of a stack of software that includes a rendering engine, equivalent in many ways to Unity or Godot.

Re: If Not SPAs, What?

#177

Post by jay_kyburz »

hnick wrote: post #172

It's interesting to me that in video games we talk less about frameworks than we do engines. Doing a few tutorials, I was shocked at how little code I had to write these days with something like Unity or Godot. Breakout indie success stories are often lead by artistic types, since it seems harder to teach a typical programmer to draw than to teach an artist enough code to get by. And I think the scene is richer for i…

Probably a hard sell in the web would because it would feel like a return to WYSIWYG.

Re: If Not SPAs, What?

#178

Post by Nextgrid »

switz wrote: post #134
cateye wrote: post #37

I've always felt this problem from the first time I touched Angular. It was just so much more complex and fragile without actually a lot of benefit unless you wanted to make a really interactive async application like Google Docs or Facebook Chat. When SPA's became the norm and even static web pages needed to be build with React, developing became more and more inefficient. I saw whole teams struggling to build simpl…

> developing became more and more inefficient Anecdotally I find the opposite to be true. I've been writing frontend code for over a decade, but I've never moved faster and wrote less buggy code than now. Is that because I've become a better developer? Sure, a little bit. But by and large, I don't believe that ultimately is the reason. I think it's the maturity in the technology. My growth as a programmer is hardly l…

> Frontend tooling has never been better than it is today.

What's the library or design pattern to consume a REST API in React or any of the mainstream front-end frameworks? The only thing I'm aware of is Ember Data but Ember is apparently not cool anymore, and I couldn't find a suitable replacement.

I'm asking because in all the projects I've been involved with, consuming the backend API always felt like a mess with lots of reinventing the wheel (poorly) and duplication of code. I can't believe in 2020 there's not some kind of library I can call that will give me my backend resources as JSON and transparently handle all the caching, pagination, error handling (translate error responses to exceptions), etc and people have to do all this by hand when calling something like Axios.

In contrast, Django REST Framework handles all that boilerplate for me and allows me to jump right into writing the business logic. It's insane that ~30 lines of code with DRF (https://www.django-rest-framework.org/#example) gives me a way to expose RESTful endpoints for a database model to the web with authentication, pagination, validation, filtering, etc in a reusable way (these are just Python classes after all) but the modern front-end doesn't have the client equivalent of this.

Re: If Not SPAs, What?

#179

Post by recursivedoubts »

542458 wrote: post #87
recursivedoubts wrote: post #65

Well, we could go back to the original model for the web, using REST & HATEOAS without arguing or even really thinking about it, by building hypertext-based applications. Of course, the hypertext we have, HTML, wasn't completed, and it leaves a lot to be desired. I have tried to fix that with htmx: https://htmx.org

Hey, this is super cool. Thanks for building it! One quick question: How should I be handling server side errors with this? Like, normally I’d check the status code coming from the server and throw up an error modal if it’s an error - what’s the equivalent mechanism here?

htmx triggers a bunch of different events based on various request life cycle events.

For server errors you'd use htmx:responseError:

https://htmx.org/events/#htmx:responseError

You could write some code like so:

   htmx.on("htmx:responseError", function(evt) {
     GrowlNotification.notify({
       title: 'Request Error',
       description: evt.detail.xhr.responseText
     })
   })
And that would show a growl notification in the event of an request error. Or however you wanted to display it.

Re: If Not SPAs, What?

#180

Post by austincheney »

pier25 wrote: post #151

The fundamental problem is not that the SPA pattern is bad, is that it takes a lot of skill and effort to make a proper SPA. Obviously, skill and time are scarce resources and the result is that most SPAs are crap. OTOH all these component based frameworks have definitely brought us a much better way to produce interactive experiences compared to the jQuery days. This is not related to SPAs at all. You can use React/…

No, it doesn’t take that much skill. I think this is the source of the problem.

The stupidity and hostile fear of originality I detect in this these comments is a very real reflection of my professional experience. This, dependence on frameworks and inability to imagine anything beyond the common SPA, really scares the shit out of me knowing I will be coming home from a military deployment soon and returning to the corporate world are scared to write code.

Whenever non programmers ask me what programming is like I tell them it’s full of the most insecure people you can ever meet. People are afraid to do their jobs, need a framework for everything, and always talk about how hard it is (when it isn’t).

Post reply on HN