007 - The state of the modern web

• Experts Deborah Kurata, Hampton Paulk, Jonathan Mills and Joe Eames discuss the frameworks and processes driving modern web development.
• This breakout session was one of the most popular at Pluralsight LIVE 2019, and we’re excited to bring you the audio of their conversation.
• Real Talk JavaScript podcast

If you enjoy this episode, please consider leaving a review on Apple Podcasts or wherever you listen.

Please send any questions or comments to podcast@pluralsight.com.

Daniel:
Hello and welcome to All Hands On Tech, where today's leaders talk tomorrow's technology. On this episode, it's our pleasure to bring you one of the most popular breakout sessions from this year's Pluralsight Live, Pluralsight's annual user conference. This panel, titled The State of Modern Web Development, gave attendees the opportunity to pose questions to experts Deborah Kurata, Hampton Paulk, Jonathan Mills, and Joe Eames. We think you'll enjoy this entertaining discussion about frameworks, tools, processes, and more.

Deborah Kurata:
We're going to start off with a question that I'm going to ask the panel, and then after that it's going to be all you. So if you want to start thinking about what question that you have about the modern web, the whole thing today is going to be answering your questions, so hopefully you brought a couple with you. All right. My question for the panel is please introduce yourself and tell us what you think is the biggest hurdle today for developers working with the modern web.

Jonathan Mills:
All right, so I'm Jonathan Mills. I'm a Pluralsight author in the JavaScript, Node.js Express kind of space. I'm also a technology advisor at Worldwide Technology. I think the biggest challenge right now is identity management and security because I think a lot of people don't think about it nearly as much as they should be thinking about it. We just kind of try and slap that login page there and that's not what we want to be doing in the modern era.

Hampton Paulk:
Hello, I'm Hampton. I work at Pluralsight. I'm the director of curriculum over software development. I think right now this is a little bit self serving, so, I mean, you kind of expect that, right? It's education, right? It's learning, keeping up to date with your skills, trying to figure out what's next. Learning things like secure coding in each particular language, each framework, each tool where to find that and where you're not just sucked in to multiple websites to learn the same thing.

Joe Eames:
My name is Joe Eames. I am a Pluralsight author as well, been authoring since 2012. I've been developing for quite a while, since '96, primarily into Microsoft and web spaces. I've been doing mostly education for about the last six, seven years, and now I'm the CEO of a small company called Thinkster.io. And as far as the biggest challenge, is the biggest challenge for software development or just web development developers? Developers. Biggest challenge for developers. Regardless, I think the answer is the same, which is dealing with the pace of change, right? Especially when we talk about with web stuff, but just dealing with the constant pace of change and how that affects our jobs, as specifically large enterprise apps.

Deborah Kurata:
All right, thank you. My name is Deborah Kurata. I'm also a Pluralsight author, primarily in the C# and Angular space. I also have a consulting company doing architectural and code review kind of things. I prepared a couple of hurdles, because I knew I was going to go last, so I didn't repeat one that they said. So the one that hasn't been mentioned is user experience. I think that as users of the web, we have probably experienced really bad design. Just the other day I went to a website that came to tell me something, that standard, "We do cookies," kind of thing, and that dialogue was so big that the little 'X' on the top was off the upper right hand of the screen on my phone.

Deborah Kurata:
And I was hosed. There was no way I could access that site because I couldn't get to the little 'X' to close the big dialogue. So I think that we have a long way to go. If you were in the session this morning, you might have heard them talk about how mobile is so important in so many places and as one of the key driving factors. And so when we're doing web for mobile devices, we have to be worried about foreign factors. All right, so now that you know who all we are, let's go ahead and open it up for questions. So, anybody want to start? Who wants to be the first one with the question?

Audience:
I don't know if this is for you, or if it's for Jonathan, or, I don't know where you right on the front end or the backend of development, but we did go to a progressive web app course today, and, for me, that was the first sort of interaction I had with it. My tech lead that I work at seems to think that WPF is going to be the future of a lot of things. I know it made me laugh the first time he said it, but really, when it comes to platforms for how we deliver what we do, it's hard to really predict what we're going to do. What are your guy's opinions on progressive web apps or where do you think we're headed as far as how we deliver things?

