He might potentially be, but I've been pretty deep inside MUSHclient's guts in the past. I too believe it's one of the best clients out there, so don't get the wrong idea. Honest question: have you experimented with MUSHclient's codebase before? I actually refactored the scripting support and the regex matching module (though my changes weren't merged because they were too drastic). The main difficulty is that MUSHclient has a giant "Ball of Mud" antipattern at its core, so it's hard to tease things apart. But the meat of the client isn't really algorithmically complex.

In fact, I consider the most involved parts of MUSHclient to be the display and the scripting. Browsers give you both nearly for free. Simply treat the DOM as a scene graph, and pass user scripts to new Function("arg", "their code"). Now, you might say that browsers aren't performant enough for these components… but I think you might be underestimating the technology and evolution of today's browsers.


You mean miniwindows? Actually, those are what gave me the idea and impetus to build a browser-based client, because I think I can make it easier and better. All you need is an absolute/relative-positioned div, and there's your miniwindow. Add elements to it like any other scene graph, and the browser will handle rendering. Yeah, Canvas is really useful, but I think you might be overestimating its importance to a browser-based client.

Not being fast as mushclient isn't grounds for claiming the features aren't replicated to be satisfactory. I'll say it again. You're confusing less performant with not performant enough. And as for this canvas nonsense. Canvas would be harder, run less efficiently, be less supported, and break out of the document model for something that's mostly text! It's just absurd and it belies your self described expert status.

I can contribute a zlib example from my web-based automapper, which gets its data in async calls to a php file.

Server-side:

gzencode($output);

Client-side:

(nothing)

Someone, I think DH, mentioned earlier in the thread that if you begin thinking about a web app as your primary client (which everyone should), it begins to make sense for such features to be implemented server-side. This happened to me. Since I launched the web app, I implemented server-side timers, server-side multi-command input, server-side command repeat shortcuts. Very soon, I'll add server-side triggers as well. When I do, they'll have the potential to outshine anything that MUSHClient can offer. They'll have 0 response time (even if player is laggy as hell), and I can let people base them on any variable or event that could be useful, including stuff that is never reported to the client. But the biggest benefit of having usability features like triggers server-side to me is that everyone (even people using simple telnet) gets them.

Deimos, I agree with you that web apps have a lot of largely untapped potential. I disagree that it's impractical to develop them. I define practical as "something that will reach people". Level of effort is irrelevant to me if the payoff is real. If you define "practical" based solely on level of effort, you would need to have an estimated number of hours that MUSHClient took to develop (a point that Runter made earlier), so you can compare it to what you think a comparable web app would take. Otherwise, it just sounds like an excuse to do nothing.

@Runter: Feel free to implement a working ANSI translation buffer and zlib decompression layer in JS. Yes, of course it is possible. No, the performance will not be satisfactory. And that's even without trigger matching and screen buffering.

@Twisol: The pieces of Mush separated could individually be recreated with satisfactory performance. Layering them will bog down even the best JS engine at this point. In particular, as I keep reiterating, implementing real-time zlib decompression, ANSI translation, etc. in JS is no joke. These alone are very taxing operations in JS. I don't think I'm underestimating browser tech at all. I'm very aware of what modern browsers are capable of these days. It constantly impresses me with each new version release, especially now with the paradigm shift to ramp up JS performance. I just don't think some people here realize how intensive some of the features of "80s technology" are within the confines of a JS engine in a browser.

@plamzi: That is not how zlib streams work, unfortunately. In particular, a browser doesn't natively handle zlib streams (but handles zlib decompression fine). For a JS driven client to be able to speak to an arbitrary MUD server using a zlib stream, a decompression layer would have to be written in JS - the browser can't do that. If it could I likely wouldn't be as sure as I am that Mush couldn't be practically replicated in web tech.

Doing all of this server-side isn't a terrible idea, but your performance will suffer server-to-client latency, which would be very noticeable and frustrating if you're used to the responsiveness of normal clients. Also, that would be replicating Mush in server scripting tech and piping output to a browser, not replicating Mush in the browser itself :-p

OK, so gzipped packages are not zlib streams. Is that really the show-stopper for you? I very much doubt it. Check out this link and read the first response - it's what I call practical.

It seems that HTML5 will have zlib decompression abilities. Assuming that it does, can you give us a preview of what your next "line in the sand" would be? Embedded LUA engine maybe?

ANSI? Already done, simpler even than my Telnet library. Zlib? Going to handle that server-side, but I haven't written the Node.js extension yet. The existing ones don't let you pull leftover uncompressed text off the end of a stream if it ended in the middle of a chunk of data.


