 For those looking for the search lab, that's not here, it's in Club H-Room down the corridor. So many people for JavaScript, that's unusual. Yeah, of course. We were wondering if we were going to get like two people or fifty people. I'm really unsure. So if you're checking Twitter, the last tweet to the DrupalCon hashtag has a link to a document where we can take notes. So if you want to take notes while we're in the session, you can all take them in the same document and you'll have it in perpetuity. Use the mic. Or until Google blows up. Or the sun experiences heat death, whichever happens first. Alright, so today we're going to talk about JavaScript testing. It's more going to be us presenting to you what we currently have and what we currently do. And basically asking you what you would do if you could implement testing for DrupalCon. So if you have ideas of a specific framework or specific thing we should be using to do JavaScript testing. Well, let us know it's a core conversation. It's not a core presentation, so stop us anytime. So first, why do we want JavaScript testing? Because it makes maintenance easier. When we refactor, it makes sure we don't break stuff. During the H release, we already broke ViewZUI, states, overlay, table drag, vertical tabs, collapsible field sets, contextual, and probably some other we don't know about. So testing is good. So that's what we want. It's been pretty painful and now a web chic is a bit scared when she commits JavaScript patch because there's no testing. So it gets in the way. The testing scope currently in core, we have 107 custom Drupal JavaScript files and none of that is tested or very little of that is tested. Yeah, you know, that's not great. So first, we can test the actual code itself so that tools like JS int, JS lint, these kind of things to make sure that you know the syntax is correct and these kind of things. But it doesn't do anything for the actual behavior and the interaction that the JavaScript is supposed to provide. So I guess the first question to you is we need to integrate JS int to test bot to make sure that at least all core JavaScript patch follow the JS int configuration we have in Drupal 8. So we would need someone who's willing to integrate that with a test bot because it might take a bit of time and a bit of effort. So who might be interesting in doing something like that? I'm going to add a volunteers section to the document. You can put your name. Yeah. I imagine that's going to be one of the hardest things to find, a volunteer for test bot. So should you just pick one? Yeah, I'm just saying. Number 17. Yes, we could put that in Coder module. Yeah, actually. But since it requires some Node.js stuff, it might not be straightforward to integrate, but we can try. So yeah, JS int or test bot or Coder module. You should mention that in Drupal 8 core at the root, there's a JS int RC file. Which automatically sets the correct configurations on JS int. So if you have it installed locally through like, I think brew will install it, maybe, or like NPI. I can't remember which one of the package managers doesn't. But if you run it from Drupal core on a particular file, it's going to pick up the correct configurations. And also it's picked up by IDE like, well, personally it's PHP storm, but you know, whatever is integrated with JS int. It picks it up and run the test when you edit the file. So that's helpful. And we should mention too, there's a policy at the moment in core of absolutely no messages, no warnings. Nothing goes wrong with JS int when you run it. I run into this all the time because I'm okay with warnings personally, but Node wants zero output so that he can run it and get a clean JS int. So it sometimes means you have to play some games with the JavaScript. But yeah, it's kind of nice when there are zero things coming out of it. So I guess like who are in their project use JS int or some kind of validation tool for JavaScript files? Oh, that's good. So I mean, is this kind of changes stuff you want to see in Drupal core? Because I mean, we did that assuming that you would want to run it for your country module as well. Yeah, so that's going to happen for country, at least some of it. If you have any feedback on the core configuration, feel free to send an issue or open something in the issue queue to change some settings that, you know, not set in stone yet. I guess we're done with this topic. Or do you have anything else to add about just code verification testing? Maybe you could describe what JS int does. I think we have a slide about that. Yeah, that's right. So who didn't know about JS int? Oh, okay. Sorry about that. So JS int, a command line tool that you run and it will verify your JavaScript files for some very easy and common mistakes that can be made. Like, you know, you don't declare your variable, so it ends up as a global variable. That's bad. So JS int will tell you, you need to change this and this variable and declare it properly. Also, you know, brackets on if, else, this kind of things. Yes, syntax verification. And if you want to know more about that, JS int.org, there's maybe more explanation than what I give you. So I guess the current, for the actual behavior and interaction testing, what we currently use is test swarm. So that's been written by Attics, who wrote, like, pretty much all the useful stuff in Drupal 8. As far as JavaScript goes, like the picture modules at him, test swarm, and, yeah, other things. So test swarm module with QUnit testing. So QUnit is the framework that jQuery uses for its own testing. Then we have the FAT module that goes with it, which is a front-end automated testing test. It was all made up for the acronym anyway. And yeah, that's used QUnit as well. So I guess the question is, do any of you already use the test swarm module for Drupal for testing your stuff? One, two, okay. I know I've used it, so. And also, is it just right after, or are we going through a testing, a test, some test example? Yeah, I'll explain kind of what it does, show a bit of the code, and then Steve has a running example of our current suite of tests. Maybe, it ran, like, two seconds ago. And we'll see what we can show this look like. So the output of test swarm is essentially a table that tells you, you know, if all the tests within a particular group passed, or if they failed, you can drill down into a particular failing test. It doesn't tell you why it failed. That's something that developed for us to figure out. And it's a fairly basic presentation. I think, you know, in terms of our tools, this is version 0.01. It doesn't, it's not very usable. I'll just say that. Like, it takes a lot of tinkering. You have to know specific URLs to go to. It often fails on obscure Ajax errors. This is something that we're all building in our spare time. And bugs get fixed when we try to run the tests and they break. And you just, you have to fix the things so you could, like, get to your tests again. So let's go into the next slide. So let's look at some of the code that, you know, what a test in our system would look like. Essentially what you do is you declare your tests on the Drupal.tests object as a method, or an object. We have, it's very similar to simple tests in the sense that we have this getInfo method, a setup and a teardown. The difference between the setup and the teardown is that we don't have the separate, you know, encapsulated installation that simple tests does where you have to essentially build your installation from the ground up, you know, enabling modules, creating users, logging them in, going to pages. These tests run on the page that you start them from, or a page that you can direct it to, but it doesn't always work. So the problem is sometimes you'll have a test fail just because you're not on the right page when you run it, but if you move to the right page, it passes. If we were going to integrate this into Drupal, you know, the testing suite, we would have to somehow integrate it with simple tests so we could also allow you to create the environment, on top of which you're supposed to run your tests. There's also a lot of pollution from other pieces in the page. Steve spent an hour last night debugging a problem that just happened to occur now and not six months ago because of a feature that was added. But the tests were totally fine if you sort of tweak them. So we have a tests object. Inside of there are the individual tests. These will look like the functions inside a simple test. So the public functions in the Drupal version. So let's go on to the next slide. Yeah. So the anatomy of a test, if we're looking at an announce message in QUnit, let's go on to the next slide. We have the declaration at the top of the QUnit test where you have to declare how many things it should expect to test for, how many assertions you're going to make. If you have more or less assertions than that expect number, the test will fail. So we can see here that I have three assertions. I'm going to insert in equals. I'm going to assert actually three equals where I'm finding either a DOM element on the page or some text and saying that those are equal. All right. So then on to the next slide, we can see one of these assertions. We go and we find an element on the page and then assert that the length of that variable, that dollar live variable is one. So if I found that one thing, those two things are going to be equal. The test passes. And then again, we can see another type of test here where I've just got a string that I've created and I'm going to pass that into the announce method and just make sure that it actually gets printed to the page. So on to the next one. And then we have this kind of quirky block of text here where in order to essentially wait for something to happen, we have to stop the tests, set a timeout, run another function, and then once we've done those assertions, then start the test again with that QUnit start method. I've written tests where I have to nest this sort of thing like five and six levels deep where you're constantly starting and stopping and running set timeouts and it gets a little tricky. I wish that QUnit had a slightly better way of doing these weights. You're kind of thrown out of the system when you call QUnit stop and you have to figure out how to get back on track. So in this particular method, the announce method, it waits a certain number of seconds before it executes. So we have to wait in the test for that to execute before we can go check to see if it actually worked. So the reason we're waiting is the results of just this particular method here. And also it has the announce method as the manipulation. So if you call announce too many times in a row, it just kills the performance. So you just wait and bundle all the message together. The API that returns weighters, so if you say some element dot physical, it would wait until the element is physical, of course it had a timeout. But the nice thing is that you can queue up, so you can say this element dot physical dot click for example, and you pass in a function, that function is called when this is, when physical function, so it can change a lot of functions. What's the name of that system? CanJS. But we're using JavaScript MVC, but then they made it more the extract part of that section. Yeah. You can get just the controllers, just the models from it, just the views. Well, JavaScript is clean enough to do that, so, yeah. But I guess one way the queue needs to be, well, improve this use promise. So same concept as what you're using. It has a global queue. Sorry. Yeah, yeah. So I guess we look into that. So that's in the doc now, I guess. Yeah, I'm just going to show some tests actually running. Do you have the adapter? Yes, Mike. As we learned yesterday morning, a girl can never have enough dongles. And no, it just worked for basic purpose. So if we want to get more serious, I guess that's a good way to go. I mean, I don't have anything against it. It just, it wasn't, you know, what we started with. Because a test form allows you to spin it off to different machines. You can have that different machine be a phantom.js that runs on BeHat or something. Well, what I was going to ask is, like, could you use BeHat to write tests that run with this? I think that's supposed to be possible, right? I mean, I don't know. Yeah, but like the other way around, I think. Like you'd have to write a test here that runs on BeHat or on phantom.js. So BeHat is just the language. Yeah. Like it's just the grammar. Oh, he talking to the microphone? Yeah, just take it. BeHat is three things, at least. So you have the Goken language where you define like, given I am doing this, then I should see this and this should happen. And that's a natural language, right? That's a natural language, yeah. And then in PHP, you define a method that is like, given I create a node with a title and then when that gets processed, it will hit that method in your test class and you can extend it and you can add custom things and you can chain them together. And then mink, then from that, then executes the actual test with a browser which can be like a PHP browser, like basically the same as simple test does now, but can also be Phantom.js or Selenium. And then it will then get the output of that and then you get the result. So from the command line, what you see is the natural language stuff that you put in, green or red, but all of this goes on in the background and each bit can kind of be used independently for different things. I wasn't actually trying to do functional testing when I was trying to use it, I was trying to do something else, but it's not going like that. So that's what you get from it. Because it's like a runner and a language and a browser and the integration with the different things and they're independent bits, but they all fit together right on time. Well, I'm not sure if we could pipe that in, but it's definitely worth looking into. We have a sprint tomorrow, right? So anyway, here's the test results. You'll see that some fail. These are not necessarily because something is wrong in Core. These might just be because the test is wrong because Core got updated and test did not. But most of them actually pass, which is surprising. They actually all ran, which is also surprising. You can do the talking thing. And also, I mean, we haven't even decided exactly what we wanted to test. So that's a topic for discussion as well, like what do we want first and second and third and what we don't want to test also. So the solution we have so far, it's test-warm, well, maybe be hot, or at least we look into it. Maybe the CKT tour guys can walk us through what you planned. Yeah, we don't have anything to show right now about it, but JavaScript is what we do. We've been doing it for years and so it's very important for us. We've been looking around on JavaScript testing solutions. There are many of them. There are things like Yeti from YY, for example, which is pretty cool, but they're not modular or not complete or not as cool as we think they could be. And so right now we are on a design phase still and starting calling this thing. And now in October, we're going to start releasing some documentation, some specs about this project, which we call Bender.js. And we hope it will be very, very cool in terms of JavaScript testing. In our case, of course, we are talking about a library, which is CKT here, or even our product like CKT Finder, which are pure JavaScript applications to be tested. But we would be very happy to understand what is the Drupal case for JavaScript testing and to understand how we can generalize Bender to apply eventually for Drupal. And on the other hand, you're going to have a team of JavaScript developers working on this thing fully for the CKT benefits. So I believe that it can be beneficial for Drupal if we contributed somehow back to Drupal working together to make it cool. So from our side, you certainly have support on making this thing work. I mean, it means that you guys will base your tests on a different platform, which still doesn't exist. So it's hard to say that this is a good choice right now for you guys. But I think we should talk at least. So because what I see is that we start implementing that in Behat. And then we'll see if we can use some of your testing suites to test the other part that Behat is maybe not really good for or not really suitable for. So yeah, I guess we should keep on talking about that. Well, we want to make it very generic in terms of the assertion libraries that can be used, the syntax used for writing tests. It's supposed to be plug-able, et cetera. So it's something that, you know, we want to make it a framework for you that can be extended by an integrated other solution. We're open for talk. Well, thanks. I think Christophe is not here. That's too bad because Christophe from Workthrough.it Well, his project is do some documentation on the tool module we have in Drupal 8 and then test this documentation to make sure that it's still running after changes on whatever system is documenting. I think it was based on Selenium or something similar. Yeah. Too bad it's not here. We also have a website that checks for accessibility issues automatically. I'm not exactly sure how that's done, so maybe Jesse? Yeah, sure. Can you click on that link? No, that's not the one. That was our subliminal beer. So drupalale.org is a site that was put together by Dr. Miller. He's been the primary developer for the accessibility module and our accessibility efforts. Those are ones, not Ls. And he has the fortunate advantage of being funded by Cal State University in the United States. What he's done is taken what was a PHP library and ported it to JavaScript. I believe he's using QUnit under the hood. He has over 200 tests that work against the 508 specification, the United States section 508, and also the WCAG specification for accessibility. I believe up to the AA level at the moment. What we're doing is going through essentially and grabbing pages is all being done in a headless browser in the background, rendering those pages, and then looking through the pages for things like color contrast, checking elements like image and A tags for things like alts and title and things like that. Personally, I want to see something like this also get into our test suite so that committing a patch maybe it wouldn't be a blocking thing, but we would know if we were committing ourselves to technical debt in terms of accessibility going into the future. And it's a core gate. We could make this a blocking sort of thing like no accessibility failures checked into core. This year is to have this number down to zero by the end of November in our test suite, and then we'll introduce more tests to get us up to full compliance with the specifications as we go along. So, you know, testing the JavaScript is not as simple as just doing unit tests or behavioral tests. We also have this other level of testing that we need to consider as well. Yeah, it's kind of testing the HTML as well, to some extent. So, kind of a holistic fun and testing. And then we got also some ideas from people yesterday about Chai.js Synone.js or Jasmine as well that we could look into. So, if someone is interested to look at the different framework for testing out there and help out on doing a comparison, that would be nice, because then we would have a good data set to make a decision on. So, who might be interested in doing that with us once again. Awesome, thanks Reven. Can you include? Well, it's going to be like tomorrow, this afternoon, I don't know. We'll get started at least. Well, it's going to end up on an issue, so. And yeah, it's going to be long, so they're probably going to be beer involved at some point. Yeah, so the future like what we want to do you see where we are it's not very pretty I mean the test suite is broken so that's not going to help much. What we want to do, what we want what we want to get is to run the front-end testing with the test that we got, so with the PHP testing as well. But that might be in a while. How to help that's, you know, the sprint so we can help out on comparisons or just trying out right tests in test swarm or B-hat and look more into that. So we have this afternoon and tomorrow to help you get started if you want to. Potential issues, well, not enough knowledge I guess if you see any other, let me know. Because I'm not well familiar with integrating a whole test suite into the front-end test suite to a project. Yeah, can we test bot fat, yeah. I guess we can. So for the people who are not volunteering for integrating JSON to test bot Kat just told me that it's not that bad. Yeah, thanks. We have advisory code reviews on core already and those code reviews run completely different to the simple test tests. So you write like a new the test with the infrastructure like but at the moment you would write a new thing that instead of code or instead of simple test is the JavaScript testing that we run and so you just it's like there is an integration point that you have to implement and then there's like infrastructure issues getting deployed but it's not like you have to go and change everything that's there you just have to do the things that have would have been done for this. And who should we be talking to? Jeremy Thorson, but I think that catches understating how painful that would be based on kind of the obvious moment of work or there would be a quick thing to deploy but just the like it's to get code and simple test running like a couple of years ago was like massive thing and it's adding an extra one is not like you can do it I might just lie But Jeremy, like Jeremy is very interested in he's working on a new architecture for our testing infrastructure stuff specifically with the goal of being able to do more kinds of testing including possibly running up front and testing but I don't know the technical details because I want to talk to. The question that I wanted to ask is on like up here so like where do we want to get I think that we want to get to a point where you know all the JavaScript and core has regression test coverage in a minute right? Are there other slides? Okay, I'll stop talking. This is exactly that side. Yeah, hey I agree with all I go through this I thought you were done so I was going to go. Alright So what we want we wanted to have you talking to us about what you do in your projects so we can get ideas from that we wanted to see if there was some some one who could do project management on the whole testing I guess you could call that an initiative but not a D8 initiative like underground testing initiative for frontend project manager for that if you know some some spare time here and there because I mean don't leave it to developer to organize it's going to be messy some people who actually are interested in writing test and helping out on the infrastructure and also start defining what we want to test and how far we want to go because we can't test everything that's just not possible it's crazy but I guess first what we came up yesterday with was felt a Drupal kind of the Drupal API we have a few methods like Drupal.t in JavaScript make sure that this works well all the time the states API I know XGM has been beaten by that a couple of times that was a long time ago table drag because you know that's really all of the placing call Ajax and well if you can refactor that at the same time you know wouldn't hurt and the rest of the file that you can find in the MISC folder that shouldn't be in the MISC folder but that's another issue then views behavior we broke views a bit too many times I guess and the rest of the behaviors we have and I guess that's really what we want to start with because well at least Drupal the states it's not but the behaviors are going to be much more involved yeah yesterday you presented that actually you said that no Drupal it is bringing a lot of third parties JavaScript inside Drupal and in terms of upgrade a test will be something that could be very very helpful for example CK for itself we are releasing bug fixings very often and it's very important for Drupal to have it inside on every single release so I believe it's very important for you guys also to have a good set of tests on the libraries that you are using for the things that you are using from those libraries for example even jQuery you are not using the whole jQuery thing and you know if you have a set of tests for those things that you are using on jQuery then on the new jQuery you just run your tests and you are fine on upgrading and this is for jQuery for CK as well as for any other thing so this kind of test may be very helpful on the maintenance of Drupal in general as well that's a very good point actually I was going to do that manually and go through the bigger country module and see that they don't break when we upgrade stuff but you know if some script can do it, that works for me as well that's been a painful process so far upgrading jQuery chasing head in Drupal 8 has been a manual but we don't evaluate anymore so that's fine stories we'd love to hear like you've you implemented a test suite and it didn't work or you know you had to change gears or anything like that you know it's early days in terms of front-end testing in Drupal I don't believe that the system we have is the one we want to end up with I think it was our learning projects and we've learned a lot from it so far but if you have any other questions about you know something unrelated who here has ever written a test in JavaScript that's not going to work yeah can we get you on the microphone yeah let's get you hooked up so this is the CANJS that you were talking about JavaScript NDC does anyone have an HDMI to UVGA no we can do the soft set they do that as well now they do that as well now yeah so absent of questions and input I guess what I can say is you know we have three JavaScript maintainers at this point I think most of us are involved with building out features for the most part writing tests is something that we end up doing in our spare spare time which is between those hours of like two and five in the morning and Ruben over here has been extremely helpful in becoming a co-maintainer of the FAT module and just running with that and I have to apologize for him for all the patches that you haven't reviewed yet but there are my list of things to do Ruben would be a great person to mentor as well you know within that queue of the FAT module there are many very small scripts in Drupal Core that need five or six assertions to just tell us whether or not they're broken you know something that as a novice JavaScript developer it would be very easy to get involved with and posting messages to those project queues is the best way to get our attention to jump in and ask us you know where do I start next so I have the questions I'd like to ask first of all for new JavaScript developers who are interested in getting involved or experienced JavaScript developers who might be newer to Drupal how can they get in touch with you so just posting in the issue queues and are you going to be like are you going to have a table on the sprint on Friday wow that is so interesting I have a slide on that frog is terrifying while Jesse is finding this crazy slide I'll ask my other question which I have thoughts accompanying it which is how can I'm a JavaScript idiot I can't understand it but how can the core process help you get JavaScript coverage for core examples of things that we could do that we've talked about doing are things like simply when people add JavaScript functionality asking for a test or even just a test scenario things like making, running the JavaScript test part of the testing gate for patches that affect JavaScript I know that actually with Webchik we kind of agreed on whenever there's a JavaScript patch anyway so there's not enough people in the queue and so then another part of that is running so that's like one part is test scenarios even if they're just English language scenarios Gherkin is the language something that people who aren't JavaScript developers could do because I have no idea I just have them in the recording it's Europe, it's alright that's one reason to me the JavaScript is just a barrier but I know a lot of people who would like write scenarios and then getting people to transit those scenarios into JavaScript is a second problem but the other part of the question though is like we saw the tests you showed us the test that we currently have is broken into a bunch of places and either those are regressions in core or those are tests that need to be updated for API changes or whatever and so part one is I think that we should at least run that test suite whenever we commit especially any kind of major JavaScript change and if that's not document on the issue I've been pushing for a long time for that not to go in, that doesn't happen unfortunately but if you as JavaScript maintainers wanted to start asking for that you've already asked that people ask you to review them that would go a long way I think toward getting people to do that even if you don't want to make it a blocker and maybe it's worth having the conversation about whether it's a blocker I mean that's why we want to have a project manager on this because he would what I hope he would do is is kind of set the process on how we should integrate testing into the core workflow we have that doesn't really exist in JavaScript yet anyway and organize that because you say that to me I agree with you but I have no idea how to enforce it so here's the thing is that I mean this we need to we're losing time now like all the time that we spend until we get a project process going initiative thing we're losing we're losing regressions we're breaking JavaScript in core all the time and that adds a lot of things but right now we already have a process for blocking changes in core for PHP tests we don't commit a patch that breaks a PHP test we fix the PHP test and whether it's because of regression or not but the JavaScript suite isn't in core the solution is to run it manually so what I'm asking when I'm positing is it a reasonable thing to do to ask people to run that test suite manually you've seen the result of a test it's broken right but what I'm saying is obviously first we need to fix that but even saying is there a new regression if we had a simple way to determine if there was a new regression against the known state of head manually until we have this done automated running of automated testing is that worth considering and I'd love to have that and I'd love to have that conversation with catching Angie and stuff because I feel like there's a lot that non-JavaScript developers can help you with that's not being done right now just because no one's saying do it the bit that I think you went through very quickly there was no no I mean pejoratively is this writing of the descriptions of what the test should be so if there is something like Gherkin or more if it's a common language that we can just use to check in with the patch so that we have a sense of what the test would eventually be when we write it we at least aren't losing the time that we have now to define them so we have a sense of the scope we have to get to eventually like if we decided to use bit hat in core and Gherkin then we couldn't commit Gherkin files without the coverage and then when we have everything behind it and things running then if they fail we might have to take them out again or something but like there's no reason not to put a text file in that describes the test in anticipation that it is going to get run and later why not those would work for me would that work with a seek editor path like would we be working yeah and so the first step that I think is like there's probably like specific vocabulary things we need to define and I think that for I mean the people the people who have been talking about had at this conference like Taisler has already done work in that area Taisler for like the things that are Drupal specific like a common I don't know what I'm talking about Taisler is someone we should talk to okay we'll find that person cool anyone else have questions, comments but the stories thing I think is very interesting and I'm kind of sad that no one was like hey I have a story and also like what would you what do you expect out of this session that you didn't get because we still have like a couple of minutes and maybe you can address that so you guys have no expectation whatsoever yeah it's not an expectation I think just to understand you know I know that this thing should be ready yesterday but you know do you expect this thing for Drupal 8 or is this more a future? Depend on how many people volunteer for that because I don't have that much time to spend on it even if it's really important and it's a matter of I mean really the JavaScript issues well the main issue in Drupal is that we don't have enough people it got much better since a couple of months but still not enough still too many patch to review to write you know test even in in English so if we add a new big project on top of that I don't know when it's going to be done hopefully soon the cool thing I think though about testing is that it's not something that we can add after an 8.0 release no problem right? and we're all really nice we're nice people so if you want to become a better JavaScript developer there's no better way than to like put code up and we review it yep I want to share my experience with the frontend automatic testing module because just I landed I just found the module because in one issue we break the toolbar so I noticed that somebody says we need test for the toolbar and just I found the frontend automatic testing module and started to write the test for the toolbar I just increased my skills of JavaScript that's only writing a couple of tests so I guess for non-experienced JavaScripters it's a nice change to start because I'm not fronting but I started to increase my skills and only writing tests so it could be nice thanks more time for the question just by coincidence I saw there's a bunch of JavaScript developers in here and I thought this would be the right place to come with this little wish so I do CSS and I don't do JavaScript and what always happens to happen in my themes when I begin to play around is a clear separation from the JavaScript and the markup and the CSS so it could be pretty, pretty, pretty please make a couple of tests figure out if we could use the data attributes instead and remove that whole idea of having class names in for use for hooks for JavaScript for 2.8 it's kind of like because one thing I've heard every time I've set it out loud people are like no it's slower and I don't yeah there was a blog post that came out like yesterday it depends it depends what browser and stuff use opera it's very fast on opera that's true he blocks opera we have that now anyways it's a wish for the not so technical front-enders who like to do pretty stuff we can separate the stuff so we don't kill things or at least make sure that we're going to have some kind of a prefix more than don't touch this class so you'll break views again yes the mothership was going on for almost a year and broke every kind of HX call views did tada no we don't have time anymore you might be able to do attributes for things that don't repeat so page template type attributes but then when you get into views you do want to use classes because then you're potentially printing out like you know a hundred or a thousand rows or something like that and then you'd want to use classes just because they are faster right now and then we could you know revisit that you know during D9 snuggle or something I love that yeah I got really sad when I saw that I was like go I hate you guys I I'm I guess we should wrap up because it's the end of the session I should have any more question we are around this afternoon tomorrow and feel free to you know come by and work on stuff thanks thanks and your music make sure you have like a ball of clava wrapped around your head yeah it was actually for music