> > Specific question: how do you handle the user hitting the "back" button on > their browser? Its very common and a lot of simple approaches don't handle > it well.
This was a problem for me. I force the page to reload instead of using the cache: // https://stackoverflow.com/questions/8788802/prevent-safari-loading-from-cache-when-back-button-is-clicked/13123626#13123626 // https://stackoverflow.com/questions/17432899/javascript-bfcache-pageshow-event-event-persisted-always-set-to-false $(window).bind("pageshow", function(event) { if (event.originalEvent.persisted || (window.performance && (window. performance.navigation.type == 2))) { window.location.reload(); } }); This is for a web application where the page state can be changed by another client at any time though, I assume that usually for user experience the back cache is a good thing to have a website use. I’m not sure for what other cases back causes a problem. ...a potential user coming from another language does not want to go via > the chores of constructing their own router. Or other helpers. Or if they > are used to ORMs, getting back to good old SQL will be a major problem. Why would constructing a custom router be necessary for most use cases? The rules for the default router seem straightforward and useful to me and I haven’t reached out for another implementation. Just with SQL each application requires a third-party driver library already. I’ll advocate using the standard library until there is a specific need for expanded functionality (such as websockets, ORM, permutations of complex routing), in which case my opinion is a specific library should be added and not an entire framework. Matt On Thursday, January 25, 2018 at 3:26:00 PM UTC-6, Florin Pățan wrote: While you are right, you get a lot from the builtin stuff, a potential user > coming from another language does not want to go via the chores of > constructing their own router. Or other helpers. Or if they are used to > ORMs, getting back to good old SQL will be a major problem. And so on and > so forth. > > So the problem is: to whom do you advocate the language to, and what do > they expect to make them happy. > If we keep saying: you don't need a framework, just use the standard > library, then there's a single logical conclusion that we'll have: a lot of > potential users of the language will be driven to alternatives. Drive > enough of them and Go will be just a niche language, that is slowly > replaced by others. Take the Rust community for example, and look at this: > https://rocket.rs When we say: use the standard library then people see > that as an alternative, then what do you think the majority will do? > > I'm not saying that we should be against recommending the standard > library, by all means, it's one of the best assets of the language. > But maybe it's time we should think about saying: Start with this > framework, insert framework name here, and then, as you gain more Go > knowledge, or you are curious about how it's done, look into these > packages, insert collection of packages here, and finally, do not discount > the standard library, as it is very powerful and it can do a lot out of the > box without introducing further dependencies into your code. > > On Thursday, January 25, 2018 at 1:36:29 PM UTC, matthe...@gmail.com > wrote: >> >> Here’s a third vote for the standard library. >> https://golang.org/pkg/net/http/ + https://golang.org/pkg/html/template/ >> are already effectively a web framework. >> >> Matt >> >> On Thursday, January 25, 2018 at 3:15:25 AM UTC-6, Florin Pățan wrote: >>> >>> Big plus one for Buffalo. Out of the frameworks I've seen in Go so far, >>> Buffalo tries its best to stay close to the spirit of Go while delivering >>> all the power to the user in an idiomatic manner. Do give it a try. >> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
