3 ms·
One thing stood out to me, from reading the post and the HN discussion. I think there's a real distinction to be made between web pages and web applications. HN
by zomglings 6y ago
One thing stood out to me, from reading the post and the HN discussion. I think there's a real distinction to be made between web pages and web applications. HN seems to have a bias against web applications which is probably unfair.
Most web developers today do not set out to build web pages. They start with full-on experiences they would like to bring to users, and the web stack is their tool of choice in doing so. There is nothing wrong with this! And different considerations apply in the development of such applications versus a web page.
Philosophically, SourceHut is about non-browser-based workflows (e.g. using email for merge requests). Since SourceHut users do far less of their SourceHut-related work on the actual website, SourceHut can afford to take a web page approach. GitHub, in contrast, focuses on browser-based workflows. They actually do a pretty great job at it - and this is something that they can do only because they take a web application approach. I like their keyboard shortcuts, for example, but these would be difficult (impossible?) to implement on a simple HTML page.
No single user can say that one approach is right and the other is wrong. All they can do is assert preferences. At the end of the day, traffic does the talking.
But thinking in terms of web pages vs. web applications makes things like this:
> Many companies have written checks with an uncomfortable number of zeroes on them to get the job done.
more understandable.
- Karrot_Kream 6y ago> HN seems to have a bias against web applications which is probably unfair. It may be unfair, but I think part of it is a pushback against the cultural zeitgeist that the web is meant as a platform to deliver content to passive users. If web authors assume that users are out there to just passively consume content, then yes most of the web will just be elaborately designed applications designed to guide the passive user. > All they can do is assert preferences. At the end of the day, traffic does the talking. I think this simplification is part of the problem. Traffic doesn't dictate anything. Just because The Bachelor receives more eyeballs than War and Peace doesn't mean that The Bachelor is a superior product to War and Peace, or conversely that War and Peace is a better product than The Bachelor. Each has its place in our species' cultural milieu. The web has a growing culture of trying to erase media plurality and embrace a single hot, or dominant form of publishing, and I think this specifically leads to the outgrowth of these sorts of big flamewars. Different forms of media can coexist, and traffic isn't the only mark of success.
- zomglings 6y agoYour reply really made me think - you are absolutely correct about traffic not being the end all and be all measure of successful content. Thank you for pulling me out of the echo chamber. :) It isn't just about guiding passive users through content, though. My comment was motivated by a little dilemma that I have been wrestling with: I'm building a search engine and have written the first version as a React app. I've been wondering if we shouldn't switch to a more traditional web page structure. Drew's post made me realize that I want to give my users - not passive - an application experience so it's okay to stick with the current setup.
- Karrot_Kream 6y ago> Drew's post made me realize that I want to give my users - not passive - an application experience so it's okay to stick with the current setup. Yup, and I think that's fine! I love using the web applications that I do use. I think we just need to take a hard look at what should be an application and what shouldn't, especially given the target audience. Having SPAs with infinite scroll to display a blog post really is just unnecessary.
- ratww 6y ago> I like their keyboard shortcuts, for example, but these would be difficult (impossible?) to implement on a simple HTML page. There is a very old (pre-Javascript) attribute called accesskey that allows primitive shortcuts without using JS. [1] Can't really use the same optimal shortcuts as GH, though! As for the webpage vs web app, is it strange that I still consider GitHub having a webpage-based approach? I think they got a lot of functionality, but I don't really see them as being an SPA. [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/accesskey https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
- zomglings 6y agoThank you for teaching me about accesskey, very useful. You are right that GitHub is not an SPA, but they seem to be moving towards becoming a proper web application - probably will happen over the next year or two. The site is quite interactive - e.g. closing issues automatically when a PR is merged to master, GitHub actions triggering on pushed commits and giving developers valuable feedback on their changes. Now that they are pushing GitHub Codespaces, they are a small step from turning the GitHub site into the only place a developer needs to go to write code, test it, and release it.
- ratww 6y agoThat's true! The Actions UI is also very SPA-ish compared to the older parts of the site.