Hampton Paulk:
I like them personally, so my opinion is going to be biased towards enjoying them. I liked the experience, right? I feel that it's better for the user when it's an integrated experience. You get more interaction, you get more time on a site, you get more investment from an actual user on your site with a PWA, unless the data has magically changed in the last three to six months. But I think they're good and I think it allows you to do really good debugging, really good testing for performance. It's a good way to package things, especially if you have a product that you need to get across and keep people there, so.

Joe Eames:
Some other really good aspects about to PWA, like he was saying, is just how much it can improve the user experience, to Deborah's point. But my opinion, in general, about PWA is that they are one of a set of tools, right? So, don't look at it as your panacea to all problems in general, right? From the scale of, we have a completely non-mobile friendly web app, all the way down to, we have custom mobile apps built specifically for iOS.

It's just a tool along that spectrum. It's not a unique tool as well, you can have multiple points in there, but it is something that you should be aware of so that you can understand if this, by itself, might be a solution to some problems you're experiencing with your other delivery platforms. And you can use that in order to alleviate problems elsewhere and potentially cut your development costs, while increasing your user experience. So it definitely is something that your team should be aware of and understand. And if nobody on the team has ever played around with it, somebody needs to spend some time.

Audience:
So we've got Vue.js, React, Angular, which would you choose and why?

Joe Eames:
It's Svelte.

Jonathan Mills:
Stencil, maybe? I don't know.

Joe Eames:
[inaudible 00:06:46] Really low end.

Hampton Paulk:
What's your team using right now?

Audience:
Vue.js.

Hampton Paulk:
Keep using Vue.js? I like Vue.js. So I'm glad you said that, but it's one of those things that, do you need to switch? Do you need-

Audience:
No, I was just curious.

Hampton Paulk:
Yeah, yeah. I'm just saying... Teams rally around technologies, right? They get excited about it, they feel intensely particular about one framework over another. They all work, right? They're all pretty fantastic. Everything has its advantages and disadvantages, and the internet is full of people that will gladly tell you the advantages or disadvantages of each one. And that's great, right? And we love opinions, right? That's why we're all here for a Q&A. But really it's, what is your team excited about? What do they want to work on? What do they want to invest in? Is his way the one of the ways I look at it?

Jonathan Mills:
So I do Reacts, just to answer your question. I'm a React developer, kind of, sometimes. But I have played with Angular, and I have played with Vue, and React felt more in line with kind of what I wanted to do, right? And so, I would encourage you to do the same thing, right? I've played with Vue, I've played with [inaudible 00:08:05] Stencil, and all that, and the one you pick, like Hampton just said, they all work, right? It's more about which one do you feel the most comfortable in.

Joe Eames:
The one piece of advice I have for everybody who talks about this question is always never choose the solution based on the technology, because Hampton was saying the parody is so tight between the three of them, that outside of the choice of those three, there are others. I think that's Svelte as very promising, but it's too early to be going crazy about it right now, and others technologies as well, but inside of those three, don't choose it for the technology, choose it for political reasons. What does the team want? Was the team experienced in those sorts of things? Don't choose it for the technology.

Deborah Kurata:
There is also a company that does podcasts, and once a month, they do state of the JavaScript frameworks. And if you've ever watched that podcast, if you'd look up state of JavaScript frameworks, you'll find that it does a really good job of taking each framework, and they have Preact this time. They had Stencil, they had Angular, they had Vue. The React person had to drop out, so it wasn't in this past month, but next month they'll have them again. And if you start listening to those regularly, you will see that they're all working on the same problems. They're all doing the same things, they're just doing it a little differently.

So which you pick really depends on which one feels more natural to you. Coming from C#, going to Angular was very natural to me, because C# and TypeScript are so similar. But coming from straight JavaScript and jQuery to Angular, when you suddenly have to learn TypeScript, might be too jarring for you and you might want to pick Vue instead. So, it really depends where you're coming from and what you're comfortable with, and trying each one with the little project is a really good way to go.

Joe Eames:
Jonathan, are you TypeScripting in your React? [inaudible 00:10:08] No TypeScript.

Jonathan Mills:
Just so I could clarify for everybody in the room, right. So if I am working on something with a small team of people... I prefer JavaScript. I feel like I get a lot done, we move fast and things are fine. I have worked on a React application that had many teams all working in the same code base. We moved to TypeScript. For all the reasons that TypeScript provides, right? So it's kind of back to React versus Angular, right? It's the specific problems that dictated whether we went TypeScript or whether we went JavaScript.

