Opening title Okey dokes.
So I'm going to call on stage, our panelists for this final session And I'll also invite participation from the floor. This is a conversation.
I don't want it so much to be question answer. It's more a conversation, that hopefully I will help shape, and I'm going to motivate it, about where it came from, in just a second.
But if I can get our panelists on the stage. So when we did this in Sydney, we had a different group of speakers involved.
Come on up.
Come on, don't be shy.
Up you come.
We had a different group, so it's going to be two different conversations, so, which is really interesting.
This is the one we'll be capturing on video, and so on. So, no pressure folks.
So you'll remember for today, Ben Buchanen. So who are we missing, Seb Mackenzie, here he comes. So Ben and Elice, and Alicia and Yoav.
So we've all heard them speak over the last, well, all today, as it turns out.
And, then Mark Dudley which I mentioned earlier. Founded LJS, well, didn't found LJS but has been running it for quite a long time.
I think everyone in Melbourne knows him, and should know him, and that wasn't what he and other folks there do, and elsewhere.
He spoke at our conference quite a lot of times. And I need to explain why, in part he's here, in just a moment, to put it all into context. And finally, Seb Mackenzie.
So Seb is actually someone I wanted to have at Web Directions events for a long time, because he kind of, he founded Babel, as a school project, or at school, when he was 17 years old, so I'm already feeling really inferior.
It's amazing projects that allows you ES6, most of you will know it, but it's born and bred in Australia.
Now lives in London and works for Facebook. And I thought, and then I saw a tweet about ten days ago saying I'm going to be back in Australia to go to Code, I thought this is kind of like Prince turning up at your concert, well, until about six months ago right? (laughter) I keep saying Prince, because if I ever was a musician, the one person I would turning up at your concert would most terrify or excite would have been Prince, right. So, Seb, so wow, if we had have known he was turning up a little bit earlier, we would have found a place on the stage.
But he very generously said he would participate in this, and I'm really grateful for that.
So that's who's here, and so why are we here? Well, at Respond, which was in this very room, in fact, all this took place in the aftermath of Respond, back in April.
Mark Tweeted this particular thing, he said I love progressive enhancement and all but PROLO without JavaScript would be JIRA and literally nobody likes that.
It's a trade off, right.
It's a bit harsh, and we've got some nice friends at Alassian.
So, I saw that and like, my ears pricked up, and maybe I was tired, or something, but no, it's got 83 re-tweets, and 171 likes.
That's pretty popular right? So here I replied, and just note the number of re-tweet and likes on this one, none.
And somehow I came out and snuck in there, I can't work out how, but it said, so if it's Jira or nothing, whose decision is it to make a trade off? And I guess my point was, well look if all I can get is Jira, or I can't get anything at all, and you really want me to get Prolog but I could get Jira, whose decision that is.
And I guess that's about the position around the web, and this idea of the web, and browsers are called user agents in standards land, and I've referred to that, I'm not sure in today's presentation, but the other day.
On the web, webiness idea that at the end of the day, progressive enhancements delivers at least some experience, if at all possible, to our users. So I called that out right.
So it continued, so Chris Wright, many will know, Chris.
Spoken before, he said he's talked about a forced dichonomy, I think he's agreeing with me here.
You can have Prolog experience and Jira experience, better than no experience, which I think is kind of webiness for me at least, right? And then Mark gets back, and a lot of people are scared of progressive enhancement because it seems so unrealistic, in 2016.
I think that's a really important point, that's sort of the heart of this conversation, or the heart of the start of this conversation. I disagree that it's hard, it certainly adds complexity and challenge for us, as developers.
It's this seeming unrealistic, and the word seeming, as (mumbles) would say, it's doing a lot of work. I know it's 140 characters, and I've certainly not going to get a phD from a minor American University in analyzing this.
So here's my position, basically I think people don't see it as important.
I think people, as in developers, often, and see it as hard to do.
So it's a bit of a trade off there.
And then Mark says We need to have this conversation in person, Twitter makes this a debate, instead of a discussion.
I think that's a really good point.
In Twitter you're sort of trading pithy bits, and if you don't know someone very well, Mark and I do, things can descend very quickly into, you know, a statement sounds very very direct on Twitter.
And it's obviously devoid of all, we know all that right? So, so that's what Mark said, and I said, agreed. What about a session on code, and here we are. So this is our Twitter conversation that took place over the first one was 9.56am, so 9.57am, so it seems to be going backwards in time.
But basically within a few minutes we came up with this session.
You can probably tell I'm getting a bit tired. The other thing I go, one of my business rules is, I don't actually even like panels, so we don't normally do them, but I really thought this was a great opportunity to do it, and it went well enough in Sydney, so this is our session at Code.
And I guess I'm going to start with where that started. And I'll say to you Mark, you certainly have the position that you love progressive enhancement.
Would you stand by that idea that at the end of the day, I guess you're talking about yourself.
Say you were building Trello, and if I did it in a PE way, some people might want to get JIRA.
Is that the decision you, or your decision would be well it's like, they got to get Trello or just too bad. Or is that overstating the case, or where do you stand on that? - [Voiceover] I guess with a lot of these sorts of questions it comes down to what it is you're trying to build and why.
So I talk about myself, with Trello, one of the reasons why it was so engaging is the things that it does that you can't do without JavaScript.
And so if you're trying to enter a market and say we're the new Jira or equivalent kind of product, maybe if you built it in a way that it worked without JavaScript, suddenly you don't really have a value proposition over your competitors any more. It's like Google maps versus was it Map Quest back in the day, where it was very slow, and everything was a trip back to the server. Sometimes if you want to get something out to market quickly, and stake your claim in that marketplace, it's about embracing the things you could only do with JavaScript, and maybe there's actually no value to you as a company, in supporting environments where you don't have JavaScript.
- [Voiceover] Or I guess there may be value, because of course you'll get a larger reach, and you'll get people who don't have devices, or they're using Opera mini or something else. But maybe at this time, particularly in the context that you're talking about, the impact on the time to market, is such that yeah it would be nice to have, but its' not absolutely critical to what you're doing. - [Voiceover] The thing with Progressive Enhancement there are definitely cases where you have to do the basic version first and then layer features on top. But then there are experiences where, to make it work both with and without JavaScipt, you're basically forking the code base. You're going to have a code path that's only if there's no JavaScript, and you're going to have a code path that's only if there is JavaScript.
And those are the kind of cases where it can be quite hard to justify now we have to be web zealots, and make sure it works without JavaScript.
So you've got to actually honestly ask yourself, why are we going to delay other things we could be doing. - [Voiceover] So I guess the word of zealotry is doing a lot of work there as well.
I personally try and steer away from identifying as a zealot, as much as I believe in the web.
But I guess what we're talking about in a way, is pragmatic decisions about engineering and product features, and the like.
I have my thoughts around this, but I'm emceeing so I'm literally trying to stay as independent from a particular position, as possible. I wonder if anybody would like to speak to that, and maybe put an alternate position? And someone who's sitting up the front, and I'd be very happy to give the mike to, so Marcos as we all know, been heavilly involved in doing the stuff at the W tree, at Mozilla and so on. I'm not surprised he's got some thoughts around this. So Marcos, what are your thoughts? - [Voiceover] I think it's, to have that, or set it up as that dichotomy where you go from no JavaScript, I think that's not realistic.
So I have to agree with Mark, that to a degree, you just don't have the dichotomy, so I don't think anybody starts with, we have no JavaScript.
So the way, coming from a browser vendor perspective, as somebody who works on standards, we assume that JavaScript is there.
So, the dichotomy's really like, what browser version, for instance IOS 8, and Safari, what web version do I want to start from? So you have, I think you generally start from that, and then do I want to progress all the way up to service workers, where you can still have a very rich experience.
And you know I have to go to this extreme, zealot position-- - [Voiceover] So it's almost like a straw man right? - [Voiceover] It's a true straw man-- - [Voiceover] Either all on, or all off, but maybe the more interesting difficult question is along the continuum, at what point, is there, a browser doesn't support rounded corners, but it does have all the buttons right. But they've got to have square corners, I mean that's a straw man as well, obviously. To me this is maybe out of this is the interesting question, where on that scale, is, how much, what's the base line? - [Voiceover] When it comes to the business case, and that's it.
Who is the audience, and who are you trying to target, and you might have to cut some people out, and that's like sad, but you have to, you can't be at that extreme. It has to work.
- [Voiceover] We certainly know people who would say it did.
- [Voiceover] Right, but that's what the browser renders do. We try to, for those gaps, that's what our role is. To fix that for developers.
That's why we have html and that's what I encourage people to use html elements, because they are accessible.
So then you don't have to think about it too much. So the browser renders role is that.
So we try to fix that.
- [Voiceover] On top of that there's the (mumbles) story__ - [Voiceover] Hang on, I'm not sure the mike's on, Is it on? - [Voiceover] No, a fake mike.
- [Voiceover] No, it's okay, I'm used to it. So there's also the performance story that if you build stuff, progressively enhanced, you get to render them way earlier.
Now we heard earlier from Josh that early rendering without functionality may not be valuable.
But you can have html based functionality built in, for example, going back to the like button example, it could have been a form, and then, when JavaScript kicks in, you change it to something else.
So you could have early rendering, you could have a better performance story, a better accessibility story, a better semantic html that we also heard yesterday about benefits in terms of translation, for example.
So, using html for what html does best, is in your best interests.
Now, there are some apps where it doesn't, you cannot, for a video chat app, there is no fall back, unless you turn it into just a regular chat, that is server based.
You could claim value in that.
You could say that it has no business value, but for most things, like for the Trello example, you could have rendered that as html and then add all the animations later on, as JavaScript, where when there is no script, you could click on various places, and this, the page re-renders, which is not great, but no JavaScript case is the extreme case. Common case is JavaScript is either broken, or comes in late.
And this happens quite often.
- [Voiceover] So Alicia, I see you nodding vigorously. So is that, so your approach, you've got a kind of main stream product.
Probably not of the scale of FaceBook, we'll get to Seb and his thoughts around this, I think Facebook have very strong opinons in the sense of baked into their architecture and code around this.
What's the approach that you, because you've got Ember based front ends, and you heavily depend on JavaScript.
- [Voiceover] So, depending on who on my team you ask, this answer varies.
For 80% of our website, we probably don't need to use Ember. That was a decision that was made very early on, and I think that's more of the problem.
Where we're saying let's use JavaScript for everything, even though there are things that basic html and css do really, really well.
But we're just deciding, for some reason, that no everything must be in JavaScript now, and so now we're running into this a lot more. I don't think it's that we can't do it without JavaScript, it's that we don't want to.
I think we've gotten to this point, where we're looking for a silver bullet.
We're looking for the one way to do things, and that's where you get these really passionate camps, of it's reactor and only reactor.
It's angular and only angular, right? I think the beauty of the web, is that there's no one way to do things.
And it's all very relative, and it just seems like we're trying to get rid of that.
- [Voiceover] Right, I tend to agree, and I think one of things I notice is you'll see, I think there are definitely places with different approaches but we'll often see plain old fashioned websites which you know the obvious example of which was it, which was the one you did today that you said, the mobile was broken and the website is-- - [Voiceover] the verge - [Voiceover] the verge right and it's like a it's literally a plain old fashioned website you could have built with html and font elements in 1993 and it's like nine ten meg page load, most of which is compressed javascript.
And I guess part of my concern around these things is, if people almost use things as an excuse.
I'm building a really complex thing therefore I don't have to worry about, and I think you know progressive enhancement is one thing, but accessibility often quickly follows, in behind.
Because there's not many people who really need accessible solutions.
That tends to be that the sort of reasoning around that and I guess that's one of the reasons why I'm sort of calling this out, and what we will hopefully lead to is this, you know my sense is that we've got all these different kinds of things that we're building. But for the longest time we built more or less the same sort of thing on the Web right.
And so we had one true way of largely building that. And all people like me you know in my pyramid of html can do it css next if html can't , and Java Script on top of that pyramid of technology, which is kind of a really simple web architecture that I tweeted about in the same time frame as this, and was like re-tweeted hundreds and hundreds of times and criticized as well.
Like that architecture, you know, you know that's good right? Sometimes the criticisms were like, no I really did not mean use font tags.
I meant properly.
140 characters.
And I guess I'm wondering if we're moving to an era where that's that approach that all web people have had since the beginning.
There is this web way of doing things.
There is webiness, but now the sort of things that Facebook are doing and Seek it doing, you know they're very app-like experiences, like serving people at massive scale over all sorts of networks.
Maybe it just means that you know we have to start thinking about the different things we're building and choose an architecture appropriate to that. So I guess Seb, you know like obviously, the front end team at Facebook is very heavily in and around you know around JavaScript.
Obviously react comes from you guys, you know one of your colleagues in a conversation I had on Friday night was like he sees this I see css as an implementation detail right.
And there's certain amongst us who would go, ohh, but that's a position that's there right.
So I wonder if you could talk to, I guess specifically the cons of challenges that realistcally if we weren't doing this we just couldn't be doing this sort of stuff.
What's been your experience? - [Voiceover] So first off I've been at FaceBook for like a year, and I don't think I've written a line of html, css, or like front end JavaScript. - [Voiceover] Does anyone write html and css? - Pretty sure yeah.
- [Voiceover] Do people write html css or they mostly do they write JavaScript? - [Voiceover] I mean they write all three, but I'm saying personally, I haven't actually really worked on that directly.
I'm aware of it just so I can probably, give more information-- - [Voiceover] Just to the room on the mike, if you want to have words, do you want to speak to that Josh? - [Voiceover] I mean I guess like one of the biggest things people say about like Progressive enhancement is like oh disable JavaScript news website, and everything is like it doesn't work.
If you disable CSS it's probably going to look like shit, but But like the implementation detail around that is, if you're building a technology to power the website, then it makes sense that that would be there. Like what benefit are you actually getting from supporting like the no JavaScript case? So it would be like the few seconds of page load, where you can't it's waiting for the Java Script to happen in which case I see the solution to actually be, just like make the JavaScript execute or load on the client faster, to the point that that's not an issue, or lazy load everything.
- [Voiceover] But why do it that way? I guess what I'm getting at is why do it that way. Why do you have to do it that way in particular, and it's not a rhetorical question.
- [Voiceover] I mean really you don't have to do anything anyway.
- [Voiceover] Yousaid today, why has Facebook made a decision this is what they're going to invest in. Josh, do you want to speak to that? - [Voiceover] I can try to field this.
Like firstly I think the reason the progressive enhancement is great, when you're developing applications using html and css is like it's two fold.
So firstly you get that nice incremental loading behavior, like that's that's what we want from applications, they load really quickly.
And the second is that it's a little bit like semantic html, in the fact that it's, I saw John do a double take there, - [Voiceover] No, I'm looking at the time, - [Voiceover] is that it's more of an indicator that like you know what you're doing, and you know how to build applications.
So like it's good for the incremental loading behavior, but also like you can have a fair bet, that anyone you talk to who says I love progressive enhancement, I love semantic html, you know they have their reasons for doing that, and it's an indication that they know how to build applications.
And so I think you know really the heart of the matter is that like we build applications at different levels of abstraction.
So there are a lot of people in this room who probably, you know when they're building a website they build html and css, and that's great.
For Facebook like that just did not scale across hundreds of engineers.
Like you cannot have hundreds of engineers-- - [Voiceover] So that is so that's the interesting part. Why doesn't it scale? Again, it's really interesting question, and I really want to learn.
Well with you've learned about scaling things, - [Voiceover] Great, especially in the old days, like css consider like how we used to write css six years ago.
Nested selectors, everyone's just like I need this hack, my button is in the sidebar, I'm just going to like add a selection that overrides this. You imagine 200 people touching the same code, doing that? And it just doesn't work, so like we've moved towards this component model where you have like css modules, like Mark's you know advocating for, and we use component models in React and in PHP2 and so for us, that's our building block, is react. And so it means that if you do want progressive enhancement to be you know that html and css progressive enhancement what you're really doing is now you have to opt out of that mindset of like my building blocks are react and an XHP which is now PHP abstraction, into this one where a list like you have to be like building one thing and then thinking about how that actually renders on the page.
You know in the final form.
Because otherwise it's hard to kind of like understand what's going to happen.
So it's like if I build a react component and I'm thinking about how that initially, that finally renders, like that's going to be hard model to develop again.
So it's easy if you say 90% of my work is in react code, but that's how you think about you know the application delivery.
I think the incremental loading behavior is great, and we should totally do that.
I just think it's different for people who are living in JavaScript for a lot of the development, as opposed to people who are living in html as their kind of building blocks for their applications. - [Voiceover] So sometimes it comes down to what developers know, to begin with.
And then around a team, because the core development and team development is on JavaScript you start acquiring more JavaScript developers.
And it snowballs in a way.
- [Voiceover] Not so not so much that they know, because it's like a lot of Facebook engineers do understand the fundamentals of the web.
We hire smart people and they they do understand this. Just in your general day to day life it helps to put a layer of abstraction on it.
Obviously like you're developing html and css and it's like you know the fundamental, the implementation details of that is obviously the layout routines, and the paint routines for how the browser does layout. You know you don't expect someone writing html and css to kind of like code their application with that in mind. So it's like it's an implementation detail of how you design applications.
And yes you can understand it, but that shouldn't be front and foremost in your mind in your day to day work. - [Voiceover] But you just abstracted away the importation details.
- [Voiceover] Exactly, yeah.
And in react we can we can say yes we can do things like this like you have mentioned the like button. You know you can have a nice toggling behavior and have a fallback and like react does allow that as an escape route.
Is that you can say like OK that's how I'm going to implement it, implement a button.
And if you choose to be severing and have that as your implementation detail for a toggle, then that's great. Like yes, go for it.
- [Voiceover] I would claim that these two worlds are not contradictory in any way.
Developer workflow, html and css have been an implementation detail for the server side rendered websites forever, not forever, but yeah.
Because if you generate your html using templates, then it's generated html.
It doesn't mean that it can't be semantic, it doesn't mean that it can't have the same fallbacks. And the same is true for the react world, especially in their server side rendered context. You could generate completely valid semantic, accessible html out of react components, while maintaining your workflow.
Those those two worlds are not contradictory. And the only thing is if html and css are an implementation detail or a compilation target, they should be a well optimized compilation target. That basically maintains all those semantic qualities of them.
- [Voiceover] Elice, you recently started working at the digital transformation office.
So I guess that's why you're only there a few weeks, one of the government digital service, because I think one of the elephants in the room right now is native stuff.
We might get to that like native apps.
Because you know for the last couple years at the very least, has been well a bit longer still, a genuine concern that perhaps native is just, doing what the Web's always done.
You know traffic numbers gone mobile for web has been falling because people are living with attention spans are also taking place inside native apps, basically inside Facebook really. That wasn't a flip comment.
You don't but certainly a small number of social media sites are generating most of the attention and they're taking place inside for the most part (mumbles) So that's a bit of an elephant the room but one thing that the Government Digital Service in the U.K. is done which is like the cream of the DTO that's been around a long time they've said, we're not doing native apps.
It's web all the way down.
So I guess you know now whether and they tend to also be around css, html, some JavaScript as a general rule.
What about within DTO, what's been your experience, and perhaps differently from say a startup like high pages where you were before that.
- [Voiceover] I mean certainly one of the concerns is often we don't know about users that have JavaScript disabled because tracking requires JavaScript. So at the DTO user research is really important and they do a lot of surveying real people, to find out what the concerns are.
And obviously in that context as well, we need to support all users.
So I think it's about sort of, defining what your baseline is for your product.
And maybe Trello is not a great example because it's very rich.
But your baseline could be something as simple as having a PDF that you could download, instead of viewing at a hyper-visual app.
And these are some of the strategies that we're thinking about at the DTO.
Particularly for things like graphs, so SVG support.
We have you know we're having conversations about should there be a downloadable resource as as a fall back, so everybody gets value from services.
- [Voiceover] And I guess with DTO or GTS it's about reach, I guess.
It's about the breadth of reach.
You simply cannot leave anyone, no matter where they are, network or someone behind.
Because they need to be able to interact with government, especially with a digital first approach right. You simply have to take care of almost every possible use case in terms of technology, and disability, and everything else for that matter.
- [Voiceover] Sure, and to go back to the question about the apps.
So one of the tenants of all these things is that, some users don't have iPhones, so if you're building an IOS app, well that's great, but you're still going to need to build the full spectrum of apps. A lot of devices, you know some devices, just think about some android devices for example. So you still needing to build the web equivalent as well. So yeah I mean the first thing is you know that's more universal solution than just a specific target group, because they have a big wedge of the, a big monopoly of users.
It's not everybody.
We need to be more inclusive.
- [Voiceover] All right, so I'm going to finish up this bit, and I've got a couple of other questions I want to soley monopolize on this position.
So but Facebook, obviously Facebook we have an ambition, and we're certainly getting there towards that reach, but on a global scale.
There's a billion active monthly users, maybe some days of more billion monthly active users, and yet it seems to me that native apps are probably being like Mark Zuckerburg famously said, we bet on html5 was one of the biggest mistake we ever made, you know. That was some sort editorial there that I didn't quite catch, but you know I like in many respects I'm very much applaud and excited, a little bit surprised by why there even are teams doing JavaScript and so on, given how much outside desktop, on mobile platforms for example, the native approach is kind of where people are being, that's how you want to live your experience so.
I guess is why are you even doing web stuff anymore at Facebook.
- [Voiceover] People still use websites.
- [Voiceover] People still use websites.
I mean are you finding certain kinds of people use websites and places where people use websites, and you know I guess short of you know, obviously there's some proprietary knowledge there. But I really interested in what are the kinds of people who use websites? Where they're using them? - [Voiceover] So the question is who's using the Web? - [Voiceover] Right.
Who uses the web.
- [Voiceover] It's a very broad question.
I'm not sure there is anything too specific to Facebook about it.
- [Voiceover] Well no because, no because I think it's specifically in FaceBook's case, like I would suspect a very large percent of your traffic is using a native Apple mobile or and IOS Android, for example right.
And then on the desktop you have native apps, but most people I suspect on desktop use the browser based version of the site.
But I'm generally interested.
Are there things we can learn about who ultimately continues to use a mobile web version, or a web version, as opposed to a native version.
- [Voiceover] I mean Facebook does have like native versions of certain apps on the desktop as well as mobile. - [Voiceover] Yeah there's also like the mobile websites, like set like a couple different mobile websites. One that you don't actually even need JavaScript for, that has very, they use just basic css for all sorts of phones.
I think Facebook definitely does care about accessibility and having as many people as possible being able to access it.
Yeah I mean that the web is just like another vector for that.
So there's like the desktop app where, it is assumed you have JavaScript.
And then the mobile, there's a mobile website where you do have JavaScript, but then there's another mobile website that assumes you don't.
Since that's like a common thing in the environment. Josh can maybe talk more about the specific specifics I guess.
- [Voiceover] Yes as for who uses, I think it's a great thing that on the desktop right it's like our main Facebook dot com site like it wins right. And I think that speaks to the volumes of how strong the web is on the desktop.
On native like you know definitely, the mainline experience is the assumption is that you have the native apps.
And you know that's the way it is now, and that kind of sucks for us as web people. But that's just the expectation that people have, from the from the applications that they use. Is like you know we want to push the boundaries on every possible front.
Like if you have a 360 degree video, and you want you move your phone around, and we want to be able to render that for you. We don't want to have the technology holding us back. Unfortunately on the Web You know it often is, that you have to trade off between you know what the Web can do and what you want your product to do. You know we obviously still have the mobile sites, and they're important but that's more about like just extending that reach as far as we can get it. - [Voiceover] All right Marc, Marcos.
- [Voiceover] So I guess another problem that, I wouldn't say problem but-- - [Voiceover] Challenge - [Voiceover] well I know one other problem that like native absolutely Twitter and Facebook have is that, what makes them social is also this ability to share that little your L. thing.
So you eventually have to cater for the web, because what really powers these sites is this ability to share news items and share things that are out on the Web, So you know without the Web these things are, despite attempts to do you know this by, like AMP, whatever the Facebook articles are, the native articles.
What are they called? The instant articles all that stuff, you know they're just trying to replicate what the web does. And take characteristics of the web but at the same time, turns out these humans are actually sharing your Else which are on the web so.
Trying to kill the web is like a hard problem. - [Voiceover] Thank goodness but the rats will get us. All right. Do you want to say something Yoav? So I want to move on.
I want to leave behind that and we didn't really tease this out.
This is the thing that kind of interests me now. What are these architectures and approaches. I think it's still quite (mumbles).
I think over the next 2 or 3 years we will start optimizing around specific architectures, for specific kinds of challenges.
And I think it's still very early days around that. But I wanted to sort of end over the next ten minutes or so, with a quick swots.
Remember swots? Strengths Weaknesses Opportunities threats, I think I've changed the algorithm now.
It's like you don't have weaknesses anymore, you have challenges.
Whatever it's called.
Weakness is like uncool right.
Has everyone done one recently? What are they called? Anyone know? I like, we're going to start with what you feel, to the panel, what do you feel the challenges the web really faces.
What are the things they got to fix, what do we got to do better? What do we want to see being done better? Ben.
- [Voiceover] That's a pretty big question. There's a lot of challenges depends if you want to look out to where the standards are going, that kind of thing, but I think what people in this room probably need to think about, and it does it does kind of go back to what we have been talking about so far is, it's become very very easy to build something for the web quote unquote and actually very quickly and easily build something very very complex.
And the thing that I think is a challenge for the industry is people aren't necessarily, number one, making a decision for each of those pieces, and it's become so easy to run up and use an abstraction. We're getting people entering the industry who have never used the underlying technology.
So when you've never learned css, how do you even know what good css looks like? When you go and inspect your compiled code, can you even judge its quality? And I see this actually in terms of people who are interviewing, and people entering the industry. And they're just straight to writing SAS, the never write raw css, and I think that's kind of this issue of if you manage an entire orchestra made of people who never learned to play the scales for their instrument. I hope everyone here played some instrument, at some point and knows what this means.
It's like if you don't know the very basic music theory you're going to be very limited in what you can achieve with it.
And I think that's a big challenge for us as an industry. And the flip, to flip that quickly.
This whole focus on you know we want to use this tool, or think we think this is a better way to do this kind of stuff is it's very very easy to lose the user. Because the user doesn't care at all how you get the result, and I think that's something we can do.
Is like I don't really mind if we turn JavaScript on , or off but I want you to actually think about, if you're going to use JavaScript, is it fast, is it accessible, is it going to keep working on a reasonable range of devices, and what do we even classify as reasonable. Because you imagine I'm sitting here, I'm thinking I have a fairly recent device, I've got a nexus 7, Facebook on that's not fun guys.
But that's my fault for continuing to use it in a way, but where is that bar, where are we cutting off our users, all of us can think about this as well. What is the bar we set? I think that's the thing.
It's the ease of complexity, and we've actually kind of made simple difficult. I think that's kind of bonkers.
And everyone's silent.
- [Voiceover] They're definitely things that came up in the panel on Friday in Sydney as well.
- [Voiceover] I should say sorry for calling out Facebook, I didn't really mean to do that, but I had been using the web app, sorry.
- [Voiceover] So we know how to uses Facebook mobile web app.
- [Voiceover] yeah it's me, sorry guys.
- [Voiceover] Elice? - [Voiceover] Yeah I agree with Ben and generally I think there's just too much complexity.
You know across the whole front end stack, and it's a turnoff, for new and old.
And as we all know the technology's getting replaced, very quickly, so just your react cool, next year something else will be cool.
It's concerning, because it's like we're redlining the whole time, as front end developers.
Sometimes it's better to just take the simple way of doing things for the longevity of your code. You know if you're not a start up, or you're trying to build something that that's going to be around for as long as possible.
- [Voiceover] Alicia? - [Voiceover] I echo both those points, and so being here specifically abroad, and getting a taste of the, I have a certain amount of gigabytes I can use over the you know course of my stay, and how that's affected my what I do on the Web, has been an interesting endeavor and I think really highlights that you know we talk about, you know the warrants of building things one way or another, like JavaScript disabled whatever, I think there's still a lot of room for you know exploring that we don't always have really awesome internet connection or like unlimited data. I think that's something that a lot of us still take advantage of because, when we're building these things were typically in a nice office with a nice fast internet. So I think there's still a lot of opportunity to come up with really good solutions for that. - [Voiceover] Yoav - [Voiceover] Excellent point, But other than that one thing that I love to see is, I love to see the gap between the web devs and the platform, minimized.
- [Voiceover] So what is that gap? - [Voiceover] So I think the Web platform basically is serving billions of users with millions of developers, and I'm probably exaggerating.
Hundreds of people maintaining the platform. And I'd love to see more users getting involved, not users, but more maybe users but before that, more developers getting involved in the process. Because there are a lot of things to be done, a lot of work to be done, and I think it can benefit everyone.
Like Hadi outlined knowing how the platform works, can often help you in your work.
And getting involved in web standards work whether it's by feedback, testing new features, writing tests-- - [Voiceover] And then all the new specs, are acting up, and raise issues on github directly, made it 100 times, Rachael mentioned that yesterday, made it 100 times easier to contribute in many respects. - [Voiceover] yes everything is on github, tests or written in htmls, css and JavaScript, and all of that is very accessible.
I'm not going to lie it is time consuming.
But I think that in the long run it's worth it, for both people that get involved, as well as the health of the platform.
- [Voiceover] All right.
And I want to finish, on a high, obviously. So I'm going to ask everyone give me a short something that's exciting you about the web.
Something you're thinking about, or working with, something you want other people to know about. So I'll start with you Seb.
- [Voiceover] Actually this came up today.
I don't think that the Web has enough html heading tags. Six isn't enough.
- [Voiceover] right.
- [Voiceover] I don't know where they drew the distinction at six.
I want h7, h8, - [Voiceover] Well hml5 was supposed to fix that, by just having h1s and like a nesting algorithm, but we've kind of given that up, haven't we. Yeah, all right.
OK you just put, h6 classicals plus five, Mark? - [Voiceover] As my snarky tweet says, it at least starts positive which is, I do love progressive announcement and this might seem like I'm just jumping on the latest fad but I'm honestly really excited about what's happening in the react space.
I've been using it in production for quite a while. The fact that you can server render react apps is what got me hooked on it in the first place. And we're now using it at Seek to kind of bring these two worlds together.
I really love single page apps I think that they're clearly the future of the web.
That once they're running they're a much better experience but I think giving up that first load of seeing usable content.
I think that's that's a really big thing to give up. And I've certainly gone through that period, where you know you build these big rich apps, but then you don't actually see anything on the screen for potentially seconds at a time on the first load. And I think it's a real innovation that's happening in that react space and it makes me feel like it empowers me to be a better professional. Because I can build something that's really sound from an engineering perspective, really good from user experience perspective, and I feel like I'm staying true to my roots as a web developer.
I'm not giving things up like I used to, in you know the world of say backbone or angular, in my previous work.
So yeah and then the react space is just so much, so much innovation happening there.
But ultimately it's about the progressive enhancement for me, and I really really enjoy that. - [Voiceover] Awesome, Ben.
- [Voiceover] I think what's kind of exciting in a way is there's been a big period of turbulence.
We've had a lot of highly competitive, the librarian framework and all that kind of stuff, but what we've got right now, I actually will echo that. I think react's quite cool in a lot of ways, because one of my actual core philosophies is to bet on standards.
And this might sound funny, but when you look at what you actually write, because we're doing this at work at the moment.
We're writing a lot of ES6, thanks to being able to use Babel, which is awesome. But we're doing that and then when you look at JSX and then you look at Web Components, conceptually so close, so what you're looking at is a whole generation of people if we get on this type of, this style of building, down the track as the standards catch up to the implementations we're doing now with the abstractions, we have a really clean looking future.
Because react to me is like the final wish to have web components now and really web components is a final wish to have in templating language that we can use everywhere.
Because that's actually one of the huge things you hit if you do your UL libraries is how do I get this across multiple stacks.
There's no one templating language that works, but web components because it's the target, would actually give us that.
So a bit long winded but all I'm saying is that, we get a lot of standards innovation from the abstractions we push now.
And the abstractions right now are actually starting to look quite good.
You know I mean they're actually quite useful, fairly succinct.
So it's a really exciting direction.
- [Voiceover] Yeah, I'm quite interested to see how the Web will move down closer to the operating system. And sort of IOT comes to mind.
There are so many new apps and types of apps, that we're yet to build, that you know, I was talking about this yesterday and example might be, your payment final might actually turn into being more like an eftpos terminal.
If you would sort of pay somebody in real life. So yeah I'm really excited, to sort of think about where the web might go, and that if we try to be more ambitious with the tools that we have, to what we can build that we haven't.
Really, we've just been building blogs and stuff, and sort of it sounds pretty trivial.
So let's see what happens in that space.
- [Voiceover] I'm very excited about building games on the web.
So I grew up in the generation that totally just consumed flash games like nobody's business.
That's what I would do after school, and I think it was great and you kind of saw that really go away.
You saw a lot of great kind of like games go away, kind of with the death of flash.
One of my favorite games of all time, The Binding of Isaac started as a Flash game. Got some really great feedback from from that, and so I mean with you know the Web G.L., with canvas and even with, and this might be terrible, but I like to use and abuse html and css and JavaScript to make games not in canvas, which is a lot of fun. And I think there's a lot of potential there. And I think we just need a lot more people to go and do it, and kind of abuse these technologies for things they weren't made for.
- [Voiceover] Yeah we had this great period of about 2009 and 10 with a lot of really interesting game engines and gaming things happening in the browser, and it's sort of, like Zynga invested heavily around that, and a lot of browser based games, almost always on the Facebook platform originally. But they have kind of faded somewhat I think you're right. Maybe they're all on I guess they're on IOS and Android as kind of native apps.
But bring back those web games right.
All right we'll finish up with you Yoav.
So what have you got? - [Voiceover] I'm really excited about progressive Web Apps, and basically having Web apps that are installable, work offline are fast to use, and can have all like push notification, sync, potentially geo location and all the other nice things that the native apps have, while still maintaining the ephemeral nature of the web with some sort of permission model that we still have to work out. There are a lot of details to work out, there but I think that progressive Web Apps are definitely exciting.
They're definitely the future and it gives us the distribution of the web that is unparalleled, with all the capabilities of, that people nowadays require with native apps.
- [Voiceover] So you get the breadth and the depth, together? Magic sweet spot.
All right so one that, let's please thank our panel for their thoughts.
Thank you very much.