Er, ANSI is actually quite trivial. I parse the ANSI codes out of the text and create a simple style-string object that gets processed by the renderer.

If I had the choice (there's no widely-deployed binary buffer for JS in browsers yet), I'd deal with zlib on the client from a WebWorker. Since I can't, I'm doing it from Node.js's event loop in a C++ binding to zlib.


GameBoy Color emulator
Linux emulator

I think we can do this.

EDIT

Lua VM (probably incomplete)

@Twisol: If any of your dev is server-side, then my arguments aren't applicable, as I'm operating under the assumption that we were talking about replicating this stuff within the browser itself… not doing it on a server and piping it to the browser.

Most of it is. If I could, I'd do it all client-side, but there's two problems. (1) I'm not using Flash, Java, etc. so I can't connect straight to a MUD. That means I need a proxy server to do it for me, which is what Aspect!server does. And (2) client-side Javascript has no support for binary buffers (yet), so I'd need to take Telnet and encode it as UTF-8 for the browser, and then I'd have to deal with that mess. The server just makes the data palatable for the client, and handles the Telnet layer. But everything else is client-side, including ANSI, triggers, aliases, scripting, miniwindows, and all the good stuff you expect from the client.

@Twisol: And apparently the zlib decompression. :-p That's pretty significant piece. Without having to muck with telnet or zlib, I could see a well designed client in the browser working adequately enough. I could go either way at that point, but as I said, Ive been arguing the notion that doing all of this in the browser would not be performant enough, and Im sticking to that.

It would be, we just don't have binary buffers. Unless you're saying it's because we have to muck with workarounds and UTF-8 that it wouldn't be performant, in which case, of course.

EDIT: Telnet's almost as simple as ANSI, by the way. More involved in its API because it's a protocol, not a format, but still simple in execution.

You're wrong. I'm sticking to that.

@plamzi: There are no more lines in the sand. Most of Mush's features are not performance sensitive. They would just take a lot ofeffort to replicate. I only think such a project is impractical for two reasons: 1) the performance sensitive pieces (incoming data processing) wouldn't be satisfactorily performant implemented in JS, and 2) the whole project would take a ton of effort. The second reason could ne mitigated by too much free time :-p or putting together a team of people willing to work on it. The first can't really be resolved by anything other than another 4-5half browser versions probably. Or implementing pieces on the server, but that's apples and oranges.

As long as I build a great MUD client accessible from the web, I don't care whether or not you call it a web-client. It's something useful.

@Twisol: Doesn't the newest ECMA draft include support for them? I could swear I read about that not too long ago. Anyhow, if that's true and when the vendors get around to implementing it, I'll look forward to evaluating your client ;-)

Anyway, it was nice debating with most of you again. Sleep calls!

@Twisol: Of course it is! Sorry if you thought I was implying otherwise. I was merely debating about the abilities of web tech, not the usefulness of your project

Yeah, there are implementation efforts for binary buffers in Javascript, but nothing really cross-platform yet. Nothing I'd really feel comfortable using. And I'd still need a proxy server to connect to the MUD, and if I'm going to be handling the connections I feel better if I manage the network layers there too. You could pretend it's a thread alongside the front-end client if you want - I would've offloaded zlib to a WebWorker anyways.

EDIT: No worries! The bulk of my project is in Javascript, and I'm toying with an actual MUD in Node.js too, so I am fairly opinionated about the utility of web tech at this time. ;)

If the question is "How much effort would it take to replicate MUSHClient in a browser?" then I think I'll go even further than you and say that it can't be done, period. But is that even a meaningful question to ask? What if I asked you how much effort it would take for MUSHClient to replicate my web app? That can't be done, either. What does that mean? That any platform has strengths and weaknesses. Some of them are unique to the platform. But while the desktop apps are in gradual decline, mobile and web apps are on the rise. You can stay desktop-only if you so wish, but I want to still be able to reach new players 5 years from now.

@plamzi: The question was whether a client which was built with web tech and replicated the features of Mush would be performant enough. Actually replicating Mush just to say it was possible would be pretty silly, I agree. But I think the former is actually a useful and interesting question.

I understand–we're just coming from different places. You're interested in whether a generic web-based MUD client (like Twisol's) can match the performance of MUSHClient. To me, this seems like a hypothetical benchmarking question (I find even non-hypothetical benchmarking questions a tad boring.) and I can't imagine why I'd care whether the answer is yes or no. May I ask what it is about this question that interests you?