5 ms·

> I like the idea of this. There's so much information on the web, but we still need a way to bring that information to other applications, without being tied t

> I like the idea of this. There's so much information on the web, but we still need a way to bring that information to other applications, without being tied to a particular source. I'm not sure I'm interpreting you correctly here, but I think I'm on the other side of this. The problem is that many modern websites are godawful. I think the story pretty much ends there. If websites were not awful, we wouldn't find ourselves appalled by the idea of just embedding a browser. Modern web browsers feature a 'reader mode' as a countermeasure to that much modern web design is significantly worse than having no web design at all. If you're serious about a 'lightweight' alternative to the lumbering horror-show of the modern web, the way forward is either Gemini [0], or a formalised simple subset of HTML. [1] > That way we can find, say, a recipe or an address on a web page in a reusable way and without needing magical heuristics. I think the find and reusable aspects here are really two very different problems. The reusable part is easy. HTML is already reusable. A standardised simple subset would be even more so. [1] The find part is trickier. Discovering decent content is harder, as there's an arms race of ad-funded spammers trying to out-compete legitimate recipe sites in search-engine rankings. (There's also the possibility of search engines not being motivated to work on delivering good search results. [2]) The idea of having a choice between native GUI applications and web apps, has been with us for some time. Email is probably the best example, we've long had the choice between webmail and native email clients. Beyond webmail, these days even Microsoft Word has a web-based version. There are of course both advantages and disadvantages to web-based applications. [0] https://news.ycombinator.com/item?id=23730408 https://news.ycombinator.com/item?id=23730408 [1] https://news.ycombinator.com/item?id=29291392 https://news.ycombinator.com/item?id=29291392 [2] https://news.ycombinator.com/item?id=29772136 https://news.ycombinator.com/item?id=29772136

Karrot_Kream 5y ago
How do you know someone uses Gemini? They'll tell you the moment they can! Like the vegans of the web...
- antifa 5y ago
  I didn't want to register for a gemini group just to ask this, but I looked at it from a webdev point of view just long enough to notice there was no evidence of any way to implement a "save comment" or "type in search" feature, basically as if gemini was entirely reduced to mostly static websites with no forms of any kind possible. Is that an accurate assessment?
  - Karrot_Kream 5y ago
    > I didn't want to register for a gemini group just to ask this You actually don't need to. Gemini is a client-server architecture just like the web. You can grab a Gemini client, or use some of the web portals out there that make a server-side Gemini request and render the result to the browser. > or "type in search" feature There is a limited form of input allowed, but this input shows up as a query parameter essentially. This is how you can do search or offer some form of interactivity and how the current Gemini search engines/crawlers work. > basically as if gemini was entirely reduced to mostly static websites with no forms of any kind possible Again Gemini does allow limited forms, but it only accepts a single query parameter as input. You can, of course, parse the parameter however you choose, but the general culture is that there's very little interactivity and most everything is a static page.
jka 5y ago
Also entirely possible that I'm misunderstanding both of you, but I think what the parent comment was imagining was something like common schemas (like schema.org[1]?) for content that is currently around the web and encased in the challenging web design you mention. With common (and evolving) formats -- and incentives for publishers to provide their information within those formats -- we could then have much simpler, more streamlined tools to use and remix that data in application-specific ways. [1] - https://schema.org/docs/full.html https://schema.org/docs/full.html
anderspitman 5y ago
> Discovering decent content is harder, as there's an arms race of ad-funded spammers trying to out-compete legitimate recipe sites in search-engine rankings I wonder if we even need the search engines? I think a lot of the things we've come to rely on them for could easily be handled in other ways. Recipes for example. You don't really want the best recipe page for a given dish. You want a good quality recipe site that has a recipe for that dish. Quality of recipe sites ebb and flow as they sell out and incentives change, but generally you would probably only need to be aware of the top 2-3 sites. This is exactly the type of information that is easily stored as "tribal knowledge" on a subreddit, forum sticky, community wiki, or even blasting out to your Facebook friends "hey what's everyone's favorite recipe site?"

Karrot_Kream 5y ago

How do you know someone uses Gemini? They'll tell you the moment they can! Like the vegans of the web...

antifa 5y ago
I didn't want to register for a gemini group just to ask this, but I looked at it from a webdev point of view just long enough to notice there was no evidence of any way to implement a "save comment" or "type in search" feature, basically as if gemini was entirely reduced to mostly static websites with no forms of any kind possible. Is that an accurate assessment?
- Karrot_Kream 5y ago
  > I didn't want to register for a gemini group just to ask this You actually don't need to. Gemini is a client-server architecture just like the web. You can grab a Gemini client, or use some of the web portals out there that make a server-side Gemini request and render the result to the browser. > or "type in search" feature There is a limited form of input allowed, but this input shows up as a query parameter essentially. This is how you can do search or offer some form of interactivity and how the current Gemini search engines/crawlers work. > basically as if gemini was entirely reduced to mostly static websites with no forms of any kind possible Again Gemini does allow limited forms, but it only accepts a single query parameter as input. You can, of course, parse the parameter however you choose, but the general culture is that there's very little interactivity and most everything is a static page.

jka 5y ago

Also entirely possible that I'm misunderstanding both of you, but I think what the parent comment was imagining was something like common schemas (like schema.org[1]?) for content that is currently around the web and encased in the challenging web design you mention. With common (and evolving) formats -- and incentives for publishers to provide their information within those formats -- we could then have much simpler, more streamlined tools to use and remix that data in application-specific ways. [1] - https://schema.org/docs/full.html https://schema.org/docs/full.html

anderspitman 5y ago

> Discovering decent content is harder, as there's an arms race of ad-funded spammers trying to out-compete legitimate recipe sites in search-engine rankings I wonder if we even need the search engines? I think a lot of the things we've come to rely on them for could easily be handled in other ways. Recipes for example. You don't really want the best recipe page for a given dish. You want a good quality recipe site that has a recipe for that dish. Quality of recipe sites ebb and flow as they sell out and incentives change, but generally you would probably only need to be aware of the top 2-3 sites. This is exactly the type of information that is easily stored as "tribal knowledge" on a subreddit, forum sticky, community wiki, or even blasting out to your Facebook friends "hey what's everyone's favorite recipe site?"