Andreas Møller: So the name itself was a bit problematic, because Toddle is sort of a relation to toddlers and toddling… Which was actually a joke name my wife came up with in the very early phases. Because when I started working on this, I had no idea if it even could work. There was a part of me that thought “Since we don’t have these kinds of tools, there’s probably a really good reason why, and I just don’t know what it is.” But I had to try and figure out, so I kept working on it. And to some degree, when it came up, I’m like “That’s kind of what I’m doing. Right now I’m trying something, and then I’m falling over, and then I’m trying something else…” I’m like “Yeah, okay, let’s call it that.” And then as it started working and we kept referring it to Toddle, and we kept going, eventually then VC investors came in, and then we had to talk to all of those, and that was a bad time to change the name… There was never a time to change it after that. We’re not going to sit down and come up with the best name, because it’s like, it was fine.

And there’s a certain truth to the fact that a name is whatever meaning you give it, eventually. So had we kept the name, eventually Toddle would just mean our app, and it wouldn’t matter, because that would be the ideas people had. But we could feel it was holding us back a bit from anecdotes from customers. And at the same time, we couldn’t get a dot com… It’s hard to search for, because we get so many other results… So there’s a lot of small things about the name that wasn’t so good.

So when we realized that we needed to make a branding pivot away from being a no code tool, and a more professional tool for beginners kind of thing - which is also a weird phrase to say out loud - we said “Well, let’s take the name away as well.” Because that at least – everything will still redirect to the new site. But when people, say, think like “This is what I think about, Toddle”, versus this tool that you really have no reason to compare us to, because we serve completely different sets of users… And a lot of that is sort of existing conversations we could actually a little bit leave behind. And that was very intentional. So we wanted a brand that sort of highlighted that this is meant to be for professional teams, it’s meant to be for developers who know what they’re doing.

Tomek Sułkowski: Yeah, me too. That was so cool, to remember these things. But anyways, so he built this amazing tutorial. And if you look at any of his talks, actually, YouTube recordings, any demos, he’s using that tutorial himself as a starting point even to demo specific parts of the framework. So it’s not only for beginners and people who are just onboarding into the technology, but it’s also for like an advocate as himself.

So it’s a very, very cool concept, a cool tool… But now, if you know anything about Svelte, the most common way of using Svelte is by using SvelteKit right now. And SvelteKit has a very significant backend player. So now we’re kind of coming back around to web containers, because it was kind of impossible to build a new tutorial for SvelteKit without having the Node aspect. So Rich Harris reached out to us and asked if there is some way of using web containers outside of stackblitz.com.

Adam Stacoviak: “Teach me tmux. Getting started with tmux. Tmux for beginners. Why should I use tmux?” All those tmux phrases… Yeah, I agree, you have to think – this is part of user experience, though. This is part of product development. This the problem of all products, it’s the problem of all I guess startups, really, is like “How do you capture the attention?” Well, you have to think like the user. You have to talk to some people, you have to go on some podcasts. You’re doing that great. No problem. Good job. But you have to title and think like – and Jerod and I maybe don’t do this very well. Right? Do we do this very well?

Nick Nisi: Alright. Well, first off, Amy, you said that there’s a beginner argument that you want to keep things simple to make it easy for beginners. I agree 100% with that, but I think that that’s more of a DX story and not a case against build steps. Why does the build step have to be difficult? It could be easy, and we could make it easier, and make the tooling easier.

Kball, you talked about we have this magical world of evergreen browsers, and we don’t have to think about that… That works really well if you’re in this Chromium bubble, I guess… But even if you want to say that every browser is perfect now, we have this other problem where we’ve regressed on the backend. And now we have all of these backend steps. And do you know how to use modules correctly in any given instance? I don’t. I want a build step to wash that away for me. And so I just need that.

