Live data from Hacker News

Show HN: Orange Forum – Web 1.0 style forum written in Go

goodoldweb.com

111–120 of 178 posts

Re: Show HN: Orange Forum – Web 1.0 style forum written in Go

#111
post #109

Earlier quoted context omitted.

Do you get why you'd prerender a JS app and why an isomorphic setup is fundamentally different than server side rendering with PHP? You're comparing different things. Also, JS performs as well or better than PHP. Not sure why you guys get so ideological about this.

>Do you get why you'd prerender a JS app and why an isomorphic setup is fundamentally different than server side rendering with PHP? Tbh, I'm not really interested. I can squeeze amazing performance out of a 10kB self-written JS library with noscript fallbacks than most JS-heavy apps out there. The sites I develop work with dialup connections or worse. Because my phone regularly has only such a connection. Modern JS…

Discourse is a Rails forum with a JS frontend. It's bloated. I don't disagree with your PHP experiences, you're extrapolating from:

1) your personal experience

2) mature software vs immature software

3) bad software vs good software

You can't say you're "not interested" in understanding the other side, throw out your own anecdotal benchmarks, draw conclusions from that, and then demand that others provide "non-synthetic" benchmarks in order to prove you wrong. Well, you can, but it doesn't seem especially objective.

Re: Show HN: Orange Forum – Web 1.0 style forum written in Go

#112
post #109

Earlier quoted context omitted.

>Do you get why you'd prerender a JS app and why an isomorphic setup is fundamentally different than server side rendering with PHP? Tbh, I'm not really interested. I can squeeze amazing performance out of a 10kB self-written JS library with noscript fallbacks than most JS-heavy apps out there. The sites I develop work with dialup connections or worse. Because my phone regularly has only such a connection. Modern JS…

Discourse is a Rails forum with a JS frontend. It's bloated. I don't disagree with your PHP experiences, you're extrapolating from: 1) your personal experience 2) mature software vs immature software 3) bad software vs good software You can't say you're "not interested" in understanding the other side, throw out your own anecdotal benchmarks, draw conclusions from that, and then demand that others provide "non-synthe…

Then please, show me a performant NodeJS webapp that works with noscript and slow dialup.

There is not much personal experience about that since it's a simple on/off comparison. Either it works without scripts on dialup or it doesn't.

Re: Show HN: Orange Forum – Web 1.0 style forum written in Go

#113

Ok, sorry, bitter old man coming through: this is Web 2.0, not 1.0. For all the buzzwords, Web 2.0 was defined by the dynamic interactive solicitation of user input as opposed to Web 1.0 being just static HTML. I don't think we've coined a good catchphrase for fat applications implemented in tons of Javascript with only lightweight AJAX calls to the backend. And then, of course, there's Web 0.1: https://thedailywtf.c…

[deleted]

Re: Show HN: Orange Forum – Web 1.0 style forum written in Go

#114
post #94

Earlier quoted context omitted.

The benefits from client side Vs server side are really a matter of scale. If you're running a personal forum / whatever then you're not going to notice a whole lot. But when you start having several hundred thousand or more concurrent users then being able to cache your pages in a CDN and only generating JSON responses via APIs really can have a profound impact on your server side resources.

You can cache server rendered pages in a CDN or Varnish or whatever you like, and there's also the use of the proper http headers to drive client side cache control. All of this works for server side rendered content.

Obviously there are a great many layers to caching (there's a whole multitude of other solutions out there that you've also missed off :p). However with regards to the specific points you've raised:

1) You cannot cache server rendered pages in a CDN (see footnote) if those pages contain user specific information (like this topic does). Information such as a user name, message read status - even on public messages, etc. If you do CDN cache those pages you'll leak user-specific information to other users. This is why you need tools like Varnish that cache page fragments rather than whole pages; or why you serve up HTML templates and then populate user information on the client side via RESTful API calls.

