SQLite can handle concurrent reads, but needs to lock the entire DB when writing. Multiple workers shouldn't be a problem per se, but if you need multiple workers to support the traffic, then maybe a client-server db like postgres is a better choice.
Writing does not lock readers if you use the WAL feature (Write-Ahead Log, introduced in 2010) https://sqlite.org/wal.html > WAL provides more concurrency as readers do not block writers and a writer does not block readers. Reading and writing can proceed concurrently.
Right. I meant it doesn't support concurrent writes.
What happens on an iPad? Do you mean memory and CPU on the server or on the client? I do wish that it were server-rendered by default. SPAs are not ideal for content websites for several reasons. And one shouldn't need a recent browser version to read and participate in the WWW.
Discourse uses too much memory on the client and crashes the browser. As you said, someone shouldn't need latest gen hardware to use the WWW. I personally don't have a lot of control in what the predominate platforms are on the internet, but I have remarked to myself in my bunker that Discourse is a first world echo chamber because no-one else can run it. Look at hacker news. It isn't pretty and it has lots of glarin…
I love HN's design. It's the "Craig's List school of design" -- simple presentation of information with no distractions.
The WWW has been heading in a terrible direction (animation, over-saturated colors) over the past few years. People use too much JS and CSS3 because it's possible, not because it's a good idea.
Have you tried turning of JS on Discourse forums? It should render a minimal HTML page via the elements. Maybe they should do feature detection -- if a browser isn't capable of running the application, turn off JS and serve the minimal HTML. If it works, you could open an issue in their Github repo or post on meta.discourse.org.
I built a forum from scratch once and it is a comical amount of work. The initial CRUD weekend-ware is straight forward. LIMIT/OFFSET for pagination. Throw in some Markdown support. Seems easy enough. But the devil is in all the individual features that make a forum usable. Like getting notified when someone @mentions or replies to you, marking threads that you've posted in, tracking the high watermark per user per t…
I've had certain forum software sometimes as a side project, sometimes as my man full time project, during the last 7 years. So yes there's lots of work. But in my case lots of time was "lost", in learning web development / React.js / Angular / Dart / other stuff, and porting from the-wrong-technology, to another the-wrong-technology, and building the wrong things that no one wanted. I think the Discourse (forum soft…
I think the lesson here is to stay away from frameworks as much as possible.
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.
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.
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.
>There is a generation out there that doesn't seem to know that server side rendering exists.
Oh, don't worry, they're reinventing it in JS. I've had a recent project proposal and one of the engineers said that to make the webpage faster we could prerender the pages on the server side with JS.
Like, at that point, you're just using PHP with a different name and worse performance (a small 4$ shared hoster can easily handle 1M users per month, I've yet to see a NodeJS app handle 1M users per month on a 5$ VPS without problems)
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.
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.
A good example of "the devil's in the details" is the decision chart of how Slack decides whether to send a notification for a particular message. I mean, how complicated could it be, if the user is in the channel and he doesn't have notifications turned off, then send it, it's just a simple nested if statement, right? But, it turns out that when you map out all of the decision points, it's quite a bit more complicat…
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.
Writing does not lock readers if you use the WAL feature (Write-Ahead Log, introduced in 2010) https://sqlite.org/wal.html > WAL provides more concurrency as readers do not block writers and a writer does not block readers. Reading and writing can proceed concurrently.
Right. I meant it doesn't support concurrent writes.
On any personal website, that shouldn't be much of a problem, most blogs have only a few writes at a time
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?
It's not hard to implement the logic when you have the rules. It's hard to define the rules.
> It's not hard to implement the logic when you have the rules. It's hard to define the rules.
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…
I'm waiting for Web 3.0: everything goes through websockets. We can also call it newframe (mainframe 2.0) if a new buzzword is needed.