Plus, build steps give me this superpower where I can write this condensed or terse code, and have it magically spill out to be real code. It’s the real 10x developer. It makes me the 10x developer, and I want to embrace that. And then I’ll just drop my mic right here with the word TypeScript. [Wut?]

Zach Leatherman: Yeah. 11ty is a static site generator. It’s maybe one of the simpler ones that exists right now. It really allows a very simple on-ramp, an easy on-ramp for beginners, and we try to keep the beginner experience as streamlined and simple as possible. So we’re sort of known for – because we’re sort of a reduced feature set from the beginning, and you sort of add things on top of it later, we’re sort of known for our build performance. And that’s probably highly related to the configurability there. So you can have a very speedy build to build your site, and the output that you can get is also speedy as well. And I think for many years, that was a controversial thing. It’s nice to see that that’s changing… Yeah, and there’s more HTML-focused tools, in the JavaScript ecosystem at least.

Johnny Boursiquot: Interestingly enough – so let me preface this by saying, I’m not a… So training or doing workshops and things of that nature is sort of a passion project, if you will; it’s something I do sort of on the side, because I truly enjoy it. It’s like the way – like, when I’m off the keyboard, that doesn’t mean I don’t want to think about programming, or engineering, or Go, or whatever it is. It just means that if I’m off the keyboard, if I’m teaching it, because I love these things, it’s a different modality for me. I’m not engineering software, but I’m teaching engineering. So I’m not a professional day job – that’s not my day job as a trainer. So that’s sort of the context for what I’m about to say.

I have noticed that at times, professional training companies or professional trainers, they may sort of structure, or they may describe what you’re about to walk into as an all-inclusive, sort of all-encompassing, like “You will learn all there is to know” kind of thing, thereby setting the expectation that “Oh, I’m a beginner. I don’t even know how to launch my shell. But this thing sounds like it could be good for me, because it’s all-encompassing. It’s gonna cover all the things.” So you go in, and there’s some assumptions already being made from the trainer’s part about the level of everybody. But it’s communicated in such a way that it’s unclear, or it should be clearer what your own level should be before you walk into such a session. But because whatever the incentives are - maybe it’s pack the room, get as many people to sign up as possible, or whatever that is, the optimization is being done for sort of the number of butts and seats, as opposed to “Okay, rather than having one big eight-hour-long session…” And I say this, because I have been part of, I’ve had full day long workshops where some of the feedback came into me and basically said “Hey, I love the training, I love the sessions, but I was a little bit more advanced; it would be great if you split this into two, and basically it gives me the option to say “Oh, I don’t need the first half, I only need the second half, because I’m already at a place where the more advanced stuff is more useful to me.” So that’s the feedback I’ve gotten. So when I do the full day, eight-hour thing, the optimization is for “Well, let’s get as many people in here as possible.” But the objective is not to get as many people in the room as possible, at least when I teach; it’s not to get as many people in as possible. Thankfully, at this stage, I’m at a point where when people come to me, they know what to expect when I’m teaching; they know they’re going to have a good time, they know they’re going to learn a ton of things, and they know my teaching style is very hands on. So I don’t talk at people, I get them to do stuff, and we work through things together kind of thing. So I don’t have to advertise and say “Hey, come” to get butts in seats.

[18:16] So now the challenge becomes, okay, how do I structure and how do I communicate the topics I’m going to cover? How do I structure the things that if I need to have two separate workshops on a given day, whereby the first half is for beginners and intermediate, and the second half is advanced, then I’m going to tailor it and I’m the language I use to describe it is going to sort of articulate that; it’s going to basically say “Hey, if you come in here, this is what to expect. I’m not going to teach you how to run your shell, because this is not what this is about. This is what you should come in with. Have these things installed. Have this configured. You have gone through the Go tour”, or “You’ve been doing programming for a couple of years, or you’re just picking up some Go?” These things, these hints you sort of put out there - people will self-select. And that enhances the chances that when they sit down in your workshop, they’re going to have a much better time, because they are targeted. They are the people that are supposed to be in that seat, so they can take advantage of everything you have to teach, and you don’t have to feel like “Oh man, this person is on the beginning end of the spectrum, but I have a ton of people on the complete opposite side of the spectrum. Now I have to sort of balance and try and be all things to all people”, which is incredibly hard. Whenever I do that, whenever I try to be all things to all people in a classroom, that’s when everybody suffers, myself included, because I’m like running ragged, trying to make sure “Oh, do you understand this?”, trying to make sure you pick up and catch up… And then the person at the other end is bored. So you want to avoid that.