2) For similar reasons as above and again very relevant to the project in this discussion, HTTP Cache-Control headers also wouldn't help with the HTML if your backend is generating the HTML. In fact in those instances you'd probably want to set your max-age to 0 (again, speaking strictly about dynamically generated HTML. Static assets like JS, CSS, and images are a different matter but they're not server generated dynamic content). Granted with browser caching there isn't the risk of leaking user information to other users; the risk is just the browser not fetching an updated forum view / whatever.

Caching is one of those things that are easy to set up but also very easy to get wrong.

Footnote: Akamai might support it - if you're willing to pay their premium - as it's an immensely sophisticated product. However it's not an option I've seen when using Akamai and the other solutions I've used definitely don't support caching page fragments.

Re: Show HN: Orange Forum – Web 1.0 style forum written in Go

#115
post #89
post #64

Earlier quoted context omitted.

When you say "irony", are you genuinely surprised by this?

No, but I've seen comments on here from people under the impression that rendering on the client is a more efficient use of CPU, or that rendering a page in HTML is significantly more resource intensive than rendering the data in json. There is a generation out there that doesn't seem to know that server side rendering exists.

Which is why I never bought into the JS framework fad of the month and keep happily using .NET/Java stacks with server side rendering and minimal JavaScript.

We should make the best use of pure HTML/CSS web pages, that is what the web was made for.

For anything else, better go native with Web APIs.

Re: Show HN: Orange Forum – Web 1.0 style forum written in Go

#117

Earlier quoted context omitted.

Well this @mention is a bit more complicated than what one might think. For example: If someone creates a post, without any @mention, then edits it, and adds a @mention — then, do you detect this, when looking at the edits, and send a @mention notification now? And what if s/he edits the post again, and removes the @mention, then, do you remove the notification? Cancel the email if it hasn't been sent yet? And if the…

Sure, but the complexity you're describing is basically business logic. Incorporating it still shouldn't lead to a slow bloated web application.

I don't think OP said his project was slow or bloated: just that it was a lot of work to implement the extra little features.

Re: Show HN: Orange Forum – Web 1.0 style forum written in Go

#118
post #112

Earlier quoted context omitted.

Discourse is a Rails forum with a JS frontend. It's bloated. I don't disagree with your PHP experiences, you're extrapolating from: 1) your personal experience 2) mature software vs immature software 3) bad software vs good software You can't say you're "not interested" in understanding the other side, throw out your own anecdotal benchmarks, draw conclusions from that, and then demand that others provide "non-synthe…

Then please, show me a performant NodeJS webapp that works with noscript and slow dialup. There is not much personal experience about that since it's a simple on/off comparison. Either it works without scripts on dialup or it doesn't.

Here is one:

https://nodejs.org/en/about/

My point is, you can write any kind of app with almost any kind of server-side tech. If you don't like the culture, you may be right, but please be explicit about it.

Re: Show HN: Orange Forum – Web 1.0 style forum written in Go

#119
post #84

Earlier quoted context omitted.

Nice but misleading graph. If you count the situations that lead to "No" you'll realize that all the "No" cases can be easily checked for, and if you're not in a "No" case then you're in a "Yes" case. Can probably be implemented in a regular function with about 30 lines of code?

You're glossing over the fact that in order to have all of those complicated notification rules that users expect, you have to allow the user to set all of those complicated notification settings. You have to give them the ability to subscribe to threads, set notification preferences for a variety of items (channels, username mentions, keyword mentions, @here mentions, etc), set DND and exceptions, etc.

All of these are small things.

Re: Show HN: Orange Forum – Web 1.0 style forum written in Go

#120
post #103
post #84

Earlier quoted context omitted.

Nice but misleading graph. If you count the situations that lead to "No" you'll realize that all the "No" cases can be easily checked for, and if you're not in a "No" case then you're in a "Yes" case. Can probably be implemented in a regular function with about 30 lines of code?

> If you count the situations that lead to "No" you'll realize that all the "No" cases can be easily checked for, I think you might be under-counting the "No" cases. I counted at least 30 (and then stopped, with plenty still to go) so I don't think you'll get it in 30 lines of code unless you have some very long lines with rather impenetrable logic.

How did you count 30? Are we looking at the same picture?

I counted 9.

- channel is muted and message not in a thread the user is subscribed to

- user in dnd-mode and there's no dnd-override

- this is a @channel mention but @channel mentions are suppressed

- message is for a thread user is subscribed to but channel notification perf is nothing

- notification preference for device is set to "never"

- @here mention but user is not active (not here)

- highlighted word in a thread message the user is not subscribed to

- channel notification preference is set to nothing

- I couldn't understand this condition (@mention in a comment on a file not owned by user?)

You can check these conditions sequentially and if any of them match, return false.

The last statement in the function would just `return true`.

The function needs a struct representing user preferences and a struct representing what's being currently parsed as inputs.

It's really not that complicated.

Post reply on HN