Paul:
Hi there and welcome to PodRocket. I'm your host Paul, and today we're very fortunate to have Omar Mashaal with us. How are you doing, Omar?

Omar Mashaal:
Good, how are you going?

Paul:
Well, I'm excited to have you on because we're talking about a brainchild of yours, a masterful product called Ultra. So Ultra's a web framework, right, very simply put?

Omar Mashaal:
Yeah, that's correct. But I think the one thing that really sets it apart is it's built Deno first, all with React 18 and some of its new features that were recently released.

Paul:
So, we just had a podcast a few days ago where we had somebody that works very heavily with Deno and this was the first step, foray I've ever personally had learning about Deno and really some of its benefits. And it seems like a very strong candidate in a lot of ways to surpass Node and a lot of reasons why I would use Node. What is the number one reason why you used Deno? Is it something you already love and you came into it, is this the first time where you want to build something serious with it?

Omar Mashaal:
Well, I guess I've been using Node for many years since I don't know, maybe seven to eight years now. And I was one of the first people to jump onto the whole experimental modules and really try to embrace ESM moving forward. And for years, I was using it with Node in the experimental way and I always found it's been a slow progress to get to where we are at this point, which is still a Node, it's still a bit iffy, which direction it's going. And we do see a lot of pushback around a lot of library supporting ESM and moving that forward.
And when Deno came around, I think maybe about a year ago, I jumped into it full force. And the really great thing about it is that it is ESM 100% by default, it has a lot of really neat things like test runners, linting, formatters, all baked in. And prior to this, it would take me 45 minutes minimum to set up Node on a new project to make sure it's working to the standard. That's what Deno gives you out of the box, as well as give you some niceties around TypeScript and JSX support out of the box as well.

Paul:
But Deno's not like, that's just like cool thing, you used it, it's like this new flavor that has all great things out of the box. But the big cherry on top that I took away when I was reading about your work is you're unbundling the web, that's like the catchphrase, right? Do you think you could step into that a little bit? What does unbundling the web mean?

Omar Mashaal:
I think the industry at the moment is really leaning more and more into bundling and code splitting and all these really complicated things that I find that when ES6 first started becoming a thing, a lot of my friends who I worked with, we were always talking about how exciting it would be when we could actually just write ESM without any translation bundling magic required. You could sort just write ESM, write your imports, all have it working of like the old school web, how we would build it back prior to this big kind of push towards a complicated bundling and weird syntax and so on. And I think as of maybe the past year, it actually feels like this browser support and you can hit that point right now if you really want to. And I think that's sort where I wanted Ultra. That's sort of why I was driven to create Ultra is to try and lean into those native browser features where it is serving vanilla ESM.
We don't bundle your components. So however you want to set your project up, you can set it up to your liking and it will actually be served in that same sort of structure that you write it in. Which I wanted to try and be very unopinionated about all of that. There's no magic directories that you have to set up that do certain things. You write your code and it gets served as ESM, however you want to format it or structure your project. So it's not 100% where it's running completely non-transpiled code. You could still use JSX and TypeScript, but that's sort of a decision we made because that's what Deno supports as well.
We wanted to try and meet in the middle ground where we're supporting all the stuff that Deno gives you out of the box, but also trying to push some of these native features. So I guess that's sort of why I'm interested in the non-bundling aspect of the web and because it's a native thing that browser support. And if you utilize things like service workers, for instance, or the preload headers, you could kind of alleviate the waterfall request that could come through. And I do see a lot of people concerned about the waterfalls kind of slowing down loading, but I kind of see it as a way to natively code split your project. Only you don't need to have these really fancy code split bundles that sort of work in some instances, but don't and you're always downloading extra code. This sort of allows a native code splitting.

Paul:
So if I could ask, when you say waterfall, do you mean the display we all love in the developer tools are kind of the development style of having all the requests flush through at the beginning?