Hampton Paulk:
And I would like to add one more tiny thing to that, is that JavaScript frameworks are not the only web frameworks. Just so that you know, other languages do this as well. So, there's more to explore there.

Deborah Kurata:
Blazer, anyone?

Hampton Paulk:
Python, anyone? Yeah [inaudible 00:11:02] You can write it and go.

Audience:
So I'm sure our web app is similar to some of you all is the web app, but if you were to take a job at health equity, you would get to the opportunity, in a single day, to work on asp.net. You'd get to work on NVC, AngularJS, and now Angular. So we've got this web app that has all the flavors. Right? Help me convince my VP of engineering that either we need to train all the developers on these technologies or get rid of some of those technologies out of our portal. What are the benefits, the pros, cons of that?

Hampton Paulk:
I know a great place you can go for education. If you really want to skill up, I have a spot for you. Yeah, I don't know how I can help you make that decision. That's a challenging decision. Scaling up your current staff is a big undertaking, but it's an important one and something that you will have to do no matter what you choose, right? Because it's always changing. JavaScript releases never change, right? They're always the same version. Doesn't happen to update very often. Anybody else want to add to this? I'm just rambling now.

Jonathan Mills:
All right. So, Hampton defaulted down one side of your question, which I'm going to kind of agree with. Because if I heard your question right, it was either or, right? Either start eliminating languages from your code base, or learn the languages that are in your code base. And I always hate the question when a developer comes to me and says, "This thing's written in something old, we need to rebuild it in something new," because you're going to spend a lot of time to write something that's not as good as the thing you have right now oftentimes. Things are going to break, you're going to miss something. And so, I always kind of default back to, and I'm the consultant, I said it depends, that's always the answer. But realistically, I think walking in with the mindset of, "We need to cull these languages in the next X amount of time," is asking, by default, for a lot of trouble, right? It's a good goal and you kind of work to that, but it's always better to know the stuff that you have to deal with than to try and get rid of it.

Joe Eames:
I want to add in a little bit into that, that the person who can't give you the right answer is the four of us up here, right? Because it is very specific to what's going on, resources, teams, that sort of thing. So, a lot of the reasons to consider whether or not you should be removing things, whether or not you should be just training, is going to be very dependent on what's going on. That being said, you have to consider a lot of things. You got a lot a large AngularJS app? It's not going to be too long before people are going to start leaving because they're being forced to work in all of the technologies. So, as much as it stinks, the reason that he has a job is because we need to be moving around. So, that's not really an answer to your question, other than the fact that it is a complex and there's a reason that you get paid a lot of money, because you have to figure out really complex problems like this based on your environment.

Deborah Kurata:
And just a sidebar to that question. There has been a tremendous amount of work done over the last year or so on really good tools and techniques for migrating your AngularJS to Angular, because AngularJS is nearing its end of life. So there's been a whole lot more effort. There has been effort but now there's been even more in making that process, not easy, but easier, to help move that over.

Joe Eames:
Slight sidebar. There are people on stage who have built courses on upgrading from AngularJS to Angular.

Audience:
So our company's trying to implement the static code analysis in our project. Before the battle begins, we are trying to establish a process where the code goes through the static ordinances and analyze the code. Do you recommend any tools for using the static code analysis, like [inaudible 00:15:20] and depend? There are so many in the industry that does that.

Hampton Paulk:
I am so trying to remember the one that I use for security analysis for static code analysis

Audience:
At this [inaudible 00:15:31], we are trying to use it, too, for security reasons.

Hampton Paulk:
Yeah, mostly. Yeah. For security. Yeah. I don't want to just sit up here on my phone looking for the data to give to you, but find me afterwards and I'll show you the one that I use and I get email reports that tell me about the code base constantly, so.

Joe Eames:
Maybe there's somebody in the audience who's been using some static code analysis that they want to mention. Coverity? I mean, you're talking to a lot of people who spend a lot of their time talking to people who do a lot of apps, but not necessarily spending all day long worrying about actually configuring static code analysis for large enterprise applications. So, probably people out here in the room. Anybody else have anything else that they're a fan of?

Audience:
Sonar.

Joe Eames:
Sonar? Sonar's a great one.

Jonathan Mills:
Oh, Veracode. Yup. And I've used that one, the previous enterprises too. It generally works pretty well.

Audience:
I find the promise of WebAssembly seems to be always talking about all these wonderful things that it will be. I want to find out what you think the short term practical benefits, that we can use now, with WebAssembly, or are there?

