Hacker News Reader

Comment by viach | Hacker News Reader

They violently break all the recent frontend best practices. Where is the React or Vie, SPA architecture, tons of JS?

There should be a federal law prohibiting making fast and simple UIs so that nobody will have concerns that the UI frameworks war leads us to great future.

View on HN

To be fair, not having any of those technologies is just a side effect of deciding to make a dead simple, spartan UI (which isn't a bad thing).

You can get away with very fast, very maintainable front-end code that doesn't need any special frameworks when you say no to modern tastes and features. More websites should really consider doing so.

One of the things that breaks my heart just a little is visiting these sites that load in 30ms and thinking that the Internet of 2019 could be largely like this and how amazing that would feel. Sure, there's lots of complex features we cherish having online, but those could all be hidden behind the main pages that are dead simple. Makes me think about how google.com is the gateway to a massive conglomerate of capability, web apps, features, etc. but the main page itself loads almost instantly.

And it would kill them to write a decent CSS file?

> To be fair, not having any of those technologies is just a side effect of deciding to make a dead simple, spartan UI (which isn't a bad thing).

That's also why google.com was originally so simple, in stark contrast to their competitors of the day.

I love the design and wish a sufficiently large part of the web looked like this... Incidentally, it's a bit like HN.

Their page was done in 114ms.

Where are the PBs of javascript, the YBs of uncompressed images in 128x320 res?

Clearly they've messed up their CDN and we're missing content.

All that really matters is the entry point size in modern application. I built an admin console for our company in react and it's downloaded and rendered in 220ms. People can make performant SPA's they just choose not to.

> for our company

Is that in a single location? If so, then it's not really impressive. A good website loads fast even when the client is on the other side of the globe.

It goes out to all the cloudfront edge locations so that generally isn't an issue. That being said anything under 300ms is not going to be very noticeable to most people.

Contemporary fancysites might pull up a skeleton in that time, but it'll (often) take multiple seconds for every div to be populated and third-party request to return, juggling the page the whole time.

"Initial request to clickability" is definitely longer than it used to be.

Same, but users think it's ugly and doesn't look "right" or "modern" :/

Which users?

The ones that usually flock to platforms. Course then you have classic reddit and 4chan which had pretty simple designs.

I changed back to old Reddit recently, and hell yeah the site is a lot more usable. The new version often had severe lag when loading comments, but I don’t have this anymore.

Its an unecessary single page abomination. Reddit will always be popular it doesnt need a new design. The best part was that different communities could style their subs.

I also remember when you could register without an email.

Lesson learnt: don't listen to all users, have confidence in some of your decisions...

Haha who do you think makes the final call? Executives (i.e. users) or the IT Department?

There’s not even any analytics or trackers. The shame!

And no non-standard fonts on some random CDN.

My eyes are bleeding

Perhaps one could use greasemonkey to inject Google analytics into arbitrary sites. (And load some font, and perhaps have a 20 second timeout somewhere.)

Reverse-reader view! Isn't there a bookmarklet that Geocities-ifies pages somewhere, same idea.

Don't forget Facebook like buttons, those really need to be front and center on every page.

No worries the snakeoil antivirus suites already does that for you ;-)

These comments put me in mind of https://motherfuckingwebsite.com/ and http://bettermotherfuckingwebsite.com/ https://thebestmotherfucking.website/ https://perfectmotherfuckingwebsite.com/

OMG! A web server serving raw HTML! The horror!

Excuse-me but you're supposed to call that Server-Side Rendering now.

My bad.

The interface does not seem fast and simple to me, it's more like primitive and unfinished. Using minimalistic SPA library, like, for example, Preact, adding some feedback for stuff like form validating and data loading would make ux more smooth. I dont want to say that SPAs are best for everybody, but I can't agree that they are always evil.

Monthly operational costs: $783

Maybe there is a relation?

Are you going to say there is not even a distributed no-SQL cluster behind this? Well, I can understand the UI part, but there are limits...

Local config for static stuff and postgres yes-SQL.

I assume it doesn't scale extremely easily but seems to work good enough for now.

YesSQL. Perfect. I'm going to steal that.

YesSQL scales just fine to enterprises like VCS repo hosting. All you have to do is shard correctly (along the lines where you least need the power of SQL, preferably).

Where did you get that from?

Not sure about that figure but there's https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3CBVRVZEWYB30Q..... Looks like their monthly expenses were around $1,200 going in to Q2.

And that's for an offering including a CI build farm. Not just a website.

I just took 640+129/3

Anyway, few hundred dollars added or subtracted doesn't really change the point. This is a fairly cheap operation given what it provides.

I guess this boils down to the classic: No approach is universally better.

You can write a client-side application and distribute it through some CDN (like Netlify) and have no administration duties or server cost. However, your app will end up not working without JS (and your tech stack could possibly be a mess, depending on your choices). Or you can generate pages on the server which requires you to have, well, a server.

Both approaches have benefits and drawbacks.

Are you calling this high or low, and are you snarking or praising?

We're in way too deep here.

I'm sorry, sarcasm is not the best way to communicate an important point here at Hacker News. I appreciate the attempt at humor, but, it's not funny.

Don't be so bloodless. :^)

HN is often accused of being humorless but it's not true. The community simply has higher standards. Deadpan is your baseline, build from there.

Before people downvote Clarkevans, please consider that this itself might be sarcasm and this is some new form of meta humor.

The downvotes are sarcastic as well.

The downvotes on this sadden me greatly.

Don't worry, they're sarcastic downvotes. ;)

What a healthy dose of sarcasm on top of a healthy dose of gui layer.

