• Do low code/no code advancements threaten developers?
• Is there a right or wrong JS framework to use?
If you enjoy this episode, please consider leaving a review on Apple Podcasts or wherever you listen.
Please send any questions or comments to firstname.lastname@example.org.
Amazing. Thanks for having me.
Yeah, more or less.
That's funny. I think that one of the worst things that ever happened to the frameworks was TodoMVC.
Oh that website that's like the, let's make everything in a Todo app and see what it looks like?
Yeah, it's like a compare and contrast. Oh, that's the most ridiculous concept to me in the entire world.
I don't feel differently, but I'm curious why you feel that way? Can you share?
Well, the biggest thing that I hate about it is it shows a tiny application. Nobody builds tiny applications. Pick the worst technology in the world, you can still build a tiny application in the world's worst--and when I say worst now I'm feeding into exactly what you said is wrong, which agree. But let's say, I'm going to pick on ABAP. ABAP, and if you want to open up a screen, you have to number it. Screens are numbered. You can't even name screens. They're numbered. That's a hard thing to get through. So I'll pick on ABAP. But even in ABAP you can build a tiny app. Tiny apps are not what matters. What matters about a language you choose or a framework is what happens 50,000 lines in with 10 developers. Those things are the things that matter. Outside of that, when you don't get to that range, that's not what TodoMVC shows. It doesn't show that at all. You don't get to see the experience, the wide variety of all the pros and cons and finally realize that no matter what you choose, there's stuff that's going to be awesome and stuff that's going to suck.
I have a minimum bar for creating an app, and TodoMVC doesn't meet it. You know why? That minimum bar is, it must have a save button somewhere. And even TodoMVC, literally, you enter something, and it just magically saves and goes to the database and everything just always works. I'm with you there on that. But yeah, I think you have build larger apps. And probably the bigger thing for me is, shipping code is the most important thing for most people out there working with technology. It's not how beautiful is the thing that I have created today. I wish it was, but we get paid to ship code.
Yeah, absolutely hilarious. They pop up every once in a while, yeah.
Let me pause you there, Joe, and I know you have an opinion as, why is not having types a bad thing?
That's such a beautiful point to make, really, about this. Because the only thing that matters is that we get working code out there. And notice, the term "working" needs to be a little bit vague because, not bug-free, working code. That is by far the most important thing, if the app's out there and it works. I will tell people all day long, you should test. That's been a core belief of mine since the early, early, early 2000s when I first learned and taught myself unit testing and test-driven development. You should test, you should do unit tests. I love Cypress, I'm an ambassador for Cypress. They'll sometimes say this thing of you don't need unit testing anymore.
The island of Cyprus or the technology?
Both. I love the island of Cyprus. No, the technology, the testing tool, fantastic testing tool. I love it so much more than Protractor or other tools that are similar to Protractor. Protractor's probably the biggest, most common one that's out there right now for that other than all the Java ones. But I love Cypress. But they will sometimes tell the story that now that you've got Cypress you don't need unit tests. I totally don't believe in that. But I will say, as much as I tell people all day long, you need to test, you need to learn how to test, you need to how to unit test well and do unit tests and other types of tests. My most successful project that I ever built, and when I say successful it's not by monetary terms but as a developer I felt like it was my most successful project, had 0 tests in the entire code base. Because it was a moderate-size project I built entirely by myself. And knew the code so well, what I was building, that a lot of the value that I got out of the tests. So here's me violating something I say all day long. And so to your point, all that mattered was that I got working code out there and made that work. Adjust the team, adjust the process, whatever, make the code work. So if you don't use types, fine, don't use types.
You think testing makes up for that in a way? Because I'm one of the people, I love types, and I don't say that having no types makes junk code or anything extreme like that. But like the deterministic style of knowing that this piece of data is going to be this type all the way through the lifecycle of programming. If it's not, something will break. However, you can achieve that, as you just mentioned, with tests. You can make sure that that type stays exactly what it's supposed to be throughout the entire lifecycle. So does testing, in your opinion, pretty much eliminate that giant complaint?
I have a strong opinion, and I want to hear what John says to this.
How many lines of code was it?
I don't know how many lines of code, but I can tell you it was 150 developers. So it was really, really large.
So I think that---I'm not disputing this, that there's value. What I'm disputing is that I don't think as developers we ask the question why enough, and I think we should ask it more than once. Why do we want this thing? What are we hoping to get out of it? Where do we want to be? And I know it sounds existential, but when you're being paid to do this, I think it's important to do these questions and do these "what if" scenarios.
So I do have a question here from the audience from David, and it's kind of a long question, but I'll see if I can summarize it. I think it's a good one. So the question is, where do you honestly feel the market is in reality across the industry, as far as older tech, the percentage of older tech versus SPAs, for instance? And it says, if you were to watch Twitter, you see it all as SPAs, you know, everything React, Angular, Vue. However, in real life, like on-prem and _____ in reviews, devs are still doing MVC, Web Forms, things like that. Where do you guys think the percentages are right now?
Yeah, I pretty much echo that same statement. I think the worst place, and this is true regardless if we talk even about tech, the worst place to get information and fact is any kind of social media platform.
Don't make any life decisions based upon a tweet that Joe or I respond to.
I think it's HEY.
We should read Jeremy's section of this at some point to talk about anecdotes about really crazy things we've seen _____. I'm sure we have stories too. You made me think of some.
Yeah. So, again, don't feel bad if you're not doing the latest and greatest. We live in an industry that is resumé-driven. RDD, resumé-driven development. Go out and find the job that's doing the latest framework so that you are marketable. That matters. As a developer you should be considering that and thinking about that but never look at it as a point of shame that whatever technology. If you're still building VB 6, you do you.
Easier or harder, I would say your ability to develop, like you said, push code. That's what really important is pushing code. I think there are certainly platforms as you go down like C++ and assembly language, if I were to write a web app in that, it might be an amazing web app, but it would take me 5 years to do something that either of you two could whip up in Angular in 10 minutes. So when I say easier, I think of immediately easier to learn, easier to push stuff out. That's pretty much the two most important things.
And I think most people would agree with those two ideas. I think both of the spectrum, easier to learn, easier to actually deliver. But let's make up a fictitious program. Everybody who's watching this and listening, if you have questions about it, please chime in with it and we'll answer these. But imagine we just get all tasked, every one of us got tasked to build an app. This app is an order entry app for the web. Now go. Go build it. You've got a month by yourself to go build this. The decisions we each make from front end to back end are going to be dramatically, wildly different across the board. And what will drive us to make those decisions? Experience with those things, comfort level, knowing the confidence that we can deliver in that time frame. Does it mean we use stuff we already know versus new? Maybe not, if we feel confident we could learn something new in that thing. Now let's make it concrete. Jeremy, not knowing anything about your skills on the web, let's say we asked you to build it in Svelte today with serverless with Azure Functions. Could you go do that? Would it be easy for you to deliver and to learn?
I have never even touched Svelte, so I have no idea. I like the Azure Functions idea, so…
Now is that because you know Azure Functions but you don't know Svelte?
That's exactly what I was going to say. The things that I know---but if I were given a choice, I would probably hop into Vue or Angular or something just because it's easier for me. And another question for you is, am I developing it by myself or as a team? Because I think there's a difference there.
What does your team know? let's say Joe knows Angular and you know Vue and I say, hey, guys, we're going to go build this is Svelte today. Is your team experience an important factor? Is it the only factor? No. I guess what I'm getting at is, I think the easy and hard thing is something that everybody should think about. Because learning something and the time to get up to speed, maybe you spend a couple of days. What if I told you within 2 days you could, technologies x, y, and z, learn that stuff in those 3 days, and then build something over the next 6 months that's amazing, versus technologies x, y, and z that you already know and spending the same amount of time building the thing. Would that change the equation to they're both easy then? Really what I'm getting at is, I think asking if something is easy is a trap. Because what's easy for you, what's easy for me, and easy for a learner on Pluralsight, some people might take Joe's testing course and go, that was easy! Another person might go, that was awful. That was the hardest thing I ever saw in my life and I had to watch it 8 times. And I think it's not the skill set, it's not the intelligence, it's not the dedication. A lot of it is just, there's different kinds of learners, different kinds of developers out there.
Yeah, I would agree with that.
Tell me I'm wrong. I want to hear you say I'm wrong.
No, the one after Knockout, between Knockout and Ember.
Backbone. I'm building in Backbone. I discover AngularJS and I'm literally cutting the number of lines of code that I write down by 90%. The new thing takes 10%. To build the same thing takes 10% as many lines of code in AngularJS as it did in Knockout. And I don't know whether or not I considered AngularJS to be easier to learn than Knockout, but it was definitely easier to think about, to conceptualize the framework. And I'm talking about a framework, but languages and frameworks do not have a clear dividing line. Languages, the technology choices that we make matter here. So I do think that easy does matter when it comes to that idea of being able to conceptualize your code. And the team, to your point, has a ton to do with whether what you build is a dumpster fire or not. If you're playing a drinking game, if you're up for playing a drinking game, whenever we play dumpster fire, take a drink. I'll drink my soda here, my Mountain Dew. But, yeah, I do think that matters. I do think easy matters from the perspective not of necessarily easy to learn, but easy to work with, easy to rationalize about, easy to think about, easy to conceptualize, componentize development, that sort of stuff. Some things are better at that than others, and I do think you can almost say objectively they're better/easier.
Yeah, I don't think any of them are easier to learn than others, to be honest. Because I do believe, I've seen people pick up Angular, and they're like, man, this just makes sense to me. And I think, arguably, people say Angular sometimes is harder to learn than React or Vue or Svelte, for example. But I've seen people with Angular, this is just the easiest one to me. And the think the "to me" part is where I'm focusing. It's relative. Everything is relative to what your experience is, where you're coming from. A good friend of ours, Dan Wahlin, an author on Pluralsight, he often tells me about how he used to go do training at companies quite a bit, and I used to do it with him but he's more recent at it, where he would teach folks who were recently in Java or C# how to use things like TypeScript. And they would pick up Angular much faster than they were picking up web frameworks that didn't have TypeScript baked into them because of the typings that they were comfortable with. That doesn't mean Angular was easier; it was easier for them. And I guess whatever I'm getting at is, I'd love it if we could toss out this whole idea of it's hard, it's easy, it's too complicated.
We've got a ton of cool questions that have popped up here.
Okay, let's get to the audience.
Love it, not for me, but I love it for people who don't want to work in the code. Think about all the new people and all the news jobs that are going to be created in the next decades. I sound like I'm working on the West Wing now with Martin Sheen. Think about all the new jobs we're going to open up when everybody can write applications with Power Automate or other tools. I think it's amazing. Remember Microsoft Access back in the mid '90s and how many people created applications who had no technology experience? That's not a bad thing. That's a good thing.
That's another way that social media can steer you wrong. I see a lot of developers railing against no code on social media, and I disagree with it. I agree with you, John. There are a lot of smart people in the world who are not technical, and this bridges that for them. So you have somebody that's extremely intelligent, creative, does great in our field. They've never written a line of code in anything. If they can grab one of these and start solving their problems with it, I think it's awesome. I don't think it's going to get rid of anybody's job or dumb down things too much or any of the criticism you see on social media.
I think I disagree with you two fairly fundamentally on this because---and maybe if I expanded into another point about what it really means to be a programmer. The idea that if you're smart you can build applications given no-code solutions, I disagree with because there's another aspect of building applications that doesn't matter what your relative intelligence level is, whatever that may even mean. But you cannot build applications, low code, no code, anything, if you cannot think through the process, though a highly logical, and when I say logical I don't mean street logic, I'm talking this highly logical. When you sit down as a programmer and you break down, when the data comes in, here's the places where it can happen and here's my trouble parts, you understand what that is like as a developer, if you've been a low-code developer your entire life, as long as you can go through that process that can help. But getting a business product-type person who hasn't done that mental exercise enough in their life to have honed that skill, and I don't know if this is a skill that can be learned or not. I've seen indications on both sides of that that it can be. But whatever it is, there is this process that you need the developer-type mindset to work, whether it's low code or not. And so if you have that, that's why I say, I always say, there's the idea that AI is going to program for us and all that sort of stuff, it's all garbage, or that we're going to make applications that business users are going to be able to now get rid of all developers. I think that's wrong. I think that's foolish. Developers' tooling is going to just get better and better and better. I mean, again, look at my AngularJS example, 10% of the lines of code of Knockout. You can call that low code when you cut down the number of lines of code by 90%, and you can get lower and lower and lower code. But in the end, you still have to think logically about the needs of the application, the user experience, how the data flows, that sort of thing. If you can't think through those things, you're not going to be able to build an application of any moderate complexity.
You have to know your problem. You have to know your problem and how to solve it. But I want to be careful where I definitely differentiate here, and maybe I don't differentiate. But I want to make it clear that what I'm saying is there's a really big tent out there, and right now only, picking a number, 10 to 20% of that tent is full of technologists that are in the industry today. I think there's a huge amount of space in this tent for people who aren't like us, who aren't like Jeremy, Joe, and myself, and others on Pluralsight today, maybe there are some that I haven't met yet on there, but who are the next wave of technologists, who are people who maybe don't write code, but solve problems. Maybe there's new ways and new ideas on how to do it, people who know their business problems well and can follow through using a Salesforce application to create forms to enter their data, process, and do what they need. And that's why I want to get away from, in my mind, that tent isn't just developers, but it's everybody who has an interest and a passion to do it and also has a business problem to solve. That's why I like these tools. And Power Automate's just one example. I mean, these things, there's plenty of tools out there that let people who have not necessarily done technology for 20 years jump right in.
Yeah, absolutely. And I agree to your points, Joe, for sure. From a developer's standpoint, one of us might look at that application and say, my gosh, this terrible. But does it matter if the problem is being solved for that person? If they built an app to where any of us would look at it and be like, oh, that's a giant anti-pattern. That's terrible. But if it's solving their problem every day, does it matter? I don't know. That's just one of the questions. I have another question here. What do you all think of Deno JS? Do you see it as a replacement of Node? I know that both of you have worked pretty extensively with Node and are probably familiar with Deno.
Right. Yeah, no, interesting point.
No, you're supposed to say, no, I'm wrong.
Your criteria of does it have traction? Yeah, there's the big X-45, whatever they are, with traction. But I don't know, when was it, a few months ago, Alpine.js. Somebody's throwing that out. It's a better version of…
Or Redwood, yeah.
Crank, Crank.js. That's another one I saw. Redwood, yep, Redwood. I feel like the CMS scene is going through their flavor of the week phase right now.
With a new headless CMS coming out every day.
But I think you're---at least your point of, are people freaked out about the newest framework that's coming out, is that going to be the next biggest thing? I don't think people are looking that direction by and large anymore. But I still do think there's some possibility that we're going to see somebody come up with something.
I mean, AngularJS did something I don't think anybody anticipated was going to happen. And we haven't seen that---React did not do it. No matter what a React true believer would say, React did not do that to that same level. React just stole some big piece of what was there. But AngularJS just came through and just really dominated new web development for some time.
Agree, Angular did the same thing, because when AngularJS came along, there were literally 50 different tools. I built a what Dan Wahlin calls a Frankenstein framework. I built my own out of nine other tools, Sammy.js for my routing, and Knockout for my data binding, and jQuery for rendering and animations and GreenSock. It was a nightmare to keep 9, 10 things together. Angular was a disruptor, and I wonder what the next disruptor's going to be. Do we know what it is yet?
I don't know that we know what is yet. Is Svelte maybe? Svelte's unique enough compared to the others, but it doesn't seem like it.
But I'll bet you 8 out of 10 developers out there listening probably have never used or touched Elm.
Yeah, probably a reasonable number of them haven't even heard of Elm. So, yeah.
I only know it because of you, frankly, and our conversations offline.
Or is it Deno, Deno?
Is it Deno?
What about WebAssembly? That's actually one of the next questions, is about WebAssembly, but that doesn't really have…
Nope, again, it's another friend who gets invited to the tent, but it's not going to fundamentally change what we're doing, in my opinion.
I thought for a while it could've, but no.
There's a question about, will Web Components replace MVVM frameworks? I think that's an easy answer: no.
Yeah, Web Components. I mean, Web Components is going to save the world, man. They're just, everything's a web component, but a web component, again, is a piece of an app. It's a very important piece.
I would use a quote from one of my favorite Christmas shows, Elf. You sit on a throne of lies, Web Components.
Watched that movie the other night. Love that movie. I love Web Components. And Vue, React, Angular, Svelte, all these things use some. But to say everything is a web component and there's nothing else left over, I don't agree there.
Why? What's hard? What's hard about it?
Hard, hard is quantity of time, like pain. You've had those jobs where you've maintained an application and it was painful. And you've had those jobs where you maintained an application and it was less painful.
I think if you write it in TypeScript it's easier to maintain. I'm going to put that out there, as a general rule.
If I wanted to do something on the server that was heavy computational calculation processes that had a, you know, go crazy on 100 database calls with business calculations and message queues and all that, I probably would use C# or Java on the server. That's what those things do really, really well.
Although, Visual InterDev, it could've been the peak.
Those 1997 tools, man.
Yeah. So here's a pretty reasonable question. Going to do a typical modern app. What tooling do you feel like matters?
I would never enforce tooling on anybody. When I worked at Disney many years ago, one of the early choices we made is, we were talking about what things should we dictate that the company must use, and what things should we allow flexibility on. And one of the immediate things was, bring your own developer tools. You want to use Vim or Sublime or, VS Code didn't exist early in the time when I was there, any of those tools. And we had a list of about 11 or 12 that people were using. It didn't matter. So those are the kind of things---and the reason I say that is, choosing the tool, to me, and putting that, imposing it on a developer is like saying, yeah, you can have a job here, but you have to drive a Nissan Altima to work every day. And if you don't drive---and it's got to be blue. And it's got to be four door, and you've got to drive it this way and come in through this entrance. It's very limiting and constricting. There's a certain level of, we must follow a guideline that you have to have at a company. I do agree with that. But I think you have to give these developers and technologists a little bit of freedom to say, you know what, I can run in vi and Vim, but these other tools just hold me back. Or I love all the things in VS Code. But to me it's bring your own tools.
You're being wishy-washy on this. You're so vague about this. Come on, linting. I'm not saying that you would go into a project and say there's no linting, this is stupid, you people are all idiots. But you're running the team. You are writing the code, you're the lead dev on a team of 10. Do you put linting in? Do you let people say, do you let one developer say, I don't want to lint, I don't care what the other nine people say?
That's a different question. Yeah, if you were going to do something with linting, I wouldn't choose it. I actually had to do this at a large company. Picking rules. So when you go to GitHub, everything matches? Like your formatting style with _____, or your linting, or anything like that? You pick a certain set of those, and you allow for exceptions and deviations with teams. And the teams can do those things, but the key is whatever you check in with those projects has to have the same rules. Because who wants, a great example is, who wants to run a project where every time someone does a pull request every single file in the project is changed because somebody had a different linting setting? I'd just reject it and be like, sorry, no. But do I care that you used two spaces versus four, if it's on the same project? Yes. If it's all on the same project with a linting file? Heck no. Bring your own tools.
Spaces or tab, John? Which is it?
Me? Honestly, I don't care. That's not what I care about. Semicolons, I'm semicolons all the way though.
Semicolons matter. We found John's line in the sand, semicolons.
Which Star Wars character would React be? React is Ahsoka. React is Ahsoka.
React is Ahsoka Tano. Why? And that's the female Jedi, right?
Yeah, yeah, yeah. Possibly my favorite character in all Star Wars, possibly. There's a lot of great characters out there. I think React is Ahsoka. I say Angular is Anakin, and so Ahsoka is what came out of Anakin, trying to take the best parts of what he learned. React was a reaction to AngularJS.
Okay, so Ahsoka was a reaction to Vader, I gotcha.
Yeah. So Ahsoka and who she is is a reaction to Anakin. Look how meta this is getting. This is getting crazy meta.
See I don't think Angular could be Vader because that's Anakin, because he turns evil. I think Angular's more like Obi-Wan. Obi-Wan Kenobi was like this, I'm great at what I do, everything's here, I'm a teacher, I'm going to pave the way. But there's a path, and I'm going to slap your hand if you don't stay on that path, young Anakin Skywalker. And we unfortunately know how well that worked out.
I think Angular's Thrawn.
Now you're getting niche where a lot of people have no idea what we're talking about.
If you don't know who Thrawn is, go read the books. All the books about Thrawn are, they're in my opinion the best Star Wars books maybe outside of the Republic Commando series. But the Thrawn books were great Star Wars books. And he was also in Rebels as well. But I think Angular is Thrawn. Angular's by far the most corporate-y of the frameworks, of the big 5, it's the most corporate-y. And Thrawn was very much, this is about order and structure. The most important thing is order and structure. Feelings are the least important thing. Order and structure matter. He's like Tarkin but without the evilness. Thrawn is just like, we have to have order and structure. The empire's good because it brings order and structure. That's what Thrawn was about.
I'm going to pick Svelte, and then you pick Vue after me. And for me, I say Svelte is an obscure, niche Jedi named Quinlan Vos. And for those of you out there who haven't read the books or seen some of the cartoons or movies, Quinlan Vos was effectively a Jedi who acted nothing like a Jedi. He was extremely powerful, very good at what he did, but he was kind of like the rebel, like the Fonzie from Happy Days, or if you're into that era, or even like the Han Solo was to the original Star Wars series. He's different, very good at what he does, but doesn't follow the same path as everybody else. And that's where I think Svelte is these days. It's got enough of the other frameworks where it makes you feel like those are comfortable. You can come from React, Angular, Vue and so Svelte and see things that make you go, I know that. But then once you get into it, you're like, the way this thing operates, it just dances to a different drum.
Trying to think of the Star Wars character that I think most fits Vue. I'm going to go with maybe Rex from the Clone Wars era.
Ah, a clone trooper.
Yeah, so I think I would've made a really great argument for Ahsoka being Vue. Because similar to what I was saying, I see Vue as what people thought Angular was going to be. When people knew that AngularJS was dying, it was being replaced with Angular, I think people thought Vue, they were thinking Vue in their heads. And when they got Angular, it was different than what a lot of people thought it was, more structured, more process. They added more, they didn't remove it. And so Vue is what AngularJS, what a lot of people wanted AngularJS to become. So you can make an argument that it's Ahsoka, but I would say Rex. Rex is all about, just let's make sure that we take care of what needs to happen and take care of people, and people matter, and comradery. And so I think…
And it's not complicated. Let's just get the job done. That's Vue.
Yeah, yeah, exactly. Yeah, whatever it is, we can make this happen. So that's Vue.
Hopefully we haven't lost half the audience. Hopefully the audience enjoys Star Wars conversations.
Oh, Han Solo, Vue could be Han Solo.
There you go.
I know who Han Solo is, even in my limited knowledge of Star Wars. But is there any final parting thoughts either of you would want to give the audience here before we wrap it up?
And one last final thought, go watch Star Wars.
Yes. Make sure you're watching the Mandalorian. That's good TV. That is good TV.
I feel like that might be directed towards me also.
I'm pointing at you, Jeremy.
Thank you for listening to All Hands on Tech. To see show notes and more info, visit pluralsight.com/podcast.
5 keys to successful organizational design
How do you create an organization that is nimble, flexible and takes a fresh view of team structure? These are the keys to creating and maintaining a successful business that will last the test of time.Read more
Why your best tech talent quits
Your best developers and IT pros receive recruiting offers in their InMail and inboxes daily. Because the competition for the top tech talent is so fierce, how do you keep your best employees in house?Read more
Technology in 2025: Prepare your workforce
The key to surviving this new industrial revolution is leading it. That requires two key elements of agile businesses: awareness of disruptive technology and a plan to develop talent that can make the most of it.Read more