Joe Eames:
It cured my gout so.

Hampton Paulk:
Where it's going and what's possible with it, in the future, as it gets developed further, I agree with you. But right now I don't really know if there's a great thing that just you can apply instantly. I don't want to make the direct comparison, but it's sort of walking to a room and yelling Blockchain. Everybody's going to go like, "WebAssembly!" And you go, "Yes!" "But what do we do with it?" "I don't know." So I'm with you, I'm not 100% sure what the current major benefit is for the general user, right? Business case uses, I'm sure you can find it, right? Depending on what you need. But the future seems to be promising, so.

Audience:
We've got 50 or 60 different applications, independent applications, they're written from Ruby, to PHP, to ASP.net to spas, homegrown frameworks, anything. The company wants to try to create some uniform experiences, potentially even with widgets from all of these different products, in a more cohesive single interface. And the dev teams, from all these different, are all steeped in these other tech stacks, in these disparate tech stacks. I mean, we're starting to explore these micro front ends, but if you've got a Vue team that reads Vue stuff, and a React team that only knows the React stuff, should we be making a decision on dash boarding techniques, where the widgets are in a more uniform stack? Or do they all live and play nicely? It's a complicated problem.

Hampton Paulk:
I'm sorry, I just made a joke about Blockchain and I feel like I'm going to make a joke about microservices. For me, the solution there, without knowing all the things that you do, other than they're massive amount of languages, right? Is all about what are you using to tie all of this together, right? Or what kind of API do you have? I don't know, this might not be the answer to your question, right? But, for me, the promise of a graph QL API, in front of all of these services, that allow you to manage it through one end point, seems to be the goal. And then whatever you put on the front of that is completely up to you. Am I answering your question? If not, maybe these guys can.

Jonathan Mills:
So if I hear your question as a purely front end question, I become very nervous when I hear the word widgets from all of these disparate services, right? I mean, so what Hampton is talking about is exactly what I would normally recommend, is don't piecemeal and a front end, right? Build a front end, and then use some sort of backend technologies, graph QL for an API, whatever works, to go and pull information from all these things. If you're looking for a cohesive experience, don't try and Frankenstein something. Does that make sense?

Audience:
So we talked about how all the frameworks are all graves and they all solved the same problems over and over, but they don't inter operate. And even if they did inter operate, payload is prohibitive. It's just too expensive to load this framework and that framework all on the same page. How do we as an industry start getting away from solving the same problem over and over? Do we need better language primitives? Solidification around CME libraries? That kind of a thing.

Joe Eames:
So there's this thing where AIs, they get smart enough, and that's, going to call it the singularity, when they become self aware, right? And then they kill all the humans. That's, I believe, the solution to what you're talking about. It's a human problem. It's not a technology problem, it's a human problem. There's a great XKCD cartoon where he says, "Oh my gosh, eight standards for this thing. There needs to be one standard for everything, so I'm going to go write the one standard, and that's how we have nine standards." So it's a human problem, it's not a technology problem. We won't see the end of it ever and we probably don't really want to see the end of it.

Jonathan Mills:
Right? I mean I agree with that 100%, but I would go one step back to your question and say, yes, all these things exist because we're all different. Our priorities are different, just emotionally we're different, we connect with different things, but it shouldn't be too hard, I hope, maybe, to consolidate to one thing on a page. I would hope we'd at least get there. So if I understood your question properly, you've got multiple different frameworks embedded in one page. Yes, that is very much wisely so. We are trying to avoid that scenario very much, but I don't know that I want to get to a point where we have one thing, because then we're shoehorning everyone into a box and we don't all fit in the same box, right? So let me have the thing that I want versus what you want, as long as we have something that solves the problem for the person who's trying to build the thing, if that makes sense.

Hampton Paulk:
So I'm not going to try to remember it, but Moore's law about power, right? Maybe there's one about frameworks getting smaller and smaller as it goes along, because I feel, with Preact, right? I just watch that modern web development, the this dot presentation, and it's just such a tiny little [inaudible 00:22:02], it's just a little tiny thing that still is powerful like React; and it's just really interesting. Things are getting smaller, so we still don't want to embed multiple things on a page, but it seems people are working towards faster, more responsive, smaller, less things on a page. I don't know if that answers your question, it's just a rant.

Jonathan Mills:
Svelte.

