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

Data fetching on the web still sucks

performancejs.com

Post reply on HN
Print view View original

91–98 of 98 posts

Re: Data fetching on the web still sucks

#91

Post by eyelidlessness »

mewpmewp2 wrote: post #80
eyelidlessness wrote: post #76

Earlier quoted context omitted.

> instead of REST Why? REST doesn't have anything to say about this. You can design your application however you prefer, and publish input and output specs however you prefer, without tailoring your application to the HTTP layer.

Instead of having to implement REST apis is what I mean. It could work with REST underneath or REST being auto generated based off your function names, but you shouldn't have to deal with that. And REST in general would probably not be optimal to transfer the data here.

I’m not sure what you think REST is suboptimal for here, the function you described maps trivially to it.

    GET /tasks?whatever=filters
I agree the part that wires up the HTTP behavior should be minimal and mostly uninvolved with your application logic. (I’m actually working on such a beast!).

Re: Data fetching on the web still sucks

#92

Post by austincheney »

richeyryan wrote: post #90
austincheney wrote: post #85

Earlier quoted context omitted.

State management, for anybody half competent, is stupid easy and not tied to the UI. State management is a data storage/retrieval problem only. Once the UI has the state information it needs you can populate it for the user however you want in many different ways. State management is also proclaimed as something it isn’t because web UI is full of incompetent expert beginners who can’t write two lines of original code…

I'm curious about your approach to making UIs. Are there any libraries you do use? Do you use anything to render your view or do you construct the nodes and insert them into the DOM directly? Is your centrally available object an instance of a class or is it a plain JavaScript object? Does it manage the state for all your UI or is it segmented in some way? How do you drive changes to your UI? Is there an imperative p…

I use the ws library for web sockets.

The state object is just a regular JavaScript object. I prefer to avoid classes as they increase complexity for almost no substantive benefit.

Changes to the UI are handled as events whether those events are from user interactions, HTTP responses, or web socket data events.

I update the DOM using old school DOM methods and some custom DOM methods I have written to do things the standards do not provide.

This stuff that people cry tears of blood over is easy and very basic. I really think the bane of evil is addEventListener allowing multiple handlers for the same events which allows laziness and super increased complexity.

What’s more challenging is writing test automation that executes in the browser and coordinates between browsers of different computers.

Re: Data fetching on the web still sucks

#93

Post by richeyryan »

austincheney wrote: post #92
richeyryan wrote: post #90

Earlier quoted context omitted.

I'm curious about your approach to making UIs. Are there any libraries you do use? Do you use anything to render your view or do you construct the nodes and insert them into the DOM directly? Is your centrally available object an instance of a class or is it a plain JavaScript object? Does it manage the state for all your UI or is it segmented in some way? How do you drive changes to your UI? Is there an imperative p…

I use the ws library for web sockets. The state object is just a regular JavaScript object. I prefer to avoid classes as they increase complexity for almost no substantive benefit. Changes to the UI are handled as events whether those events are from user interactions, HTTP responses, or web socket data events. I update the DOM using old school DOM methods and some custom DOM methods I have written to do things the s…

Would the stuff you have on Github be a fair representation of your ideal way of writing a web UI?

Re: Data fetching on the web still sucks

#94

Post by austincheney »

richeyryan wrote: post #93
austincheney wrote: post #92

Earlier quoted context omitted.

I use the ws library for web sockets. The state object is just a regular JavaScript object. I prefer to avoid classes as they increase complexity for almost no substantive benefit. Changes to the UI are handled as events whether those events are from user interactions, HTTP responses, or web socket data events. I update the DOM using old school DOM methods and some custom DOM methods I have written to do things the s…

Would the stuff you have on Github be a fair representation of your ideal way of writing a web UI?

Try this: https://github.com/prettydiff/share-file-systems/tree/tests

It is a complete GUI with full state management and the browser part of the application is very tiny.

Re: Data fetching on the web still sucks

#95

Post by richeyryan »

austincheney wrote: post #94
richeyryan wrote: post #93

Earlier quoted context omitted.

Would the stuff you have on Github be a fair representation of your ideal way of writing a web UI?

Try this: https://github.com/prettydiff/share-file-systems/tree/tests It is a complete GUI with full state management and the browser part of the application is very tiny.

I had a look through that alright. Do you code in that style in work?

Re: Data fetching on the web still sucks

#96

Post by austincheney »

richeyryan wrote: post #95
austincheney wrote: post #94

Earlier quoted context omitted.