Omar Mashaal:
Yeah. Yeah. So if you don't bundle your ESM and you serve ESM and you have a nested chain of imports, if you do open the network tab, you will see the first one get requested. And then the second one and the third one and so on and so forth. Yeah. So it's really how the network loads all of your ESM modules. It's a complicated subject that Ultra's sort of unopinionated in that regard, where you could control that and handle that, however your project needs it, I guess. And we found some really good use cases where utilizing service workers, you could actually just serve your unbundled modules and future requests. That'll always be served from the service worker case, which I think is really neat. And it's kind of fun to look through the inspector and you actually see your unbundled modules that you've written and they're quite readable too, if you're doing source code. I saw a meme the other day where people were complaining about, you can't read source code anymore. Cause it's all these weird bundles where you can't. It's really archaic and stuff. So yeah, ultimately I would love to see the web where we could actually write source code and run it and Ultras are trying to bridge that way.

Paul:
Enjoying the podcast? Consider hitting that follow button for more great episodes. So one argument about the complexity of why things are complex, cause things are pretty complex now. It feels like we're getting new features and new this new, but yet things get more complicated as we're adding these things on. I mean, one example that is hotly contested, on medium articles I'll find sometimes, is the whole single sign on Google off ecosystem, right? It's like, it's great. There's a lot of fine grain control, but that also is of forcing Google into the monopolistic position that it's in right now. Do you feel like the complexity of the technologies and the features that are being developed are sort of pushed and enforced by the proprietarization of larger companies and taking us away from grassroots and true development knowledge?

Omar Mashaal:
Yeah, sometimes I feel like the web that people are pushing us towards is really to give certain companies more power and make it easier for them to make money for some of the products that they're pushing. And I think we find that with some of these edge providers, serverless platforms, you're writing code that isn't really browser or even server native. You're finding yourself having to weed through weird documentation where some of these ed providers, serving static files is actually really tricky and I've tried CloudFlare workers, Deno Deploy for sale edge, and they all have really different ways to serve static files and serving static files and the old school web was probably the easiest thing you could do. And to me that seems a bit weird that we've come so far with making these really fast run times and really complicated serverless frameworks and so on, but still Sterling a static file is really quite hard and it seems to have really flipped its head.

Paul:
You end up writing code, it feels like, sometimes when you're working those environments that isn't owned by you in the end. What are you going to do with that? If you own a piece of code, you know how it works, how it runs, and what oil it takes to burn. And it just feels like we're kind of being brought a little bit further away from that, especially as you said in the serverless world and stuff. So the general bringing us back to your work, the general thought of unbundling the web, I feel like, is really enticing. Cause it is bringing power and understanding back into the hands of the developers in some ways. And this whole question got prompted from you mentioning, "Wow, we go into the developer tools and it makes sense." It's all there. It's laid out it's developer friendly, which is, it's just really cool if you don't see a lot of that these days.

Omar Mashaal:
Yeah. I mean, I would really love to see the frameworks and thoughts and whatever else that gets created, more focused around what the browsers can do. Service workers have been a thing for years now and I don't see a lot of talk about it. And import maps are now supported in, I think, Firefox Chrome. I think even Edge supports it. So I think Safari is the last one to do it, but Import Maps it's still... my friend did a talk at a meetup around here and I think he asked if anyone has heard of Import Maps and there's three people out of a room full of 120 or so.

Paul:
Do you want to inform some people right now? What are they?

Omar Mashaal:
Yeah, yeah. So I mean, Import Maps is something that is becoming a web standard. As I said, it works in Chrome and Firefox and Safari has it on the radar. There's a poly fill that you can use that will make it work in Safari. And Deno supports them as well. And Import Maps are sort of a way to define some of your dependencies. It sort of lets you specify their specifiers and point them to a certain URL. So we use ESM.sh, which is a sort of ESM CDN that will actually let you use a lot of the MPM repositories and you could pop an ESM.sh into an Import Map and that way. So if you have an Import Map with React, for instance, you could say Import React from React, just like you would in a normal MPM project, but what Deno does and what the browsers do is say, whenever you try to input from react, you're inputting from that ESM that I sent URL.
And I think that's probably the iffiest point around Deno adoption and a lack of understanding and a lack of how it works with MPM in general. And probably the biggest hurdle in adoption in my opinion is it is quite unclear. And you do have to sort of experiment a bit with it, but there are some neat products coming out or platforms that will allow this to be a bit easier. I think JSPM, I think is what it's called. They let you create your own Import Maps for you. So you can kind of add all your dependencies and it gives you a little chunk that you could copy and paste and put in your project, but it sort of replaces package that [inaudible 00:13:31] on and how you handle your dependency management.