Kevin Ball: I mean, a lot of this, it strikes me as sort of the classic - I think of it as an Adobe problem, where you have these expert users who are trying to do really complex things, and you support them really, really well at the cost of your product, or in this case framework, becoming much harder for beginners to adopt and understand. And Mark, to your point, Angular has always been the batteries-included framework. They give you everything. And there are pros and cons to that; that’s often – or that hasn’t been the JavaScript community’s approach to many things, sometimes to their detriment… But definitely, it has made Angular this kind of choice that often makes sense if you’re in an environment where you don’t want to be making all those choices, you just want a standard. You want a norm, you want people to be able to come and go and understand how the pieces are going to work, like a large enterprise, or something like that.

[00:40:20.07] I do think there is this interesting balance that you’re talking about, of supporting those users and their needs while making the onramp easier for folks. And I think there’s something – there’s a whole thought process there I’d love to dig into… But before we go down another road, Amal, what did you want to cover with Mark?

Filippo Valsorda: Oh, Joe is an even simpler and more for beginners version of –

Jerod Santo: One thing you said at the beginning there, Steve, was that it’s more about where you run it, because we have all this code we talk about the copy and paste thing and the dead code on the internet… And I think that’s really powerful, not just for beginners, because I definitely think that mindset… I used to teach coding bootcamp-style web development 101, and getting people set up and running, and troubleshooting environments was such a time suck for that. And that was full stack, it wasn’t merely in the browser, frontend. So Val Town and other options like it are just a boon for teaching people and getting people started. Most of them, like we’ve been talking about, are frontend oriented, whereas this is more of a full-stack serverless option.

In a way it’s really cool, because on the website you have some use cases right there on the homepage that even though it’s great for beginners actually speak to longtime developers as well, because there’s certain things that we have to do, and it’s easy to code those things up, but then the question was always like “Well, where is this going to run?” And then we all have our solutions, like “Well, maybe it is on Lambda, because I already am an AWS expert, and I can just get that thing going.” Maybe I have a VPS that runs Linux, and I put all my random crap on there… Maybe I have a few strewn about; you know, home network, home lab… All these places. I have some cron jobs that run on my laptop. It’s not a server, but it runs most of the time, and so I just cron job on my laptop, and I let it run things. But then we ask ourselves, “Well, how do I email myself? What’s the easiest way to get myself a notification?” And I’ve been doing this lately, looking at like “Well, how do I push-notify myself reliably, from anywhere in the world, on a script?” Just like pipe it into something that sends it to a thing, versus me having to do a bunch of other things to get something done. Just like simply set up something small that scratches a particular itch.

And you have cron jobs, you have email yourself… So you have scheduled, you have notifications built-in… And for me, as an experienced developer even, when I think about where, it’s just like “Well, you just throw it on Val Town.” I have an account there, throw it on Val Town, and let it email me. Schedule it with Cron. And so I like that that focus is there from the beginning, where it seems attractive not just to people trying to get started, but also people just sick of having to manage where their code runs all the time. So I have a bunch of stuff that I could easily port, being it’s JavaScript and TypeScript… I could just create a Val Town account and start moving stuff up there, and not worry about “Did that crontab run because my laptop is closed?”