Try this: https://github.com/prettydiff/share-file-systems/tree/tests It is a complete GUI with full state management and the browser part of the application is very tiny.

I had a look through that alright. Do you code in that style in work?

I have been away from my primary employer for about a year and they are HUGE with many different teams that do many different things in many different ways. I just try to gel to the team and not be disruptive.

Re: Data fetching on the web still sucks

#97

Post by mewpmewp2 »

eyelidlessness wrote: post #91
mewpmewp2 wrote: post #80

Earlier quoted context omitted.

Instead of having to implement REST apis is what I mean. It could work with REST underneath or REST being auto generated based off your function names, but you shouldn't have to deal with that. And REST in general would probably not be optimal to transfer the data here.

I’m not sure what you think REST is suboptimal for here, the function you described maps trivially to it. GET /tasks?whatever=filters I agree the part that wires up the HTTP behavior should be minimal and mostly uninvolved with your application logic. (I’m actually working on such a beast!).

Yeah, I'm saying that you shouldn't have to think of such things like URL mapping. What if now all of sudden you want to post json as a filter? You will have to start thinking of new arbitrary ways to handle this query etc. You have to both parse this new deep nested filter you thought of in backend and also you have to stringify it in the frontend. You add so much extra overhead to try to convert the query into some form of string URI that would adhere to URL rules.

Let's say you now want to add a filter for frontend where you can choose multiple dynamic fields and their conditions can be either greater than, equal, or IN some values, I think you get the gist.

You then will have to do it something like that tasks?status=in:todo,progress

Or status=todo&status=done But then you suddenly need greaterThan query. Are you going to do tasks?priority=gt:5 for example?

Or things like that. And you have to worry if this even adheres to URL standards. Things eventually get so messy. And you are very constrained in everything you do.

And how do you typecheck all of that? Also all of this is just error prune, you have to write documentation for it and every REST api is a little bit different, people often mess up when naming the urls etc.

Re: Data fetching on the web still sucks

#98

Post by eyelidlessness »

mewpmewp2 wrote: post #97
eyelidlessness wrote: post #91

Earlier quoted context omitted.

I’m not sure what you think REST is suboptimal for here, the function you described maps trivially to it. GET /tasks?whatever=filters I agree the part that wires up the HTTP behavior should be minimal and mostly uninvolved with your application logic. (I’m actually working on such a beast!).

Yeah, I'm saying that you shouldn't have to think of such things like URL mapping. What if now all of sudden you want to post json as a filter? You will have to start thinking of new arbitrary ways to handle this query etc. You have to both parse this new deep nested filter you thought of in backend and also you have to stringify it in the frontend. You add so much extra overhead to try to convert the query into some…

> Yeah, I'm saying that you shouldn't have to think of such things like URL mapping. What if now all of sudden you want to post json as a filter? You will have to start thinking of new arbitrary ways to handle this query etc. You have to both parse this new deep nested filter you thought of in backend and also you have to stringify it in the frontend. You add so much extra overhead to try to convert the query into some form of string URI that would adhere to URL rules.

I’m not sure I even follow what you’re proposing. That URLs are insufficient for nested structural queries or that you want URL queries and POSTed JSON queries (which is not even REST) at the same time?

If it’s the former, this isn’t something a client or server should need to worry about. Server tools should make defining the API simple in the native language, and generate documentation which can provide client SDKs (again I’m building such a tool).

> Let's say you now want to add a filter for frontend where you can choose multiple dynamic fields and their conditions can be either greater than, equal, or IN some values, I think you get the gist. [...] status=in:todo,progress [...] status=todo&status=done

The most common way this is handled is either your second syntax or status[]=todo&status[]=done (or even with explicit indexes) to make clear it’s multiple values. AFAIK most major URL (de)serializers handle this automatically with no developer effort.

> priority=gt:5

Why not priority=>5? Again a library can trivially handle simple expressions like this, you don’t have to.

> And how do you typecheck all of that?

This is something the library should handle too. And it’s something I know about because I’ve built it (and again I’m working on one I can make open source). For a hint of how this might look and some prior art, check out io-ts.

> Also all of this is just error prune, you have to write documentation for it and every REST api is a little bit different, people often mess up when naming the urls etc

I bet you can already predict it, but the library should take care of this and I’m building it.

None of this should be so messy or so much work for people developing services. You got that right! But that doesn’t mean REST is bad, it means the tools for building and consuming REST services aren’t very mature. But they certainly can be.

Post reply on HN