 Next we have is we're going to try and do a fishbowl type panel where we want to kind of get the answer. A lot of people have been asking, like, what's the future JavaScript framework? Like, what should we, if you're building a new app today, what should we be thinking about? Which one to pick? What recommendations we have? And I don't know, as John pointed out, if there is a right or wrong answer. But what we would try and do with this panel is try and see what different people have opinions about and what they think, you know, you should use Ember, you should use this, you should use that. And here's the reason behind why I would suggest you should use this. So we're going to open it up. Anybody from the audience can jump in and kind of start giving their perspective. But I would request if four people can come up and seed this to start with the discussion and then more people can come in and we can rotate people through this. So do we have any four volunteers who want to come up and try and take a shot at answering what is the future of JavaScript web frameworks? Good. Two. I'll do it. John, three. I'm already mic'd. This is so easy. We're actually going to do karaoke now. Making the rules, one chair is empty. If anybody else from the audience wants to answer, they come take the chair. One of you will have to leave and that continues at any given point in time. One chair is empty for someone to come and take the chair, all right? What, oh, so we're, how's this start? So I just make your opinion and I disagree with it. Oh, well. Okay. I thought we were friends. No. So me and John think very similarly. So I consider the future of JavaScript to be isomorphic JS, obviously. So rendering the state of your application on the server side using Node.js and hopefully sharing some of the logic that you've built for your application across the server and on the client. There isn't currently a lot of frameworks out there that provide this sort of support. We're getting there. Ember is working on it. Tom Dale wrote a blog post a couple of years ago about progressive enhancement and sort of referenced the work that they were going to do with Ember. But yeah, the future of JavaScript frameworks is probably this kind of work, this kind of logic is going to get done for you. So you won't even have to think about it. There won't be a server anymore. You'll probably just wire up endpoints to an API that's going to be running Go or Python or something that's super performant for actually crunching data. And that will be an API. And then your web server will be in Node because you'll be able to share the logic of your application on the server. So one of the implications there is there's going to be a web server actually, so the web server is the thing that serves out HTML and CSS which is going to be your Node.js app which is isomorphic. And you're going to have the back end server which is going to use the same APIs that the Node application uses as well as your React application uses so that it can be isomorphic to do that. So wait, do you agree with me? Do you have the stage? No. Yeah, I do agree with you, but that's like a shift, right? Now, so you're going to have all these problems with, so one of the things that I face is the Node.js app currently is doing all these nice things with the database and things like that. Now, I have to write an API endpoint as well as the isomorphic rendering part. You should be doing that anyways. Yeah. Amazing. You should be abstracting your data from here. But I think this is a step in the right direction because a lot of the closest of the community around OM is also going in the same direction. React, of course, has been the pioneer of this and I mean there are newer languages around functional programming like PureScript which are also trying to do the same thing. So I clearly agree that's the way forward and I mean it's going to be interesting. I mean disagree, actually. You don't disagree. Yeah. Yeah. I do actually disagree. So I see JavaScript moving into a future where nama crunching isn't just, you know, the property of Python and R and Go and all these other languages. But what I also see is, you know, all these server-based applications running inside the browser using platforms like Vassim or Native Client, there's going to be a time when machine learning will not just be a server-side thing anymore. It's going to be running within Chromebooks which today seems impossible, sounds impossible. But it's going to happen because we are moving in that direction. So yeah, I do disagree with you over there. I think this is going to eventually come up to the stage where the reasons why we disagree are because we all see different niches of the future because the future is actually gigantic because the world is gigantic. And that was good for keeping all the programmers and programming. It's true. I wonder though, so I would have not, especially now since WebAssembly, although again very buzzwordy and extremely new and bleeding edge, I would be much more of the belief today, maybe not six months ago, that it's not going to be Native Client that does something like that but rather when WebAssembly does diverge from whatever is currently supportable and is performant enough to do that in a way that we don't care anymore because we're not using browsers that old or we're not using pages that old. I don't know where that's going to end up somehow in the world. But that for me is going to be the future with respect to performant calculations in a browser. One awesome thing about the JavaScript community is that there's goal A. There's going to be three different ways, three different projects, three different teams who are trying to get to the same goal in probably using different methodologies, different thought processes. So at the end of the day, someone is going to end up reaching there. We just don't know who. And that is something that is probably missing from a lot of other different ecosystems. So that is one thing that hopefully is going to stay. So for instance, you know, the whole debate between Native Client and WebAssembly, well, it's two different ways to solve the same problem, but somebody is going to get there. And at the end of the day, it doesn't matter who gets there, somebody gets there. JavaScript will get there. Firefox OS. Always better on JS. Always got on JS. Always better on building their solutions, you know, for analytics, big data, stuff, Microsoft. I mean, will they see that as a vision where you are undercutting their whole economy? Are you talking about like proprietary logic or something like that? You can still, you can still abstract away, you know, if you're talking about a game where you're doing something interesting with data on the server side, you can still lock that down, that logic. But when we're talking about the future of software, I imagine, and this is something I've said for a long time, I imagine that all of our devices will eventually just be windows to the web. And application is just the web app. Because it's just going to get to that point. JavaScript is the most ubiquitous language in the world. It's in every one of our devices. There's a JavaScript engine in every one of our devices. And it's got one of the most performant, you know, like the JVMs have been, you know... I don't know. JVMs actually mean JavaScript VMs. It used to be something else. Yeah, yeah. JVM still means JVM. Yeah. But essentially they, like these enterprise companies or these big companies need to find new ways of offering something to their users or their customers. And usually it's insights, analytical insights. And there's something proprietary about that. So they have to get kind of progressive about their business model. They can't just sell software anymore. But they aren't doing that, you know, right? I mean, Microsoft is not doing that. And they're falling behind. But I also think that the... But this didn't make billions. The markets that we are talking about, this is where the future is just gigantic. The markets we're talking about are completely different. The people who are going to Microsoft or working with C-Sharp and .NET to build a web form application out of the box are not the same people that are going to be considering, one, the development team, and two, the costs of a node application that has isomorphic JS that's building react applications. These are not the same markets at all. So I don't know if I feel like they would ever think, but it's not in the near future that we were tromping on their toes because they're not the same people on... But I mean, one instance is PayPal that's moving all of the Java-based apps to Node.js. You know, Douglas JavaScript, so it works for them. So that's one. I know for a fact, SAP... I don't know, anybody from SAP here, Bangalore? SAP Labs, Bangalore? So I know for a fact they are doing a lot of stuff with Node now and moving some of their applications out of Node from Java. Well, it also depends on how far in the future we're looking because eventually we'll all just be cyborgs and robots and so it won't even matter the web. I was thinking like 100 years maybe. Yeah, 100 years, yeah. I mean Elon Musk thinks that there's going to be artificial intelligence. You become a cyborg now and you have to get a pacemaker? Yeah, a pacemaker. That still makes you. I think the pace of change around us is so fast that I think it's impossible to look one year beyond from now, in my opinion. In one year we don't know what's going to come up. At least that's the kind of state I live in. So I was thinking future as in maybe the next one year. If I'm planning to start a new product development, what are the technologies I should be looking at? My choice right now would be React and Node.js and Tecmoset. I like Ember, but yeah. We agree too much up here. Yeah. I disagree. It's going to be Ember and fast boot. I actually do think that's good. And Glimmer. I would actually go for famous. I would look at famous. Famous is the future of really interactive UIs that look good and perform really well on different devices. And because famous and Angular are so well connected, I think Angular is something, even if you're into React, Angular is something you really need to keep an eye on. And Node for back in that, I suppose that goes without saying. Can we have Alexi to talk about why he disagrees with everyone here? Any disagreement on stage? One point I have to make for the statement. Microsoft is changing its strategies. In 2016, SQL Server 2016, they are supporting JSON. They are building document, which actually support JSON. So it is changing its strategies towards the JavaScript and corporates are changing as per their needs. Hey, guys. I guess they wanted some different opinions. Sorry, I got caught up in the dessert line out there. Before I say anything, could you re-save your original question? I was like walking up here in a hurry. What is the future of Java? Why you disagree with them? Basically, that's the question. Why you disagree? Well, I have a way I disagree. Yeah, so my original question was what's the future of JavaScript frameworks, but I think the panel decided to expand it a little bit more, which is cool with me. It's now the future of Java. It's now actually the future of web development. We've been talking way further than that. We're basically saying stop writing Ruby, start writing Node and isomorphic. You take a more stronger view on that. I'm going to give you an answer, but I'm not sure if the answer was the one here. You can't really state one framework is going to win out over the other. I say that from... If you were here for the CanJS talk, we showed the graph of all the different frameworks, and I hear this argument, this debate, what is better, CanJS or this? And I've heard that debate for the last nine years. That's how long we've been around. It really comes down to... There's a lot of frameworks. There's going to be more frameworks tomorrow and next year. There's going to be a bunch of frameworks coming out for whatever reasons, whatever different purposes they're trying to solve. A lot of them found on this concept of theory and academia. This is what we would like to solve. The only thing we provide, really weird try to do with our framework is what are the problems you're facing practically today? Really what I see throughout the frameworks is a convergence versus we're all going to have different opinions, but we've already seen a lot of the framework start to start moving in the same direction when the web components spec came through. Immediately we all said, hey, there's a declarative approach to how you can throw modules together on the web. Everybody has their own declarative syntax these days. CanJS has components. Amber has components. Angular is really the only components. And React has JSX. It's a declarative way to approach things at this point. But even behind the scenes, little by little, it's really, I agree with John's statement a second ago, it's approaching web development moving forward as opposed to picking the winner. If that makes sense. I know that's a very great answer for you. I thought about something that I sort of, I don't know if I disagree with, but I think it's a nuance that might be worthwhile. There are situations now mostly for short-term applications that I have been much more interested in not having a back end at all and looking at the parses and what's the other one called? Firebase. Parses and firebases in the world. And I've only used parse not firebase. But I think that they will become much more ubiquitous like Yoroku is now that right now they are not such that we won't have to necessarily have a back end for most of our applications. Especially as front-of-developers, we don't necessarily want to delve into the type of, not even necessarily. I don't want to see the jQuery as an API. I want to see it as a language. I don't know whether there is any library such as the file system directly to the jQuery. And another thing is, I don't want to tell directly the database like HTML, HTML, 4G, HTML directly to the jQuery. Is there any song? Is there any JavaScript languages that we own? The question was, is there a JavaScript library to directly access the database? With jQuery. Well, I mean, I'm sure there's a few jQuery core contributors faces to see around the room. Maybe choosing the right tool for the job comes in a question here because jQuery at core is to manipulate the DOM. It's a simple library to help us change how things get on a web page versus how something comes in a database. You can choose now to get an employee, but do you want an API like jQuery? Yeah, let's put the mic around. When you say API like jQuery, do you mean like a fluent interface over adding query pieces of query? Yeah, something like that. So there are ORM or query helping libraries that allow you to, not with jQuery, but allow you to change things that look like jQuery. Okay, from the web perspective, PHP is directly touching to the database and file system. Can we integrate PHP and jQuery in the road map? Directly jQuery will only touch the database like that. Off a Node.js will allow you to do that. It will allow the file system also? So in Node.js, once installed on your system, you can consider like the Ruby executable or the PHP executable that can make system calls and interact with you. Only JavaScript will help. All right, I'm sorry I need to cut this out because this is going in a completely different direction. I thought you wanted to contribute something to what was discussed, not go in a completely different direction. All right, so I'm sorry. But we do want to continue on this if people have specific questions about a particular framework and why it's better and you want to talk about that. Sorry about that, but that's what the focus of this panel should be. Yeah, that question was asked, and I think my forehand shot up at the same time. So you talked about the front-end data. What are your top three offline databases that you are coming for? Are you talking about Parse and Firebase? Yeah, something like that. I only know Parse and Firebase. They all integrate with all the frameworks. Can you just repeat the question? Oh, sorry, so the question was, do we recommend any one of these third-party or these cloud storage APIs that you can essentially store your data in the cloud and you just pay a fee and you're not handling any of the data, which is awesome. So like Firebase and Parse, there's some other ones like that. I think he was asking more about the in-browser, like index DB sort of thing. You should check out PouchDB. Sorry, it's PouchDB. PouchDB is like a CouchDB in all the queries and stuff like that work there. And it's a good fit for in-browser databases. Okay, that's good. That's actually open. I have one word. Ooh. I'm personally not a big fan of the Web Components spec, and I know this will probably bring up debate. I don't like the Shadow DOM necessarily, and I think there's a lot of work that was gone into the standards bodies, like the Web Components spec that Google helped work on and the Polymer team has been essential to that. I don't like it for a number of reasons. I don't like Web Components for a number of reasons. One of the biggest ones is obviously Shadow DOM. And essentially the problems it solves, they're not problems. If you have problems with encapsulation of your JavaScript code right now, you're doing a bad job as a developer. And if you have problems with style encapsulation, again, you're doing a bad job as a developer. So I think that for us to trade the ecosystem of jQuery plugins to go towards Web Components, it doesn't solve any problems. So it's kind of whatever. Polymer 1.0, I mean it's just another framework. I think it comes with a lot of really useful tools. So I do think that people will get use out of it. The implementation, though, of Web Components, I don't like. So yeah, I'm not sure if anybody else... As far as the implementation goes, I'm a little indifferent with Polymer. What I do find really interesting is you have two major frameworks within the same company, Polymer and Angular. And the teams do communicate with each other. Angular takes a lot of Polymer's lead because Polymer eventually, at some point, there's going to need to be some convergence between the two. If you're familiar, if you're from the Rails community, this was a big thing with Rails 2.0 and Merb for those who really want to go back in the day. It's going to be that kind of concept. I find that's going to be interesting with how they're going to merge these guys. Maybe I'm a little bit more go with the flow. I don't think too much about whether or not I dislike specs. Maybe I should develop opinions. I just kind of do what I'm told, I guess, in that respect. But I find that more interesting. What is the future of Polymer and Angular? Yeah, they've added a lot of plugins or essentially a lot of the material design components they've added and given you for free. So it's kind of like a jQuery UI competitor, almost. And again, the fact that there's the Angular team, there's the Polymer team, and then there's DevRel. Although they do talk to each other, they do have different opinions on certain things. The DevRel team will tell you that you should be concerned about page load performance and time to glass and that mobile is really important. And the best way to get that optimal performance is to do server-side rendering and not to have a single-page app and rendering in the client. So that completely goes against Angular's current implementation. Wait until the package can render the view once you can execute JavaScript in the client side. Those are completely different opinions. So Angular sort of doesn't care. They sort of don't care about this thing that the DevRel team says that developers care about time to glass and it's a better user experience if you can ship HTML right away. So this goes back into the isomorphic sort of ideology that hopefully eventually we'll be able to be basically just shipping HTML code from our JavaScript applications that were executed on server-side. Actually, this is on a tangent to mobile. But very interesting. So I think one of the things that's missing in the framework or library space, in the framework space is to let us build good offline-enabled mobile web apps. Right now, I mean, you could pretty much, I mean, write your manifest yourself. You could do all the offline and all that stuff. But it makes it really hard. I mean, there's a lot of boilerplate to do to get it right. I mean, I think React is a good first step that you can do isomorphic rendering. You can pretty much get all the data locally. You need to have a good sync adapter. I think something like GraphQL could help in having the data in the same format on the client as well as the servers where you could kind of, you know, make sense of the queries both on the server and the client-side. So those things are in the right direction. But I think, I mean, if there is to be a framework which would drastically change a mobile web app development, I think something like that would be the thing. That's actually a really good statement. And here's my controversial point to the day. I think this is more, this is a huge impact. This is one of the biggest things I think I noticed when I first came to India. I know right now there's tons of commercials, YouTube, now with offline feature, that kind of stuff. It's hard when you prioritize development and frameworks. I'm gonna just recite some of the sentiment from my colleagues. We're not headed towards a world of less connectivity. We're headed towards a world of more connectivity. So asking a major company or team, especially smaller teams, that are building on those frameworks to focus on offline is, it's gonna be a struggle. You're talking about, you know, KANJS was in development for a long time. Angular was in development for four years, five years at this point. I had Wi-Fi on the plane to get here. And as we go forward, even India's huge infrastructure here in Bangalore over the last, like, five years in terms of connectivity, offline is starting to becoming less and less of an issue. There was a great, there was a fun, not great, but there was a fun article in Tech French in last month talking about Americans who were testing their software, the Beta Mobile Software app in Seoul, South Korea. And they said, hey, how do you view this in mobile? And the response was, where else would you view it? Because they were not used to the concept that Americans are even used to, where we have to check something on the desktop because maybe you don't have Wi-Fi connectivity on your phone because they're so connected. So if you know the future is connectivity, how do you prioritize offline when it's a shrinking space, basically? I'd be the US, and I think the US has more connectivity issues than India has, actually. So I couldn't get phone signals in my apartment. I didn't have Wi-Fi, but, I mean, you get the point. The point is, it's not about, it's the first app launch experience, actually. I mean, that's why these apps are amazing, because they launch, they show some data, and then they can connect and they can get the other data. I mean, there's always this latency which kills you. Now, with mobile, I mean, given that the mobile web experience is pretty bad now, mostly because of the ads and overlays and things like that. But even if you have to build an app, I think offline becomes extremely important because you want to be able to quickly display something, have those actions that are, I mean, I'm sure there'll be connectivity. I'm sure there'll be all these things, but the first pixel to render has to be really fast. I'm definitely biased by not really understanding statistics very well and being in the subway population of New York where I am offline for a lot of time. But for me, the difference would not be that I'm always online and offline, but rather I don't want to pay for things when I am on... I don't want to pay for so much data. I want to be able to cash everything I want to cash. Service worker. I find apps that let me do a lot of things while I'm on Wi-Fi to then be able to go off. And you're right, I don't think there are any... I don't know about should framework prioritize this or not, but I would love, like you said, to have a framework out there that out of the box did some of these things for me. That would be great. I think someone had their question been waiting for a time, but what do you think about the future of MeteorJS which has like front-end backend and database management? MeteorJS? So socket connection? They got 20 million dollars in funding or something. They're totally good. I don't have a very strong actual... I also don't really have a strong... I used to think that there was... I used to have a concern about the socket connections. And it's not so much anymore. Is there a... Do you know when you jQuery folks, do you know if there's a limit on the socket connections? I think maybe they would have to... They must have to do some work. Because imagine you have a website that has got like crazy load and balancing on it. You probably have to distribute like the number of note servers. I'm wondering... Okay. So my only concern was socket connections, but Meteor seems pretty interesting project. But again, with MeteorJS, they don't ship HTML. They wait until you can create a socket connection and then... They also don't use NPM, if I remember correctly. They have their own packaging idea. Which is different. Does anyone in this room use Meteor? Okay. Cool. I would be excited to hear from you. Come over if you have some experience to share. I've just developed a to-do app. So I just wanted to know like how is the future of it? Might be the wrong crowd to ask. I would say again, if they implement all the things that I talked about originally, that my original opinion on what we need, if literally there's a framework that encapsulates that whole process for you and you don't even have to think about time the glass and you don't have to think about shipping HTML for the initial page load and then essentially something that just encapsulates the whole experience of a web app. So one thing I didn't like about Meteor was MongoDB. So it has this opinion about using MongoDB as your primary storage. You can check out ShareJS actually. They are a little more friendly to the rest of the node packages. They are on NPM. You can actually use a part of ShareJS as a part of your bigger Express project and they use the same operational transform library that the Google Wave initially wrote. It's very performant actually. So I would recommend ShareJS over Meteor. I'd give it a short, I mean give it a try. I think you would like that more. Actually I'm just curious to kind of quickly go around and see how many JavaScript frameworks people have actually used, just kind of get a count of the frameworks that we have here in the room. You mean the ones that we used last month, this month or overall? Any time. Any time. Like what JavaScript frameworks, not libraries, JavaScript frameworks particularly, you've used in the past or you're currently using. Let's kind of try and get a quick count. We'll go around, we'll see how many people. I've used only one framework, Ember. Ember, okay. Everything else has been library because even Angular, I consider it to be a library than a framework. The equity is a library. I think we're grouping them all together, but I agree with you. Angular though is, I mean they do claim in some places it's a framework, but yeah, I do agree with you that it's more of a library than a framework. Durandal is a framework. Durandal is a framework. I've used Durandal, it's built on knockout. I've used that, yeah, I've known two frameworks because that has an opinion about how you structure it. You require JS and your routing and stuff like that. So I've used Durandal and this one. Two. You want me to list them? What frameworks have you used? I think Candios goes without saying. Angular, Ember. Oh my god. We used Durandal a little bit, Backbone. I mean we have to use them because we compete with them. But yeah, it's good to know, it's wise to know the ways of one's adversary, but it's good to just see what other APIs look like and what are people doing, why are they choosing those choices. So we try to be objective when we're bringing this stuff to light. And if there's a good idea, if it's a good idea we're going to want to put it in Candios as well. So we try to be as diverse as possible. So would you say Candios is a library or a framework? Neither. I mean, yeah, it really is just semantics. It's a tool to help you complete your job. If you want to call it potato, that's totally cool too. Potato, okay. That's your new tag line? Potato of the lab. I know I'm really good at marketing, right? I've used Backbone. It's like my primary go-to. I've done Ember and Angular as well. I think I might have a long-time go-to like spun up a meter JS demo, but just to check that out. But yeah, that's it. So in terms of what I use on a regular basis, it is Ember, Angular, Backbone, React, I suppose. I'm going to gloss over there. We're all going to go with potato here. But I've also used a lot of YUI 2.8 and 3.0. Not recently, but I have. XJS, Pre, whatever, sent you a tookover. Not recently. And then there are dozens of what I very affectionately call framework, John Paul's fancy things on top of jQuery and prototype, which had a lot of bugs, but I was still very proud of it at the time. So I'm going to call that. So the count is 15 so far from what I've heard from all of you guys. Is there anything else that these guys did not cover? jQuery mobile. Mobile? Oh yeah, I did that once. That's 16. Anything else? Dojo, 17. Yeah. Light. 18. Motu. Prototype. 18. Prototype, 19. Scriptaculous. Motu. Were we talking about libraries? Yeah, it kind of went off into libraries land. And I just thought it would be good to bump up the count. What is a framework? I mean, what qualifies as a framework? It's potatoes. So the way I differentiate this is not a framework. What qualifies as a library framework and a potato? For me, I don't try to differentiate between library and framework, because the argument just goes on forever. I care about opinionatedness or not, because I prefer that my personal preference is opinionated things. Like I enjoy Rails, I enjoy Ember, because I do not have, personally, because I do not have to make decisions about this stupid thing. You don't like coding is what you're saying. I don't like coding. You don't like development. I'm lazy. I do not like developing. Why are people so scared of writing code? Like, that's the problem. It's like, I want one method that says build website and execute that and it's like, that's everything. You got to, like, why are you so concerned? Like, at some point you're going to have to write the things that wire stuff together. I think being in a jQuery comp, I think it should be dollar, this dot build website. There we go. New method, dollar, this build website. There you go. And I came up with that by looking at Stack Overflow. The thing about programmers, the thing about programmers is that we are lazy and that's why we don't want to do too much work, right, John? Exactly. If there was a dollar dot build website for client or product and the computer would talk to the product manager, you would take it every time. If they did it properly, sure. I mean, there's so many caveats to web development accessibility and so many things. I agree. The reason I asked this question is because, I mean, I do agree that opinions are a way in which I distinguish a framework from a library, but I lean towards using a loose set of libraries and kind of a common way or a good way to piece them together because what that helps is that you can take out pieces of the library and then kind of evolve it separately. Now, the problem that I have with the Ember approach, I like Ember. So I've done stuff on Ember. I like the way in which their components work. I like the way in which the computer properties work. I like all of that stuff and I like the fact that they do routing and controllers and stuff like that. But the trouble I have with that is, I mean, frameworks tend to go on their own part of this package management. Meteor is a good example of that, actually. So they have their own package management. They don't play well with NPMs, sort of. I mean, Ember does pretty much the same kind of things. They have their own build system and their own... I mean, sort of... They have a naming that's called NIH. Not Invented Heur Syndrome. Yeah. NIH. It makes it very difficult. So the point is you come from a big frameworks perspective and Yahuda has been very proud of the fact that Ember is a framework and it's not a library and why he does that. I get that, but I think that's... that's kind of a wrong thing to do, especially because Ember data is... can be quite useful outside Ember if it were available as an NPM module, because that does exactly what the offline enable capabilities can do and all that kind of stuff, but it's tied very deeply into Ember. That's why frameworks are dangerous in modules. Yeah, we had the same... We had the same opinion. When we wrote JavaScript in BC, this was a while ago, we were the same way. It was like our way or the highway. Around 2009, 2010, we started to realize... I think it was when we started bringing on more people to the Tobi. We had the same thing. We wanted to break certain parts were useful. We wanted to use them with different pieces, so we broke it out into many different modules, so you can use them piecemeal, canJS. I think we even, like our tagline, we call it a library, but we are unopinionated or we try to be, because we want to provide you tools if you want to use canModel. If you guys went to canJS, talked to you, saw the quick abstraction demo I had. If you want to use canModel with rexViewLayer, cool. We wanted to give you the tools and however you want to break them apart, it's totally up to you. Most of what we do, I mean, you are going to have every library is going to make up its own abstract APIs. $something.boo, that could be cool if it's very useful. But we always try to strive for what direction the standards are heading. So we have our own module loader, Steel, which has been around for a really long time. And recently, we removed the guts completely out of it. That was a really tough decision. We say, hey, we have our own proprietary thing. The web may be moving in a different direction. Maybe we should rethink our stuff. I know that Kujo guys had the same opinion. They actually shuttered one of their projects over the same kind of concept. We were thinking about doing the same with Steel. We realized, hey, let's use, let's remove the guts from our proprietary loading system and let's use something a little bit more accepted by the community. So we rebuilt Steel in the past a couple years. I wrapped it around System.js. So now, again, if you saw the demo, you can write everything in ES6 modules and hope that when you write this application, if you had the demo today and you wrote it in ES6 modules, then tomorrow maybe you just remove Steel entirely and you rely on whatever is the actual underlying mechanic. So whenever we're developing our APIs, we try to at least give you something that's, it's not going to be future-proof, but we want to get you as close to that as we can. And we do take that something in consideration. I'm the same way. I like to wire things together because... Yeah, I like to code. We're not in the business of building small, simple, in-the-box apps. Everybody in this room is probably here because you work for a corporation that wants something very custom and very tailored to their needs in terms of branding, performance, or what widgets you're building otherwise. It's not something I would love to be able to go to every one of my clients and Google for their app and download it off the web. That never happens. So I'm in the same boat as you guys. What's your framework in a library? Let's try and pick on one of the Jake Wary guys to see if they have any opinions of what's a framework, what's a library. I think John Paul got it. Basically, I would agree that I think the degree to which something is very opinionated and limits the degrees of freedom is a good way to kind of measure the difference between the framework and the library. And I think you can look at that But how many of you out there write applications that are primarily consumed internally by some company rather than like a public application that everyone uses or quite a few people writing internal apps? There's frameworks, if you think about Excel with Excel macros, Excel is a framework for writing applications and you write code against the spreadsheet and it limits your degrees of freedom. So I mean if you look at a framework in that way then certainly Ember does that. It does it for the effect of being able to prevent you from having to make all those decisions and hopefully guiding you to what should be the one true way of getting things done. I think there's some tradeoffs in doing that though because then you can't mix and match. So it's the difference between a notebook PC and a desktop PC. With a desktop PC you can put any power supply, I mean you've got modularity, motherboard power supply case, you can mix and match but when it comes to notebook computers you can't do that. Interoperability goes up a window, you know. So traditionally I mean when we think from a language point of view the main difference people talk about in framework and library is a framework is basically in control and it calls out to pieces that you extend which you customize and it lets you do certain things but it is in charge of the life cycle while in case of a library basically you are in charge, your code is in charge of the life cycle, it calls out to the library to do specific things. So for me like jQuery is a library where I would call out to it to do specific things and get back. I'm going to blow your mind though because what you just described is a browser, right? Like the browser is a framework and it just calls back to us and then lets us do our stuff. So the browser itself defines all sites, all sorts of limits to what we do. So I don't know, I've seen, I've heard that before and I agree with some extent but you can write things that are libraries that do the same, fire events that you listen for. I mean React is not a framework but React does many of the things you just described. Okay. So can someone repeat the question so everyone can hear and then we can… I'll take the first question. You want to take the first question? Yeah. Okay, good. So what's the right IDE to be using? Well, I don't use these two but like if you want to be like a legit programmer you better be using like Emacs and Vim and like I personally use like Sublime Text. Yeah, I'm just like I'm a designer. Yeah, like I don't develop. And I'm the one who doesn't like code. Well, I'm just saying I still do develop but Sublime and Adam seem to be the big thing that everybody's using. Adam's got just hit 1.0 release and they've got a ton of awesome features. I think it's running. It used to have React in it and it's basically completely built off web technology. So that's if you want to be really meta, if you want to be like building websites or you want to be writing JavaScript code in something that's running JavaScript, I would say use Adam. Sorry. Or brackets? Or brackets? Yeah, I guess. Yeah, brackets as well. But yeah, I think if you want to like up your game, you got to go to Vim or Emacs. And then you just like constantly like. Just Vim, not Emacs. Okay, Vim. Whatever, man. Where's the photo? Fine, Vim. Okay, these guys are getting on my back. But yeah, I would say that's great. So the second question was about the built-in regardless tools that they have now, which are pretty advanced, especially Chrome, where you can edit things, you can map it to source on disk, and essentially you can treat that as your development environment. Well, you used to be able to do that. Now, of course, since you're transpiling to something that's angular that goes through about 15 build steps, you can't do that anymore, right? So just about the time we got to the point where we could do what you described, which is you could take the source file on disk and even if it's been served out to a web server, you could still edit it. Now what you're editing is essentially the compiled down, compressed, non-usable source code. And even with source maps right now, the source map, in fact, is so primitive that there's a lot of things you can't do with it. And in fact, there's more work being done on the source map aspect, but comparing it to the work that I've done, say, under Visual Studio, where they have essentially a source map, but it's like 10 times better, we're nowhere near being able to do what we were just able to do before we started screwing it out. So we've got to get all the way through this whole process over again of being able to figure out when you see a line in the debugger, how does it map back to what your original source said? Don't you think using a debugger as an active back-end? That is controversial. No, I did not. Years ago, I used to think that too. Like when there were problems, usually it would dump core, and I would look at, you know, it would say, seg fault core dumped, and the most I would need to know is where it died. And then you go back and look at the source and you'd say, well, it's got to be somewhere here, you know, and you change it and you run it again. You know, eight times out of ten you'd be right, and the other two times you'd have to sort of stare at it a little more. But no, I don't think it is an anti-pattern now. I'll change my mind. This is a problem that WebAssembly is going to run into as well, right? Essentially, like the compile code and source maps, like the support for debugging code. Yeah, and there is work being done on better source maps, but it's not there yet. So we really... Who knows how long it will be before we get back to the point that we used to be at. It seemed like we were so close to Nirvana. But... Well, there's still a lot of projects out there using vanilla JavaScript, but they occurred to find out to die early. So close to Nirvana, but we didn't get it. Oh, I totally get now. I just... I was like, that was really morbid. I was like, why is he bringing up... I knew him well, yeah. Looks like we are almost towards the end. We could do one more question if someone has before we wrap this up and open for the keynote. Coffee script. Yeah, I use coffee script all the time. Oh, yeah. All the time. I'm legit for years now. I've been using coffee script. The best. I don't... Who likes curly braces and semicolons and all this other... Get away. I love curly braces. I like mustard. Okay, I will not... We are missing the human lint, sorry. So my personal opinion is... I'm going to have to give up this battle at some point because ES6 has stole a bunch of the stuff from coffee script, but now it's like... I had this discussion with Chris the other day. We're hitting this weird... weird... weird moment where the transpilers and babble or babble or however you say it, it's still... I can't write code that's beautiful. And since I like stylus and I like coffee script, that's the way I usually go, but yeah, TypeScript and babble and all those, I'm not a big fan. I think TypeScript will be... The TypeScript team has already said that they're aiming to merge into ES7 whenever they can get them together. And ES7 has already got a type proposal, don't they? So the idea is eventually to migrate those to one through JavaScript. It just will take time. And I like the idea of having an optional type system. I think it really would help... even if not as much at runtime, it will help runtime, but just to help us as programmers understand what's expected, it helps self-document. TypeScript only a little bit, and what IDs can do with it is amazing. And I found that to be very useful. And also working on teams with many former Java or C-sharp developers that was very useful. So precisely because of my experience with Java and C-sharp development, I think it's a bad idea, actually. I guess I don't swing either way. I'm going to quote Jeremy a little bit when he was talking about coffee script when it first came out. This would be where the different approaches between coffee script and TypeScript. And what Jeremy was making is this is a different syntax than in terms of features of language. This is a one-to-one comparison with JavaScript. There's nothing they're adding additionally in coffee script. Now with TypeScript, they are adding a few different features. Dave was completely correct. There's the potential for a lot of TypeScript to be merged into the next versions of JavaScript down the road. But just be aware right now what the focuses of each are kind of are. That being said, I don't... I write in ES6 anyways, but I feel like I like it. Yeah, like... I have so many pins on this. This is terrible. So features and just compile to JavaScript. So I feel like ES5 is fine and I feel like that we're essentially going to hit this block where we just have to keep transpiling all of our code anyways and then we're going to be in the next two or three years. And it's a hard limit because it breaks... It's like syntactical changes to the language, which is an issue. You can't just polyfill that. You can't just be like, oh, do we have this API? You can't do feature detection for ES6 and like piecemeal out your code. It's not like that. So we're hitting this place where if you want to use Babel on the browser they'll support and then we're doing transpiling down to ES5. So I consider basically use whatever you want as far as type scripts, copy scripts, whatever you want, but just know that you're still shipping ES5, which I consider to be like feature complete. Otherwise you'll end up like it's the Python community with Python 2 and Python 3000 and like... I mean, I think there are still a lot more Python 2.7 programmers than Python 3 programmers even though it's been, I don't know, five, four years. Right? So this... I feel there might be a system in the community. Just a quick show of hands. How many people would like Java to be more strongly typed? Sorry. Java is already here. Java's too weak. Java's too weak. Quick show of hands. How many people would like that? Great. You should check out your script. You can do strongly typed JavaScript right now. So I kind of saw about 30% of the people put up their hands and about 70% of the people feel that it should be weakly typed and dynamically typed. I think the question you need to answer is how many of you are ambivalent or don't have an opinion? Not having opinions is also an option. No, that's because they can get into the gradual typing time for the... I mean, use something like Flow and decorate your existing code with types and that's going to get tripped up. So I'm going to go through a little bit about the background or a C-Shop background or one of these things. Seeing a weakly typed, dynamically typed language like JavaScript or PHP or one of these is very liberating. But I was just kind of getting a sense of how many people had an opinion on that. It's the Wild West, man. It's been a long time. In .NET 3.5, you've got the var keyword. So even in Java 8, you don't have dynamic variables as well. It's still type safe, but they're starting to loosen some of these restrictions as well. So I think even we're talking about convergence between the frameworks and our approaches to web development. There's a slight convergence between the languages too. Language maintainers are being less dogmatic in seeing, hey, what features are working in the strongly typed languages. We're all starting to borrow ideas from each other. So there's no nobody's found like the one language who's not going to be a winner out of this either. It's just what works. PHP for sure. PHP is already there, man. It's a winner. I'm going to take this in a different direction now. All right. I think we are about 10 minutes early, but we'll kind of try and close this panel. Oh, sorry. I have a highly technical question. Is this a quiz? Yes, for all of you. I already failed that quiz out there. I got 60%. And apparently the bar was 80%. And 60%. I only got two questions wrong, and they tricked me. They changed the wording on the first question. I'm not sure. And now we all know. All right, Scott, shoot it. Lots on comma first, optional semicolons, tabs for spaces. How do you feel about clubbing baby seals? Is this a Canadian-like thing? It's just an attack at my... It's a personal attack. And one bar. I do have an opinion on all of those things. All right, let's go one by one. Right? The first one, Scott. Comma first. Comma first, no. One bar, no. Semicolon. Yes for everything my own, typically whatever the author of whatever I'm working on. And what was the fourth one? Tabs for spaces. Oh, man. I'm all spaces. I do not understand. I'm all spaces. Spaces. So sorry to say that one more time. So it was one bar? Tab spaces, yes. Semicolons? Yeah, no way, man. I don't even have bar, man. Coffee script. But if I was doing it, it would be, okay, one bar, no. Semicolons, yes. If I'm actually writing job scripts. Comma first? No. What was the last one? You hit off one. Yeah, I'm going to need somebody to walk me through these two. Comma first, no. Semicolons, yes. Tab spaces. Tabs. Spaces are two bytes. What? Spaces are two bytes and tabs are one. Oh, yeah. My Dropbox is so full. Well, what was the other one? It was four, right? One bar. Oh, I'm kind of indifferent. The biggest thing I would say in all those is be consistent. Because if you mix and match, then it's terrible. Or double versus single quotes. Oh, man, that kills me. Oh, double quotes, always double quotes. What? I'm only double semicolon to make sure. Double versus single quotes, now that we have backticks. Yeah, exactly. For template strings, now you are... You've got to go double quotes. I know, but I only use double quotes when I'm doing HTML, like actual strings. All right, so one bar, no. Semicolons, yes. Tabs versus spaces, spaces. And what is the last one? Comma first. Yeah. Oh, wow, you're Comma first? Yeah. Do you guys know who got Comma first into JavaScript? It was Ryan Down. Oh, really? I did not know that. Where's he now? He let us Comma first and then ran away. Notice he hasn't been in the community in a while. He invited him, but he was kind of scared of this question, so he did not show up. All right, do you guys want to take that answer as well? All three. Wait, editor config is your answer, basically? Yeah, yes. Yeah, we might all have the same answer. So one bar, no. Semicolons, yes. Tabs, of course. Of course. And definitely not Comma first. And the way that you normalize all this is you get editor config for the tabs for sure, and colon re-tab to use it. All right, cool. I think we'll take a quick break. There is coffee already being served out.