Kris Brandow: Yes. If we want it to be unpop, the quick bit is “We should be making it harder for beginners”, and I’ll pause there, and that I will continue “by making it easier for people that are already established in the industry.” And I do think that’s a trade-off there. I don’t think it is as simple as we can just invest in the more advanced stuff. I think the nature of doing that will likely make it more challenging for people that are just getting started, as we shift toward these more complex things. After going through even just a little bit of CCNA, I’m like “Yeah, no, every engineer should sit down and go through this stuff. They should understand how networks work.” That is, I think, a very daunting task for someone that’s just getting started in software engineering. But I think we’re building network systems all of the time. I think it’s important that we know.

I think there’s other spillover too that I think people probably won’t like to have to confront. One of the realizations I’ve made in the past couple of weeks is that there is no such thing in the modern day of non-distributed programming. All programming we’re doing is distributed systems; just the thing that people usually call distributed systems is too narrow. If you’re programming on a machine with multiple cores, and you’re using mutexes, and atomics, or goroutines, or any of that, you are doing distributed systems programming. And there’s distributed systems literature that directly addresses this. [unintelligible 01:33:09.04] which is a very famous concept that gets talked about a lot, and a lot of things databases try to achieve. That’s actually a model for shared memory, which is a model for processors, multiple cores of your processors, that talk to the same main memory module, and making sure that all of that is synchronized. And so you’re using linearizable systems every single day, you just don’t get to see it. But we hide a lot of that, and we just don’t teach people that; we don’t frame it like that. But we really should be framing it like that. But once again, that will make it more difficult for beginners.

Travis Fischer: Absolutely. One, it’s super-noisy. There’s so much happening. We’re in the middle of this exponential wave, and I think a lot of people are like “Oh, I have FOMO, I want to be on this wave. But where do I start?” And there’s just so much noise. Which is great on the one hand, but on the practical side, how do you give it life? Where do you start?

So there’s a couple levels to this. I gave talks to kind of like a ChatGPT for beginners type crowd, and really, my main advice is one, just use it, just go in and try it. That’s simple. But two, more importantly, the next time that you have an actual problem that you think like “Maybe I could use Chat-GPT or a language model for it”, actually try using it to solve your own problem. Because what that does is it starts to build up this muscle in your brain around thinking about using these new types of tools to solve problems. And it’s really a different type of tool. It’s like exercising; you need to start exercising that muscle early and often.

And there’s a lot of noise, there’s a lot of different AI tools. The side of things which I’m confident will be just as relevant a year from now or a couple years from now is building up that muscle to think about how to actually use AI to solve your own particular problems. It’s one thing to talk about hypotheticals and general cases of problems where these tools excel, but it’s another thing entirely to start building your own personal muscle.

Christof Henkel: There are like two aspects, I would say. One is like software-wise and framework-wise. There has been a lot of progress there. So when I started, it was still like TensorFlow zero point something, which was working, but it’s really like low-level programming. So there was nothing like an RNN layer, or a transformer layer. You needed to code everything from scratch. But that also helps a lot for understanding the things. So I think nowadays people don’t really understand the granular aspects of deep learning, because you just do something like “model.fit”, and they don’t have any clue what’s happening behind the curtain.

So certainly, it’s easier nowadays to train a model just by these higher frameworks. Just calling by name, there’s not only stuff like Keras, PyTorch Lightning, there’s like a lot of different frameworks you can use, which are really high-level and accessible for beginners… And there’s also a lot of training material for these frameworks, so a lot of tutorials… So it’s really easy to train a simple model for a simple task. But also in terms of resources, I think they are more beginner-friendly, because on Kaggle, for example, five years ago they didn’t give you any resources. There was no Google Colab… So you basically had to have your own GPU at home, you needed to build your own desktop machine or something, or spend your own money on cloud resources… But now, for beginners, you can get access to Colab, which gives you a free notebook to experiment, you get some free resources on Kaggle, there’s a lot of student credits and student programs… So it’s really easy to start your data science journey, I would say. And there’s also a lot of more material online where you can really teach yourself, I would say.