Code pushed!

[denise]

The code push is now complete! Please report any problems here for the next 24 hours or so (and to Support after that).

Code tours describing changesets included in this push are:

* 22 Feb - 13 Mar
* 14 Mar - 23 Mar

In particular, we're asking people to turn on the "New JS on Journals" option on the Beta Features page. We've finished converting all the JavaScript inside your journal to JQuery, the more modern JavaScript library we're moving towards. The version available for beta testing now is the release candidate. With the next code push, we will be opting everyone into that beta (with the ability to still opt out of the beta version if you discover a showstopper bug that prevents you from using your journal); with the code push after that, the code will be taken out of beta and you will no longer be able to turn off the new JavaScript behavior at all.

So, turn on the beta now, and report any bugs with JavaScript in your journal to the dw_beta "Last Call" post if you're sure it's related to the new JavaScript, or here if you aren't sure whether or not it's an issue with the new JS!

Comments

[momijizukamori]

I'm just another user here, but - for the most part, everything will look pretty much the same. The Javascript update makes the icon browser look slightly different, but have basically the same functionality, and everything else is the same. It's pretty much all hidden work on the scripts that run display, to make them more modern, and easier for new developers to work on. That's why everyone is being opted in, with eventually no option to opt out - the clunky old code will be gone.

[esteven]

Thank you for making it clearer to me in more one-syllable words. :D But if everything is pretty much the same, then why do I read of firefox freezing, screen fatigue, difficulties in cross-post settings and emptying caches, all of which would not happen/be necessary if everything stayed much as it is?

Sorry to be such a looby, and thanks again for your patience.

[denise]

Whenever you make a change, someone somewhere will have problems with it! This is why we do updates in incremental fashion, so people can report the problems and we can fix them.

Improvement is always necessary, because no matter how many people say everything's just fine as it is, there's equal numbers of people having problems that you just don't see (whether those problems are bugs, usability problems, accessibility problems, or things just not working as well as they could). For instance, replacing all the Javascript used to run your journal with jQuery, a more modern Javascript library, allows us to have access to a lot of the development being done by the jQuery team, which means that we don't have to try to fix all the problems ourselves; we can take advantage of the development time other people have invested in the system. The old Javascript used in your journals was written a very, very long time ago, and we've been seeing multiple reports of things not working in newer versions of browsers because the standards have moved on. Switching to jQuery means that we don't have to spend all that time debugging problems with the old Javascript libraries: the people who develop jQuery do the browser testing, and we get the benefit of their work.

[esteven]

I understand perfectly what you are trying to say, I just don't understand the words you use (that is why I thanked momijizukamori for her translation for ejits).

Still, I appreciate that you are doing a good job for your users.

[denise]

Hee! I'm sorry; I try to keep things as simple as I can, but it's a complex topic to try to explain. I'm sorry my comment was gibberish :)

In the simplest terms: a lot of the things the website relies on to let you read comments to your journal, manage comments in your journal, submit answers to polls in your journal, etc, were all really really really old. (LJ was first written in 1999, and we branched from LJ; many of the things have been updated or added since then, but the most basic parts are in their teens by now!) That's good in that they've been fairly well tested by now, so most of the bugs have been ironed out, but it's bad in that browsers and computers have changed a lot since then and how they handle showing you things on websites and letting you interact with websites have changed with them.

We could write our own new versions of all the things, but then we'd be the only people who could fix problems with them. That limits us, since there's only about a dozen people actively working on Dreamwidth at any given time. Fortunately, a lot of these things are things that other people want to do on their websites, too. So people have written "building blocks" of software that can be used in lots of different commonly-needed situations, and made those building blocks available for anybody to use.

Previously, we were using our own custom building blocks, so we were the only ones who could change them or fix problems with them. By switching to the more common building blocks, we get the benefit of everybody else's work, too -- now it's not just a dozen or so people fixing bugs with the building blocks, it's thousands of people who are using those building blocks on lots and lots and lots of different websites. Because people view and interact with those building blocks in lots of different web browsers and on lots of different types of computers, those building blocks have been really well tested and people have found most of the bugs that would take us a really long time to find and fix.

Now, it takes time and effort for us to integrate those building blocks with Dreamwidth -- just like it takes you a long time to build something with a set of Legos even if you have the blueprints to build that life-sized model of a Lego car -- and sometimes there'll be a bug in the way we put those building blocks together (kind of like you not noticing until you're done that you have a blue Lego where the pattern calls for a purple one) -- that's why we're doing this slowly and making sure that people test at every step. But when we're done, it'll kind of be the equivalent of that full-sized Lego car, and since it's made out of building blocks that many, many people use all across the internet, we'll have the benefit of millions of people testing and hundreds of programmers working on the underlying building blocks.

Does that make it clearer? :)

[esteven]

Thank you so much for giving me your time and patience. You were really trying hard and I commend you for that.
*raises glass to you*

It is not your fault that I cannot build Lego cars either ;D and am deeply mistrustful of changes I'll have to see what comes out of your code push and how it will affect my comfort at DW. I would really hate to leave.

Thank you once more. :D

[momijizukamori]

Well, the screen fatigue is from the icon browswer redesign. And crosspost settings are from the other beta feature, which is the new update page they've been working on for months. I don't really know about the Firefox crashes - cache-clearing is an unfortunate side effect of moving from old code to new. If your browser still has the old code saved in it's cache, it has to be cleared for the new to work properly. Usually it does it automatically, but sometimes it doesn't update properly, and clearing it should be a one-time only deal if necessary.

So yes, these wouldn't be problems if stuff stayed the same - but we'd have other problems in the form of outdated code or code that isn't easy to work with (and the old icon-browser has problems with it's design, which is why it's being updated).