Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

imageboard

Name: Anonymous 2011-12-04 7:45

I want to write a good imageboard engine with clean code, to be the preferred choice instead of 4chan's shitty codebase (admit it, it's true) and derivatives. What I am having trouble with, is what language/environment to do it in. Every one has ups and downs. Here are some I can program in:

* C with CGI is very fast (except for fork overheads), but development times are going to be absolute shit.
* C with FastCGI runs even faster than CGI, but the development times are the same as above, and I don't like the added complexity compared to plain old CGI.
* Python is just shit. Period.
* node.js is a cool concept, but I am worried about performance/scalability, as well as the fact that it doesn't seem like a solid platform to bank on; I always feel that in ten years, no one will care about it, and my imageboard will be dead.

There are other options, like perl, but I don't know them yet, so learning overhead must be taken into account.

What should I do, /prog/?

Name: Anonymous 2011-12-04 7:52

C with FastCGI if you have time to lose, Common Lisp with FastCGI otherwise.

Name: Anonymous 2011-12-04 7:53

>>2
Are the performance benefits of less forking really that great compared to CGI that it's worth it?

Name: Anonymous 2011-12-04 8:54

Use Python or Ruby with a micro framework.
Sinatra + Thin + nginx has a good balance between easyness and bloatness.

And you don't have to worry about ``speed'' for this kind of web software if you have a good caching mechanism.

Name: Anonymous 2011-12-04 8:58

but development times are going to be absolute shit.
Ask yourself how much time will be saved by all the users that will ever use your software over how much additional development time you'll need.

Name: Anonymous 2011-12-04 9:25

3-4 peak concurrent users
3-4 years of dev time
Sounds perfectly reasonable
C all the way.

Name: Anonymous 2011-12-04 9:39

Don't write an HTTP imageboard engine, it's a waste of time. Instead, make a specialized BBS protocol and implement it. It will be more fun, more efficient, and faster to develop.

Name: Anonymous 2011-12-04 9:58

>>7
hibt?

Name: Anonymous 2011-12-04 10:01

>>6
For a barebones imageboards+off the shelf stuff like libev or own mini httpd server would be maximum a month.

Name: Anonymous 2011-12-04 10:05

>>7
I agree with this person, it is something I've been thinking about myself.

Don't even think about taking inspiration from NNTP, it is absolute shit.

Name: Anonymous 2011-12-04 10:47

>>10
Distributed or centralized?

Name: Anonymous 2011-12-04 11:01

>>11
Centralized is always better.

Name: Anonymous 2011-12-04 11:06

>>12
FBI will bust you for centralizing all the CP.

Name: Anonymous 2011-12-04 11:08

>>13
Bust my anus.

Name: Anonymous 2011-12-04 11:23

The fact that 4chan/Wikipedia/other high profile sites use shitty languages like PHP should indicate that the speed of a programming language isn't very important for websites.

It's other factors which make a website seem slow.

Name: Anonymous 2011-12-04 11:32

>>15
IHBT.

Name: Anonymous 2011-12-04 11:34

>>15
They're cached in several layers, raw PHP is x100 slower than JavaScript.
It takes ungodly amount of cludges to make PHP fast,secure and "scalable":
 The once-generated PHP content (a single puny HTML page) doesn't scale when everyone(>5k concurrent) reloads the same page like on 300mget and the php Script has to regen new content.
Compared to C servers which have them the functionality in native code(compiled modules), such stuff takes nanoseconds to generate.

Name: Anonymous 2011-12-04 11:41

Either way take apart open-source C server and remodel it, would be 1 month max.
And you get all the free functionality+optimizations+custom code running your board without effort.

Name: Anonymous 2011-12-04 11:42

>>15
PHP is the bane of Facebook's existence, they spend ridiculous amounts of resources to make it go fast.
I bet they could throw ⅓ of their servers if they could rid themselves of that ungodly abomination.

Name: Anonymous 2011-12-04 11:51

>>19
PHP is made by jews.
Facebook is made by jews.
Are implying that jews make problems for themselves?

Name: Anonymous 2011-12-04 12:12

>>20
Well if you don't have anything to contribute, you might as well get it over with and kill yourself.

Name: Anonymous 2011-12-04 12:23

Go is the future of Web applications.

Name: Anonymous 2011-12-04 12:41

>>21
Maybe I should kill a few jews instead?

Name: Anonymous 2011-12-04 14:07

>>18
I'd just use a HTTP server library.

Name: Anonymous 2011-12-04 20:17

>>24
Why embed my own HTTP server, when users may want to hook it up to a myriad of other servers like lighttpd, thttpd, apache, etc.

Name: Anonymous 2011-12-04 20:23

>>25
/prog/'s anii are full of shit
Breaking news.

Name: Anonymous 2011-12-04 20:30

>>17
not using static html

yhbt

Name: Anonymous 2011-12-04 20:33

>>27
That's another thing. I'm very interested in implementing an AJAX-based interface which will run faster and be more useful than a static HTML interface. However, I know that many people don't like anything that ain't static, so I'll make it modular, and implement two interfaces that you can choose from.

Name: Anonymous 2011-12-05 8:56

>>28
Implement a static only interface and let others write userscripts and extensions for you.

Name: Anonymous 2011-12-05 21:40

>>29
No. Because I, as the developer, like AJAX interfaces, there will be at least one user of that interface, and therefore, it is needed. Fuck userscripts and extensions, by the way; they act on the hackish premise of parsing the source/DOM which is volatile and breaks.

Name: Anonymous 2011-12-05 22:00

>>30
I agree with that sentiment.

Name: Anonymous 2011-12-05 22:09

>>31
Which one? My sentiment about an AJAX interface, or my sentiment about userscripts/extensions hackishly parsing the page after-the-fact?

Name: Anonymous 2011-12-05 22:45

>>30
Sure, JavaScript aided interfaces are perfectly fine.
AJAX however, is shit, and is only useful for real web applications, as in, desktop applications ported to run in a browser, like email clients, calendars, etc...

Name: Anonymous 2011-12-06 1:20

>>33
And likewise, "real web applications" usually tend to be shit too.

Name: Anonymous 2011-12-06 3:00

>>33
Check 'em!

Name: Anonymous 2011-12-06 4:06

>>25
CGI is slow as shit probably acceptable for low-traffic sites. Implementing a simple but robust web server is probably a better approach since you can (A) give all your friends COOL FREE IMAGEBOARDS and (B) use nginx as a reverse proxy and/or load balancer

Name: Anonymous 2011-12-06 6:05

If all jews are to be killed, the world would become a better place for all. And there wont be PHP and Python anymore, because both language owe their existence to jews. Just imagine a world without jew! A world without evil and ugly!

Name: Anonymous 2011-12-06 7:14

>>36
There are already plenty of simple but robust web servers available for every language.

Name: Anonymous 2011-12-06 8:20

>>38
Google App Engine supports only Python/Java. So are other service providers.

Name: Anonymous 2011-12-06 8:43

>>39
Why do you want to use google app engine?

Also, Heroku. Also, usey your own server.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List