Paul:
So speaking of imports, the most common way, because we're talking about the state of the web and packages and maps and stuff like that, but let's also talk about your thing, Ultra. Because it'd be great if some people can learn about this and visit your site and start toying with it, if they haven't before. And the number one way to get people onto a new web framework or make them comfortable trying it out is talking about React. Can we integrate React with it? How do I get started with React? What do you say to those people that are looking to venture through that medium into your work?

Omar Mashaal:
Oh, well, I mean, that's sort of why I created it. It's React first and yeah, I was using Next for many years. I still do use it quite a bit and I'll try one. I wanted Ultra to feel kind of similar enough to that sort of world where you write your components in a very similar way. I think coming from someone who uses Next a lot, it's not a huge, once you get your head around Input Maps and some basics around how the project is set up, I think you'd be able to kind of find it right, quite comfortable. There's nothing too vastly different from Next. Besides we don't do file based, was is it? FS Routing, I think is what they call it. Back on the unopinionated route, we didn't want to force those sort of paradigms on you to set it up however you want. We use a router called Wouter, which is really great, a really tiny React native router, not React native, but the React library. It's really simple to use and it's fully compatible with Wouter and we handle some of the more complicated route in that way.

Paul:
Oh no, that's right. So it's pretty easy to get set up basically, if you want to get into it, especially if you've been in an environment like Next.js. That's the takeaway here, right?

Omar Mashaal:
Yeah. And if you check out the repo, we have a repo called Create Ultra App, which gives you a super basic one page with routing and head management sort of stuff, all baked in for you. So you can kind of just clone that repo and run Deno tax start and it should just start working.

Paul:
That's going to be huge for people. I mean, that's what got me into Next.js is the fact that there was Create Next App.

Omar Mashaal:
Oh yeah. They're great at that. Yeah.

Paul:
So there's create? What it called? Create Ultra App?

Omar Mashaal:
Yeah. Yeah. I just tried to lift the name and convention from everything else.

Paul:
Perfect. Yeah. I'm sure that's going to be really useful for folks wanting to step into it.

Emily:
It's Emily again, producer for PodRocket. And I want to talk to you. Yeah you, the person who's listening, but won't stop talking about your new favorite front end framework to your friends, even though they don't want to hear about it anymore. Well, I do want to hear about it because you are really important to us as a listener. So what do you think of PodRocket? What do you like best? What do you absolutely hate? What's the one thing in the entire world that you want to hear about? Edge computing, weird little component libraries, how to become a productive developer when your WiFi's out? I don't know. And that's the point. If you get in contact with us, you can rant about how we haven't had your favorite dev advocate on or tell us we're doing great, whatever. And if you do, we'll give you a $25 gift card. That's pretty sweet. So reach out to us. Links are in the description, $25 gift card.

Paul:
So if somebody was stepping into your framework for the first time, besides from the mental shift, stepping to Deno, what is one of those things they'll have to grapple with changing their mental model to using the best features of what your framework, Ultra, is providing?

Omar Mashaal:
Well, I think besides being a React Deno framework, there's a few things that Ultra kind of set out to cater for. And I wrote at the time, when React 18 was still in an alpha state and I was really kind of interested in how the streaming side of React 18 working, which is one of the big features in React 18, which I still don't see a lot of other frameworks talking about too much. But basically what it does is it sends your service side rendered page as a streamed response to the browser. So what's sort of neat about that is that it uses suspense quite heavily in terms of how we do data fetching. The neat thing about Ultra is that you could kind of request data anywhere in the tree. There's no concept of pages or top level data fetching, which kind of filters down through the rest of your component tree.
You could kind of wrap the suspense blocks anywhere in your tree and make requests for data. And the react streaming server kind of will make those requests as the stream has already sent to the browser and will server side render those bits through the stream as it resolves, which is probably one of the key features around Ultra. We don't support the traditional rendered stream methods, because I was really fascinated with how data fetching works in this new kind of post suspense world. And so that's probably the number one thing that really differentiates it from everything else is that it's really trying to lean hard into the streaming side, which I still find quite interesting.