Deborah Kurata:
And if you're keeping up with what Angular is doing, they're doing the same thing. If you look now at the size of the bundles that the Angular, ng, deploy does, or ng build --prod does, they're very small. And if you use stuff lazy loading, you can get them even smaller. So you can get that, and then coming up as the new Ivy, where it's going to be smaller still. So your frameworks are, as was said, they're getting smaller and smaller. And again, if you listen to these podcasts and you listen to all of the developers, from all of these different frameworks, they're all shooting for the smallest KB size, not MB sizes, of the frameworks.

Jonathan Mills:
Right. And nobody said you have to put your entire website in one bundle either. Right? I mean, and I've seen that where they have this big massive web application and everything's in one Mundell, and then they're curious as to why it takes so long to download, right? Break this stuff apart. And it's okay every once in a while for a screen to refresh. People will live.

Joe Eames:
Your original question, though, was really about why are we solving the same problem in different ways, right? So, I just want to point out some other good aspects about that, right? It's a problem because now I'm worried about Angular, React, Vue, Svelte, Cycle, or maybe I should go back to Knockout. Whatever you're worried about, the alternative is what we get when there's only one supplier of t-shirts and we all have to stand in line for four hours to get our t-shirt, right? When there's only one option, things get much worse than when there's too many. So as they each solve problems, each of them keeps an eye on each other, and the ones that come up with really interesting solutions to problems cause the others to think outside the box and come up with new things, or else they die and somebody else comes along and produces something new. So there's a lot of really, really, really good stuff that comes up from multiple people trying to solve the same problems. And we're going to see that forever.

Hampton Paulk:
No, I just feel your pain because I have to teach all of it, right? So every time something new comes out, they're like, "Ah, yeah, we got to do of course on that."

Audience:
Thank you. You've already touched on this a little bit. I need to support an application that supports 39 languages and remote areas of the world where they have a mobile 3G connection. Aside from distributed architecture and breaking down your components, if the application has 500 components that can be used in any way whatsoever without our involvement, what are your tips for keeping performance high?

Deborah Kurata:
Bundles.

Jonathan Mills:
Yeah.

Hampton Paulk:
I don't know if I have an answer for you. I don't know, what's your slowest issue? What's slowing you down? What's causing the refresh rate to be slower? What's causing the load times to be slower? What's your performance issue? That would be what I would try to attack. I mean, it's an obvious answer to the question, so it's not really thoughtful, but...

Audience:
Sure. The number one bottleneck, of course, is the JavaScript's loading our framework.

Joe Eames:
What framework are you using?

Audience:
That particular one's using React.

Joe Eames:
I have two suggestions. One, hire really smart engineers. What you're talking about is a really cool problem, and solutions to that are available, but they're probably going to be a really difficult problem to solve using a very out of the box solution. Right? But it sounds really awesome and that sounds like a really cool problem to solve. So if there's any super smart engineers that are looking for a really cool job, that sounds like that's the place you want to go talk to, because you'll be doing cool stuff. I don't think anybody out of the box is going to help you out with that. You should be aware of what's going on, keep abreast of the new stuff that's coming out and keep an eye on that. But what you're talking about is a really, really specific problem. 3G in a really, really, really complex app. Yeah, we can do 3G on React on simple apps and have no problem, or Angular, or whatever. But 3G and a really, really, really complex app? That's going to require some really good engineering.

Jonathan Mills:
And some of that comes back to all this stuff we were just saying, right? I mean, if you're having problems with performance in a React app downloading on a 3G connection, the first couple of things you start looking at is bundle sizes and is Preact the right answer. Start analyzing what goes into that react application and start trying to pare it down, as best you can, to get that bundle size as small as possible.

Hampton Paulk:
Could you handle some of the heavier lifting on the back end, instead of on the front end? Just any of the, I don't know your architecture at all. It's just one of those thoughts. That was a good one, thank you.

Audience:
So this is an Angular specific question.

Deborah Kurata:
Okay.

Hampton Paulk:
I'm out.

Audience:
We're currently trying to upgrade a legacy.js app, and we see the two separate approaches either going the hybrid or using Angular elements. Which one do you recommend and why?