Insightful and hilarious sarcasm delivering a unique perspective!

You know, libertarians often watch train wrecks and wonder how people can so clearly report problems and commiserate but the obvious solutions never seem to come up.

Refugees... from a third party service... because things changed since they began there

Some other third party service welcomes them, but has bad front end...

SOLUTION:

1. Mercurial and Git are decentralized! They have been designed to be so. Make your back end decentralized also. Why rely on a centralized site?

2. We used to run front-end programs on our computers! What a concept. We thought desktop computers were far better than mainframes and “fat” clients were far better than “thin” ones. Now we are all back to mainframes.

3. End to end encryption! I mean wow half of all humanity has their accounts in an epic database of 3-4 billion people from many breaches. All their private information is now out there. And you trust GitHub, Facebook or whoever to host your group’s private data?

MaidSAFE, MetaMask and other projects do 1,2,3. You should be in control of your keychains. We have plenty of desktop apps for managing eg git. Why let GitHub do it?

At the very least, run GitLab on your own in-house servers. But there are other alternatives.

And frankly, think about the speed and environmental impact of shipping all those bits to Google where you are “renting” Google Docs / Drive software to collaborate on something. You can have a lightning fast network in the Brazilian Favelas or a village in Namibia. Dating sites, ZocDoc, OpenTable, GrubHub can all be local open source apps running on local mesh networks. But nooo, we need project loon to send our signal to california in order to talk to our neighbor or coordinate dinner plans. And in Kashmir, etc. the government can simply turn off our internet and suddenly BAM — can’t even stock drugs locally for people??

https://www.nytimes.com/2019/08/14/technology/india-kashmir-...

For #1, yes it's decentralized but when running a team of people having a central clone is ideal. Yea I get it you can push and pull all day long but in reality people want to have a centralized location.

The big appeal for moving to mercurial for us was better merging than svn. Our team worked a certain way already, the tool handle this workflow and that's one of the reasons we chose mercurial. Decentralized was just nice for full backups in a lot of ways.

You're replying to a sarcastic comment which is actually intended to praise Sourcehut's good frontend, hope that helps.

Further, it's a completely open source product which strongly encourages self-hosting; the main reason to subscribe to the hosted instance is to give money to the dev.

It's written in Python so as soon as they have enough users it will be as slow as any webpage with tons of JS. Thankfully, that CPU load won't be on the client side... so it's still an improvement

Are you sure? Looks like static pre-generated page to me:

  $ curl -s https://sourcehut.org/|egrep 'meta.*gen'
  <meta name="generator" content="Hugo 0.57.2" />

[0] https://gohugo.io/

The front end of the site it static but the backend of the service seems to mostly by python.

https://git.sr.ht/~sircmpwn/meta.sr.ht/tree/master/metasrht

https://git.sr.ht/~sircmpwn/git.sr.ht/tree/master/gitsrht

https://git.sr.ht/~sircmpwn/core.sr.ht/tree/master/srht

edit: It is using flask according to this blog.

https://drewdevault.com/2019/01/30/Why-I-built-sr.ht-with-Fl...

The website/blog (https://sourcehut.org) is static, the Sourcehut app itself (https://sr.ht) is Python-based.

https://git.sr.ht/~sircmpwn/?search=sr.ht

I recommend you relax your convictions about Python performance a bit.

Server-side bottlenecks are more often than not database reads/writes and other IO. And the few CPU-intensive operations can be delegated to libraries written in C.

Pure Python is slow for CPU-intensive tasks, but that doesn't mean that a Python webserver is necessarily slow.

So what you're saying is that the author of Sourcehat is expected to rewrite Flask, Jinja2, etc in C?

As an example, https://git.sr.ht/~sircmpwn/git.sr.ht/tree/master/gitsrht takes 600-800 ms to generate, and it's probably heavily cached already. What will happen when they get more users? The site will be unbearably slow, unless the guy starts spending thousands in servers.

I imagine that the CPU-intensive parts of Flask and Jinja2 are already written in C. Much of Python's standard library is.

800ms is a reasonable response time, and if they scale up according to their userbase, they will hopefully maintain that time.

(Also, we don't know how much of that 800ms is Python vs. IO)

https://github.com/pallets/flask

https://github.com/pallets/jinja

0% C

Also 800 ms is NOT a reasonable response time to generate what basically is a bunch of text, that is absurd, but I guess this is the baseline in 2019.

I trust all IO is cached. The author can confirm it. This is just how slow Python is.

Switching to PyPy is likely to improve the overall performance if it's not database or I/O bound.

Almost none of the IO of that page is cached actually[0]. The only thing I'm sure that is cached is the templates themselves. I'm pretty sure that neither git lookups, nor DB accesses are cached, where you can save time. And mind you, this is served from a single data center in USA, and the latency can already eat up a lot of that. I in Europe have 300ms ping to it, so it might be that you are simply far away from the physical location.

[0] https://git.sr.ht/~sircmpwn/git.sr.ht/tree/master/gitsrht/bl...

This. There are also several optimized versions of python, other that stock, allowing you to increase performance based on your needs. I've shipped with many of them over the years.

I used to run an image board written in Python with around 15m PV/month on a Pentium 4 machine in 2004 or so. The first bottleneck I found was the database. Some query optimization and caching fixed it very quickly. It goes a really long way until Python become a bottleneck, of which can also be fixed relatively easily (image processing in my case, which is fixed by moving the whole thing to a worker).

Python isn't slow. Running a lot of Python is slow.

If it shards well and you have the capital to buy hardware, there's nothing wrong with using python

Reply on news.ycombinator.com