Paul:
Do you take advantage of your own implementation of the best practice of doing streams or are you stepping into the HTTP 2.0 world?

Omar Mashaal:
Yeah, so I think it is all HTTP/2. We do recommend deploying with that. One of the things that version one that's currently the published version uses is Use SWR, which is a Vercel library that sort of handles a lot of data fetching in all these different edge cases around when things reload when they don't. And that's something that handles suspense quite well. Until recently, I think they've made the choice to not support streaming server side rendering anymore. So in version two, which we're not very far off of launching, we actually have our own sort of suspense fetch wrapper, which lets you kind of utilize server side render its streaming responses with.

Paul:
So, I mean, when you're using HTTP 2.0, it is a pretty significant speed boost you're getting. Because it's, A, over a stream. That's the number one thing. Do you think this is going to change the way we're setting up websites, because I feel like as we're moving more towards a server side render it's like the bigger your server is and the more you creatively and selectively and correctly put things to flush out on the server, the faster your site's going to be. It's that simple. And so are we going to have larger and larger server deployments beating smaller and smaller websites? Is that going to be a trend you expect?

Omar Mashaal:
Yeah, it's a good question. I can't really say for sure. Yeah. The thing I would like to see is that we have the options to choose which direction we want to go. And I think that's something I really like that's happening in the industry now, especially with Deno and Bun, is that there's a lot of different ways to do things and they're not the kind of tried and true throw anything into this magic box of web pack and ES build and everything and it just sort of spits out these things that browsers seem to have become a target that you build to rather than something that you natively try to build for, if that makes sense. So I just do hope that is something that becomes, even if it's not the number one most popular way to build a website, is I just hope that there's a small community that is interested in this sort of way of thinking about it

Paul:
And continues the research and development on it. Yeah.

Omar Mashaal:
I mean we don't need, every framework tries to be the end all be all. It does seem like a bit of a popularity contest sometimes and Ultra did have a bit of a wasn't massive, but it had much more of a kind of hype rush than I was really expecting. And there was a real big kind of urge to try and tick every box that Next.js does or Remix does or so on. And it's just something that it's really easy to get caught up in. And I think moving forward for version 2.0, I think we really want to try and lean into this simplicity more rather than making it more and more complicated as things go on. Ultimately I would like to remove more and more codes. So you're actually just using native browser features.

Paul:
I mean the time in human history when we really began to explode as a species is when we became specialized in artisanal. So there's something worth to be said there instead of being the end all be all.

Omar Mashaal:
Yeah. Yeah. There's many ways to build things nowadays, which is nice.

Paul:
So if I wanted to create a component today in your framework, what could I expect to run into? What's the first five minutes of making my Hello World component?

Omar Mashaal:
Well, I mean, if you start from the Create Ultra App, it kind of gives you one main app.TSX file, which sort of contains your top. What would we call a top level component where it has your router? So, I mean, if you wanted to make a new component, you could either do it straight in that file or create a new file anywhere in the SRC directory and just import it just like you normally would with any other project or tool. It supports TSX JSX out of the box. So you shouldn't run into any problems in that regard. And yeah, that's really it. There's no sort of special syntax that you have to write when you're writing the component. It's all just traditional TSX.

Paul:
Awesome. So not too much to think about. I feel like one of the biggest hurdles of somebody stepping into this honestly, is, I mean, Deno's new and you search up things and you have to reorient your whole mental model about, okay, we're trying to work with natively, broader browser supported features. We're not trying to bring in a giant transpiled Web pack monster. So I have to rethink about the way I'm developing and what modules I'm using and how I'm using them. What is one way, maybe stepping outside of just specific framework talk, what is one way somebody who's coming to this development space can help sift through like, oh, I'm searching up, Googling this JavaScript answer. And I don't know if it will run here or here, is there some resources that help give that focused approach of tooling?