Joe Eames:
Without knowing the environment, I like hybrid, because it's not just a component based solution, it solves other problems with services and things like that. So I like hybrid for those reasons, but there is certainly, based on what you're doing and how the teams organized and things like that, that the other solutions may be good, but I guess, without knowing much more, just out of my gut, I would say hybrid. And there are some really, really, really top-notch consultants that can help you consolidate a lot of work that goes on. HeroDevs comes to mind, they're doing some stuff with upgrade that nobody else is doing. So that would be one place that I would look at if you need some help to make the transition smoother. Nrwl does a lot of this sort of stuff as well. Those would be the two that came to mind for me.

Audience:
In a world where a 5G's about out to be real, and I have a gig line run into my house, and it seems everyone's getting more, and more, and more bandwidth and speed. Do you think that's going to change the industry at all?

Joe Eames:
Well, let's not forget the Elon Musk smash, right? That's coming too. So, depending on how long 5G takes and how long it takes to get out, because it's really short range, right? It's not going to be really great for cell phones for quite a while, it's going to be mostly, apparently, a home-based thing. Is it going to change things? Yes and no. But look, here, everybody is at least running on 20 gigs or better, for the most part, across, what is it? 80%, 90% of the US? And yet we still have to deal with 3G outside of places like this. So, if your applications are super US-based or Western Europe based, yeah. Outside of that, no. It's just going to be the same story that, "Hey 3G is pretty amazing compared to what we used to have 15 or 10 years ago."

Hampton Paulk:
Attention spans are not getting longer, right? So even though speeds are going faster, we're evolving with those speeds, right? Now, you go to send a text and you're watching this little bar go about your image sending, and you're sending a text message, right? And you're like, "Really, this is..." So, it doesn't even matter, you're just impatient. So, I think it will make a difference in some areas, but you're always going to make things more efficient and more faster. More faster. Is that even real? That's not. More faster-er. More faster-est, yeah.

Audience:
Hey, I just have maybe a brief question about sort of the evolution of web development. Kind of comes from a CSS tricks article, called the All Powerful Front End Developer, and how the trend is towards front end technology kind of leaking back into the backend stack. Just wanted to get y'all's thoughts on that as a trend and what skilling might look differently in the future based on that.

Jonathan Mills:
How, how are you defining front end technology in that's statement?

Audience:
Yeah, I don't know that I would define front end technology so much as just the person that works on the front end seems to be creeping back with things Serverless, which isn't a front end technology really.

Jonathan Mills:
I gotcha.

Audience:
But it does seem to be enabling rapid development for front end developers.

Joe Eames:
Now there's a lot of really cool aspects of that particular thing. For example, Nest is a really hot framework and it's really just based on what's been going on with Angular, right? So here's somebody who's looking at Angular, doing cool things, but I want to do something more on the backend. Node is just another example of what you're talking about like that. Again, to make it even more interesting, just to go back another seven, eight years, and now it's the backend is slowly creeping to the front end, and now the front end and starts screaming to the back end. I think there's a lot of cool things. I don't know if I have any, well, what was the crux of your question? What do we think of it? What would we recommend in terms of strategic skills?

Deborah Kurata:
Skilling.

Joe Eames:
Skilling?

Deborah Kurata:
Skilling.

Joe Eames:
Skilling.

Jonathan Mills:
Learn JavaScript. So, right, I mean, when you're talking about front end, that's kind of why I asked the followup question, right? I mean, I'm a JaveScript developer and I do JavaScript everywhere. Whether phones for React native, or backend with Node, or front end with, I mean, yeah, JavaScript's everywhere. The more and more JavaScript evolves, because it is evolving slowly, but it's getting there, just the more it'll be even more places, right? That's the only way you can deal with it, really, is get on board.

Joe Eames:
I have a really good idea for skilling. Let me introduce you to my friend Hampton.

Hampton Paulk:
We used to divide things between front end and backend, from a curriculum perspective. But they've just blended, they've become one, right? Learning JavaScript is a great idea, right? Because you can do a lot of front end, you can do a lot of backend, it's great. But also think about your team. Leverage your team. What do they know? What are they working on? Right? What languages do they know? How can you leverage their already existing knowledge instead of forcing them into a particular thing? And maybe it's better that you write your API in Python, and you do some of the backend there, and then do your front end with JavaScript, right? Or maybe you do it all with a Python framework. I don't know. There's several different ways to approach that, but I think the lines are so blurred, between front end and back end, that you just have to have an open mind when you're approaching any problem.

Audience:
So what are some of the greatest innovations that have come to web development at this point? And what are some that are in the pipeline, in the future, that are coming to web development that you know of?

