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

How to store your app's entire state in the url

scottantipa.com

Post reply on HN
Print view View original

311–320 of 416 posts

Re: How to store your app's entire state in the url

#311

Post by andreareina »

bboygravity wrote: post #293
reaperducer wrote: post #279

Earlier quoted context omitted.

we used to joke about LISP source code contains mostly brackets. There was a programming language in the 1970's called SAM76 that didn't care how many closing parentheses you had, as long as it was more than the number of opening parentheses. So, something like this was perfectly valid: a(1+r(em(2)))))))))))))))))))

That's genious IMO. Making sure the amount of opening and closing parantheses is equal is annoying and unnecesary. It screams "trust me all good with the closing parantheses".

paredit and rainbow parens makes it a non-issue for me.

Re: How to store your app's entire state in the url

#312

Post by paledot »

bboygravity wrote: post #293
reaperducer wrote: post #279

Earlier quoted context omitted.

we used to joke about LISP source code contains mostly brackets. There was a programming language in the 1970's called SAM76 that didn't care how many closing parentheses you had, as long as it was more than the number of opening parentheses. So, something like this was perfectly valid: a(1+r(em(2)))))))))))))))))))

That's genious IMO. Making sure the amount of opening and closing parantheses is equal is annoying and unnecesary. It screams "trust me all good with the closing parantheses".

I disagree. I would say when I get an unbalanced paren compiler error, it's more common for the omission to not be at the end of the line. Having the compiler silently swallow the error would lead to serious bugs very quickly.

Re: How to store your app's entire state in the url

#313

Post by escot »

actinium226 wrote: post #246

This is really cool, both the state-in-url and the app itself. Just wondering, how long did it take you to put the app together?

I've been working on the app for over a year. The state-in-url thing was a pretty small portion of time, although I've fixed/updated it several times in that year to make it better. Thanks for the feedback. Did you make a flowchart?

Re: How to store your app's entire state in the url

#314

Post by escot »

builwithlogic wrote: post #194

This is fine for f its public information and if thats fine then why not just add a param with a url encoded json string. Would this make the url shorter or longer? I think shorter. So why base64encode? Just wondering never created an entire app around this idea

The encoding gives you cleaner urls that are restricted to the characters that base64 outputs, not necessarily shorter. The compression is to make it shorter.

Re: How to store your app's entire state in the url

#317

Post by firstbabylonian »

numair wrote: post #271
threeseed wrote: post #180

This technique goes back to the late 90s where Apple WebObjects (owned by NeXT at the time) pioneered this approach in their web framework. https://en.wikipedia.org/wiki/WebObjects Was quite revolutionary at the time and it also included the first (or one of the very earliest at least) SQL ORMs.

You’re the first and only person to point out this fact, which shows how depressingly little history is studied by people who work in this field. It’s a shame it’s become about getting to The Money as quickly as possible…

How do we go about passing this kind of historic knowledge between generations of engineers? In my observation, most newcomers to the industry are trained either academically or through self-guided practical learning, i.e. by hacking and reading tutorials. Neither method exposes them to such 'contemporary history' of innovation within the field.

Re: How to store your app's entire state in the url

#318

Post by tonmoy »

bboygravity wrote: post #293
reaperducer wrote: post #279

Earlier quoted context omitted.

we used to joke about LISP source code contains mostly brackets. There was a programming language in the 1970's called SAM76 that didn't care how many closing parentheses you had, as long as it was more than the number of opening parentheses. So, something like this was perfectly valid: a(1+r(em(2)))))))))))))))))))

That's genious IMO. Making sure the amount of opening and closing parantheses is equal is annoying and unnecesary. It screams "trust me all good with the closing parantheses".

What if I wanted to copy that expression and use is as part of a different expression?

Re: How to store your app's entire state in the url

#320

Post by tempestn »

b112 wrote: post #272
munk-a wrote: post #157

Earlier quoted context omitted.

Just because a thing is prevalent doesn't mean it's good. I have a hard time believing all those parameters are completely necessary for the amount of data being displayed. Often times it feels like people just base64encode(page.state) and call it a day. I think it's advantageous to keep the complexity and specificity of information in URLs to a minimum outside of what's needed to retrieve the data set as it can make…

I can say that many, many times, I have zoomed in, picked date ranges, added options, then pasted the yahoo finance url to others... and they have all those same configs passed. It's awesome and incredibly handy. Yahoo is on the ball here.

Agreed. However they could still simplify the urls a ton by including only non-default parameters, and still achieve the same thing.
Post reply on HN