Spot the bug: javascript queue
-
The entire concept of "baking" makes no sense. Why is that necessary?
Where do you think the cookies come from, duh?
-
Why is that necessary? Why not just parse the raw post every time you need to display it?
Speed?
If parsing is expensive (say one boxing/markdown ) it makes sense. Clients can't onebox due to js origin rules. (I know there are exceptions).
-
If parsing is expensive (say one boxing/markdown ) it makes sense.
Then don't pick shitty-ass markup languages?
Markdown can't possibly be that slow, it doesn't fucking do anything. Community Server didn't "bake" and it was a thousand times more powerful.
Clients can't onebox due to js origin rules. (I know there are exceptions).
Onebox can't be baked anyway because it needs to be "fresh" each time.
-
fresh" each time
Why would you want that? That's trwtf.
Can't possibly be that slow,
Jeff +ROR +JS. yet it can.
-
Jeff +ROR +JS. yet it can.
Even that seems to take effort. We know that JS can update pages quite rapidly. Lots of sites manage it. Something horrible is going wrong.
-
OK, let's back up here. We haven't decided on "baking" or "double-baking" or any other kind of culinary metaphor; all we've decided on is we're going to use the exact same renderer on both server and client.
But your girlfriend said you're baking posts!
But she didn't say when, where, or why. Or how, for that matter. Are we caching the result? Haven't decided yet. Are we 'baking' the same content on both server and client? Haven't decided yet. Also note the use of
"quote marks; they indicate a term being used in a non-standard manner.The fact is you're all reading too much into that post. Let's take this for instance:
@blakeyrat said:Then don't pick shitty-ass markup languages?
We haven't picked anything yet. And until we do, we won't know whether we need to cache the cooked result or not. After all, how can we design the post renderer before we know what it should be rendering?But don't let that stop you discussing the pros and cons of baking and markup stuff; it's all useful info ;)
-
The entire concept of "baking" makes no sense. Why is that necessary? Why not just parse the raw post every time you need to display it?
well for us the baking will really just consist of a pass through an HTML sanitizer to strip out any bad and nasty HTML such as <sctipt> and
class="fa-spin"hence the scarequotes.
and before you ask, yes that step will be on retrieval from the DB.
-
We haven't picked anything yet.
As i recall we're down to a choice between BBcode and HTML and we're deferring the final decision until we take a good look at what WYSIWYG editors are out there for both options.
And either way we go with those two we'll still need to do the HTML sanitization "baking" step.
-
he difference being that the reder code will literally be identical rather than just being "the same"
When/if I have time, I was planning on setting up a live preview for t3k4 using a websocket connection and just sending the bytes which are different both ways allowing me to have only a single content transform pipeline, which seems to me like the least stupid way to attempt it...
-
Might be a bit expensive in bandwidth/processing , I presume disco is doing it client side because of that.
-
Ah, so that's a terminology thing, I dont' consider sanitation part of "baking" but you do, so you might describe a system as "baking" on the server while I'd say it was not, and we'd both be describing the same system.
-
Might be a bit expensive in bandwidth/processing ,
You'd be sending tens or hundreds of bytes per second most of the time (unless some pastes in an entire page of text). Latency, on the other hand could be much more of a problem.
-
Text i'm not worried about, however pictures, files and oneboxes might require a bit more forethought. Diffing the updates is probably hellish.
Also how do you prevent a DOS by markup?
I looked for a c# to js magic bullet, but that looks unlikely to work out perfectly.
-
Text i'm not worried about, however pictures, files and oneboxes might require a bit more forethought. Diffing the updates is probably hellish.
I'm not sure that it's that bad -- an image is just some
<img>text: rendering the final output is the browser's problem. As long as your diff is 100% reliably producing valid HTML, all you're really doing is updating your local copy of that and loading it into the DOM.
-
Onebox can't be baked anyway because it needs to be "fresh" each time.
But, in discourse, it isn't. At least, it doesn't appear to be. If you one box a post and then update the post, the one box doesn't get updated.
-
... really? Isn't that not how it's supposed to work?
-
You'd think so, but Discourse and Jeff.
-
Ah, so that's a terminology thing, I dont' consider sanitation part of "baking" but you do, so you might describe a system as "baking" on the server while I'd say it was not, and we'd both be describing the same system.
Yeah, what's planned seems to be sanitisation rather than "baking" which seems to be a thing which only applies to Dickhorse.