Hampton Paulk:
So we were just talking about front end and backend. I came up as a backend developer, not a front end developer. So... For me, what was hard about the front was the style, was how to handle dealing with styles and just doing really basics, because I'm just thinking about classes, and objects, and methods. This is all I cared about, and then I'm going into the front end. So what really helped me was how the CSS has evolved and you've gotten different styling frameworks and things that make the process easier, because I personally do not make beautiful websites. I go for functional, right? And so anything that can help make my stuff look better is a big development for me, so.

Joe Eames:
XHR was a really, really, really big deal when Microsoft decided, "Hey, we're going to make some way to talk to the backend without refreshing the page." That would be my number one biggest advancement. Number two was jobs. When jobs decided to kill Flash, he thought he was actually doing Apple a favor. Instead, he was doing JavaScript a favor by forcing everybody to make JavaScript be a high fidelity thing, right? So, killing Flash was a really big thing. Rails, for me, was the other. Those three things are probably the three biggest, most impactful things that happened to front end web development, outside of, say, the invention of JavaScript itself.

For stuff that's coming up, I think WebAssembly is going to be going to solve all kinds of problems that nobody anticipates, right? It's this crazy tool that nobody knows how to use yet. And when people start figuring out how to use it, it's going to do some amazing stuff. And then as the standard of bodies continue to evolve CSS, right? They're going to enable us to do way higher fidelity stuff and make the need for native apps drop more, and more, and more, which is good, we're still going to have them, but we want the cost of them to come down and we want the situations where we don't need them to be expanded, because that drives development costs down.

Deborah Kurata:
The other thing that I think about, from time to time, is when we're working to improve something, we as an industry, we think of little improvements. So we take a horse and we come up with a horseless carriage, which then becomes a nice car, which then we figure out a little plane and then a bigger plane, and at what point do we get transporters? There is some leap of technology that no one could necessarily envision that frequently happens seemingly out of nowhere. I mean, who asked for an iPod? We didn't have any idea that anything like that could exist and suddenly it became. So, some of that is very difficult to see into the future, because at some point, something's going to happen. I mean, if you look at old movies and visioning the future, how many of them had everyone's back pocket with a library of every bit of knowledge of the universe?

Hampton Paulk:
I will add to that and say, when it does come out, I can tell you where to go watch courses to...

Deborah Kurata:
We will have a Pluralsight course.

Hampton Paulk:
To learn about it, and probably one of these people up here will be teaching it.

Deborah Kurata:
Transporter maintenance 101. Transporter getting started.

Hampton Paulk:
You want that? Okay.

Joe Eames:
Mark me down for that one.

Hampton Paulk:
Oh, okay.

Deborah Kurata:
He's got that one. All right, we have time for one more question.

Audience:
Sorry. It goes back to that speed thing that I asked earlier. On my off time, I play some video games, and my computer is not that great, and I found this service called Shadow. I don't know if you're familiar with it. But Shadow basically just ports the video into my computer, no matter how good or bad my computer is. I'm running a super computer for my video games. It's amazing. And I think it's one of those transformative technologies that's going to change, like you were saying, I think it's the transporter with the horseless buggy.

Hampton Paulk:
Come see me afterwards. I'm very interested in this, deeply interested and want to know how that works.

Jonathan Mills:
Right. But that's actually kind of an interesting thing, because, back to your question, I can't remember who asked it, just now, the previous one, right? None of us mentioned the Cloud as a thing that has fundamentally altered the way we do things, right? So I've been doing this long enough to remember dusty closets, and now I can have something up and running just by hitting a few keystrokes on a computer, halfway around the world, doing something else. I mean, so that has massively changed the way that we do web development, and I'm a little surprised that it hasn't come up here anyway. Because now, to do web development, I can break it all apart and drop it in five different things that exist in the Cloud somewhere, and they'll all just talk to each other magically. And I don't need to worry about it anymore.

Deborah Kurata:
All right, well, I want to thank you ever so much for coming and joining us this afternoon. I really appreciate it and hope you learn something that you didn't know before coming. Thank you very much.

Daniel:
Thank you for listening to All Hands on Tech. If you enjoy this podcast, please rate it on your platform of choice. You can see show notes and more info at Pluralsight.com/podcast if you're interested in learning more about the two 2020 Pluralsight live events, either in Salt Lake city or London, you can visit Pluralsightlive.com.