Omar Mashaal:
The thing that I always try to steer away from is just searching through MPM as soon as you want to do something that's even mildly complicated. You kind of have to be a bit more choosy around some of the modules or dependencies that you use. I mean, ultimately I would love to see ESM compatible packages being published to NPM and other services like that, which I think is becoming more and more of a trend. But I mean, you will run into issues even with ESM.sh, where you're trying to import something that's been written with CJS from NPM and it just doesn't work because of some weird compatibility issue with ESM, really. So I mean, what I find pretty neat about an Ultra project is that it is quite low dependency. There's only a handful of dependencies that you're using when you're building a project from scratch, where any of these other frameworks around here, you look at the no modules folder and it's absolutely insane how crazy it is.
And that's just like with nets with nothing that's like with a blank project, pretty wild. But with Deno, I think specifically, you can make these really robust, modern, neat service side rendered, client side routing, client side transitions. You could do it all with very little. And I think that's one of the most exciting things. And I guess if you're a developer who just wants to be able to throw in anything that you could find on MPM, Ultra's probably not going to get you the most mileage out of it. It's really for, if you still need to take care in that regard. And it's mainly because the ecosystem hasn't caught up to being fully ESM compatible yet, especially a lot of react ecosystem.

Paul:
So yeah, definitely paid attention when you're bringing down packages. I mean, one thing I know I've done in the past is taking down a package and been like, all right, I'm hard forking this. There's like two spots where I need to change the import. I'm going to change it real forward.

Omar Mashaal:
Yeah. Yeah. I mean, that's a thing. I do think the tide is finally turning. I mean, ESM support and Node has been taking so long and it's still a hot topic of debate. I see a lot of really popular packages and I think even Node Fetch, a few months ago, they went to all ESM and they broke thousands of projects around the world. And I don't know, it should have happened a long time ago if you asked me, but it's good to see that it's happening now. And I think the new GraphQL is going to be all 100% ESM, which they're releasing soon. So it's all happening. And I think that's going to make Deno usage in general, a lot better or easier. And I think that's the future that we have to look forward to. And I get excited about that.

Paul:
I can tell you're excited about that. We just got a visionary statement about the Node Ecosystem from Omar. So we're kind of running up on time. I did want to mention one thing about GraphQL. I recently found a project. It kind of blew me away, cause I've always been frustrated. Are you familiar with Bull JS?

Omar Mashaal:
I don't think so.

Paul:
Okay. It's a queuing system, but it's only in JavaScript. You can only address it with JavaScript. It runs on Redis, but somebody made a GraphQL rapper for, and it's like, wow, it's amazing. I can talk to it with any language now. I've just been very excited over the past 24 hours about this finding, but yeah, we're running up on time. Omar, it was really cool to learn about Ultra. I think this is one of the more unique kind of frameworks that we've been able to delve into and talking about the future of Node development. If people wanted to learn more about you or follow your work or things, do you post anywhere or do you have a social that you like to give out?

Omar Mashaal:
Oh yeah, I posted a bit on Twitter about this stuff. We have a Discord channel, which someone in the community recommended me opening a few months ago and it's pretty cool. We have, I think 50 or so users that come in. So if you do want to dive in or have any questions, the Discords probably the easiest and most useful place to go. That can be found on the Repo homepage. I think it's on there a few spots, but yeah, join the discord and you could ask any questions and we kind of keep everyone up to date as much as we can with things that are going on.

Paul:
Great. And if people wanted to visit the docs, do you know the website URL off the top of your head?

Omar Mashaal:
Yeah. Ultrajs.dev. That will take you to the project homepage, which will have all the information.

Paul:
Awesome. Well, thanks again, Omar for your time. And for letting us pick your brain about what's happened in the development world.

Omar Mashaal:
Cheers. Thanks a lot.

Emily:
Hey, this is Emily, one of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you, there would be no podcasts. And because of that, it would really help if you could follow us on Apple Podcasts so we can continue to bring you conversations with great devs like Evan You and Rich Harris. In return, we'll send you some awesome PodRocket stickers. So check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcasts.