Our Terms & Conditions | Our Privacy Policy
In this conversation about the evolving landscape of front-end development, Natalia Venditto, principal owner of JavaScript developer experience for Azure and Code extensions at Microsoft, and Igor Minar, senior director of engineering at Cloudflare, chat with Kate Holterhoff, senior analyst at RedMonk. In addition to discussing the future of JavaScript, the significance of server-side rendering, and the potential of WebAssembly, they speak about the challenges of migrating from client-side to server-side architectures, the role of micro frontends in managing organizational complexity, and the importance of open source foundations like the OpenJS Foundation in ensuring sustainable development practices. The views and opinions expressed in this podcast belong to the speakers, and do not necessarily reflect those of their employers.
Microsoft and Cloudflare are RedMonk clients, but this is an independent and unsponsored conversation.
Links: Natalia Venditto
Links: Igor Minar
Kate Holterhoff
Hello and welcome to this RedMonk conversation. My name is Kate Holterhoff, senior analyst at RedMonk. And joining me today, I have two guests I’m excited to introduce. Natalia Venditto is principal owner of JavaScript Developer Experience for Azure and Code Extensions. Natalia is also a cross project counsel at the OpenJS Foundation, which among other projects hosts Node.js. She is also the author of What is JavaScript? published by O ‘Reilly. Igor Minar is senior director of engineering at Cloudflare. And before that, Igor worked at a number of heavy hitters in the tech space, including Google, Oracle, and Sun. But he is most well known for his work on the Angular team. Igor and Natalia, thanks so much for joining me on the MonkCast today.
Igor Minar and Natalia Venditto
Thank you for having us.
Kate Holterhoff
All right, let’s get right into it. I asked Natalia and Igor onto the MonkCast because they are opinionated about the JavaScript ecosystem. They have seen some things in their time in this industry, not all of it good, and they have some thoughts on how to improve the front end development space. So lay it out for us. What is your vision for the future of front end workloads?
Natalia Venditto
Well, I see a future where we are not only front end, but full stack. And that’s going to be changing how we do everything. Basically, I see the lines blurring more and more and folks having to adopt new ways of handling workloads, writing JavaScript, thinking about how they write JavaScript and how they use web platform APIs, but also whatever native APIs of our runtime, which my favorite would be Node.js in my particular case. But yeah, this is basically how I see the future moving forward for our space. Igor?
Igor Minar
Yeah, I totally agree. I think, you know, web started on the basically as a static platform for sharing documents, and then it turned into this more dynamic platform that allow us to build applications, but these applications lived on the server side. But they were not very interactive. The user experience wasn’t very great. When you click the button, it took forever to do anything. So we moved the user experience to the client side with JavaScript, and we added a lot of JavaScript on the client side. We built Gmail and Google Maps and all of these very rich interactive applications that couldn’t exist before. But over time, over the last decade, we just started putting more more JavaScript to the client side, which…in the end started to dragging down the developer, the user experience and slowing down the user experience. So I think what we’ve observed over the last few years is this gradual shift back to the server, but in a way that preserves the interactivity on the client side so that we get both like the offloading of the client by doing workloads on the server side, but still doing just enough on the client side that you still have this rich applications. They just work faster and better and the user experience improves.
Kate Holterhoff
All right, so talk to me more about server side rendering. Why do you feel like it is the superior means of running these workloads?
Natalia Venditto
Well, I always say that one of the reasons is because it’s an environment we control, but it’s also an environment that doesn’t impact any great performance for the end user, which in the end should be our main goal. Our ultimate goal is delivering a great experience and enhancing the ways a business presents themselves and makes their services and products available to users. So if we are having their experience, impacted by the way we put together an application. We’re doing a disservice to everyone, the business and the end users. And now when we move back, certain compute intensive sometimes and in general system intensive workloads to an environment where we have the full control, where we can distribute in a better way. So we make data more accessible or put it in a way that is less consuming for the system to operate. Then obviously we’re having, we’re benefiting everyone, right? End users, the businesses and ourselves as developers in terms of what we control and what we don’t.
Igor Minar
I agree. But I’m going to reframe it from the user’s point of view. As a user, if I navigate to some URL, the first thing, the thing I want the most is actually see what that URL stands for. What is the user interface? And I want to interact with that. And without server-side rendering, if I click on a link, I first have to download all the JavaScript that powers the application. That JavaScript has to start, has to go fetch the data from servers and only then it could start rendering the UI. With server-side rendering, as soon as I do the first navigation, the server receives the request and can go fetch the data and send back HTML that can then render the user interface much more quickly. This is why server-side rendering is so important. But we used to do server-side rendering 15 years ago with PHP, with Perl, with Java and all of these approaches.
And that’s not what I’m talking about. I think I’m talking just about the initial rendering should be done on the server. But after the initial rendering, we want the application to become alive on the client side and continue from then on, on the client side, the way we’ve been used to interacting with Gmail and all these Ajax applications that run on the client side. So we are looking really at this hybrid model where the application starts with the server-side rendering. But after the initial bootstrap, it continues as this very interactive application from then on.
Kate Holterhoff
All right, so say you’ve convinced me, who is disagreeing with this? What are the sort of blockers to us rendering everything on the server then?
Natalia Venditto
That’s very interesting question. But I also want to say that it has to do with in which way we make the application interactive again. That has changed. That’s not the same way we used to do it 15 years ago. And I think that we have detractors to the idea of server-side rendering, then hydrating because of certain interests that are pertaining to providers and not really to the community of developers. But sometimes we tend to see things only as this proponent is just advocating for this way of doing things because maybe they have a business interest in the matter. And that may be influencing a negative outlook on how we propose things are done, which in reality, we very much disagree with. We really believe that this is the most optimal way to build an application in the front end. This is one of the reasons, I guess, why people disagree.
Igor Minar
I think anytime there is a change, people feel uncomfortable about change because they are invested in doing things the way things are working today. And today, building web applications is simple. You often just write your JavaScript, HTML, CSS in some way, usually with some frameworks, and you upload them to someplace that serves static assets, which is often free these days.
And you’re done. You don’t have to worry about any infrastructure, about any other costs. And it’s actually the clients of your application that are paying the cost in terms of the battery power, the network bandwidth. So basically, as a developer, you’re pushing the cost on the users and you don’t feel any of the monetary costs of running the application because so much of it is done by the clients and clients carry the cost.
With server-side rendering, we’re saying some of this workload actually should happen on the server side. In that case, somebody needs to run the CPUs, usually in some semi-concentrated way. And that is often free, but not always. Especially the question is, how big is your scale? If you are.
Some multinational corporation is probably unlikely, with a big audience, is probably unlikely that anybody is going to allow you to run your server-side application somewhere for free. No cloud provider is going to do that because it just doesn’t make sense. But if we are looking at what are the benefits, is the user experience improvement worth the cost? I think the people that are commercially benefiting from running their business on the web, it’s a cost that is just like any other cost, right? So if there’s any opposition, it’s about this like shift in I need new tooling, I need a new way of deploying applications and that is sometimes uncomfortable.
Kate Holterhoff
OK, so to be clear, it’s Single Page Applications (SPAs) that are doing this, that are doing all the rendering on the client side that we’re sort of trying to move away from, correct? OK. Yes. All right. Just wanted to make sure that we’re stating possibly the obvious here. And Natalia, I interrupted you.
Natalia Venditto
No, just wanted to say that sometimes there’s also a little bit of misinformation or ignorance about the actual conditions in which end user is going to be loading an application. Because we tend, especially, and I always say this in the US, in Europe, we tend to work on high-end tech. And we do not consider that that’s not the reality for everyone, right? And even when it’s true that sometimes businesses may have to assume the cost of the rendering infrastructure and the decoupling and composition because this type of architectures typically work in distribution. So they are not a monolithic kind of architecture. In the long run, the advantages, especially for the end user are very, very high and very solid.
Kate Holterhoff
All right, so one of the things that I think is so exciting about working in the front end space, and usually I say the client side space, but maybe you’re having me rethink my framing a little bit here. So let’s just say the JavaScript ecosystem is that there are all these sort of innovative ways of running workloads that we’re seeing now. And one of the sort of loudest voices in that room, I would say, is the WebAssembly folks that are running Compute on the client, right? And they’re doing a lot of exciting stuff. I’ve talked to lot of advocates of this type of technology. I understand that there’s a few permutations of it that are a little less client focused. Talk to me about WebAssembly, because I think that they would have words for your sort of blanket opposition to running compute on these local devices.
Natalia Venditto
Well, WebAssembly obviously is a very performant way of running client-side code because you do it at a very low level. And the way you consume resources is very, very much different from the way you do it higher in the JavaScript engine. Right. And this is what they are trying to promote that we use lower, lower level resources, but WebAssembly is also not easy to use. Like you have to have an understanding of things like, I don’t know, as expressions and understand how to optimize it. And then you have to understand how to import it into JavaScript and how to buffer it. And it’s not that simple. However, there is a great ecosystem around it. We’re trying to solve those problems, especially the debugging part. It’s not easy to debug WebAssembly when you’re running it from a, or when you’re calling it a module from a different runtime.
But what I see the most interesting about this is that WebAssembly enables a real isomorphic kind of application when you combine it with the WASI or WebAssembly Interfaces that can be run literally anywhere from a tiny device like this to a large computer, or a data center. So this is where I see probably something really portable happening in the future. That’s the biggest opportunity with WebAssembly at a very low cost, right? At a very low cost, very optimal, very efficient, and in the end, truly isomorphic.
Kate Holterhoff
How about you, Igor? What are your thoughts on WebAssembly?
Igor Minar
So I’m both a big fan and a skeptic of WebAssembly, and I’ll explain why. I think WebAssembly is amazing at taking any code written in any language and running it on the web or on the server side. Because now the JavaScript runtimes that we have in the browsers run on the server side. So your code truly becomes ubiquitous and can run anywhere. And that’s great. However, I have yet to see a WebAssembly application that can achieve the level of fidelity in terms of interactivity of user experience as JavaScript.
I think JavaScript and DOM are so married together, so tightly integrated, and such a perfect match for each other that I, except for some special cases, if you’re talking about web applications, especially enterprise applications and consumer applications, I have yet to see a WebAssembly architecture that would achieve better results than JavaScript and DOM, more traditional way of building applications. However, that doesn’t mean that WebAssembly has no space in these modern applications. I see WebAssembly as a way to reach and tap into functionality, special purpose functionality that is very difficult to build with JavaScript. For example, image optimization is a good one, or any kind of encryption, or something that is hardware or resource intensive.
We have lots of implementations of libraries and code bases that allow you to perform these kind of operations that you can use WebAssembly to now run in a browser. And from your JavaScript application you can call into and tap into this function and say let’s transform this video or let’s transform this image using some web assembly routine So I see it more as something you would use in addition to your JavaScript application, not as a replacement of the JavaScript application.
Natalia Venditto
I think I agree there very much agree there and there is a very good example with static frameworks that use WebAssembly capabilities to run search or indexing in the client side. And that’s exceptionally fast. That could never be done by JavaScript running client side as we know it. So yes, I totally agree that it’s more like a combination. And it’s the same thing that we are proposing for server side that then gets rehydrated, right? So this is why I also mentioned when you have an application that you want to transform or integrate into this new way of doing things or ecosystem, you have to start splitting it apart and considering what’s the best way to run each part of the application and then connect it and yeah, compose it.
Igor Minar
Yeah, I agree. For years, people have been trying to replace JavaScript because for all its benefits, JavaScript is not perfect. It’s a language that is simple but also not at the same time. And people love to hate it. And over the last almost two decades, people have been trying to replace JavaScript. And all the attempts have failed, starting with Flash and ActiveX and…Java and Java applets and Dart and I don’t know, just like so many different approaches. All of them failed because JavaScript is actually a perfect fit for this interactive user interfaces on the web. And we should stop trying to replace it. We should try to make it better and then provide WebAssembly and these kind of ways to reach into this routines and libraries for special operations that are resource intensive.
Kate Holterhoff
All right, and it seems like there are a number of front-end frameworks that are trying to have it both ways, in the sense of they’re using island architectures and some of these ways that you can, like I’m thinking of like Qwik has almost like a lazy loading approach. so everyone seems to be grappling with this issue that we’re discussing broadly, but not everybody is saying, let’s go server-side rendering all the way. If the way that web apps are delivered is a pendulum, let’s swing back to the PHP days. I guess my question to you is, what is your response to folks who want to incrementally move back to the server and that maybe you want to still do a little bit on the client? Is there a space for that or should we just burn it down, move back to the server, like forget about it?
Natalia Venditto
Definitely incrementally.
Kate Holterhoff
Incrementally, okay. Yes. All right. What’s the best approach for incremental? I mean, signals is doing something with this, right?
Natalia Venditto
Yeah. I think that Igor is working on something that may help folks move from one pattern to another. Maybe you want to talk about it?
Igor Minar
Yeah. I haven’t really talked about this publicly, but I’m happy to start sharing more. In the past, built with Misko [Hevery] and others and the team, built AngularJS and Angular and a bunch of frameworks. And one of the things that I realized is that one thing that any framework does is it kind of locks you into an ecosystem. And it’s very difficult to move away from the ecosystem because you have so much investment in it. So changing stacks is almost impossible.
In a way, it’s good for the community because that keeps the community together because they are all being held hostage by themselves. But it’s also bad for the consumers and for the end users because it makes it almost impossible to change stacks because rewriting these massive applications that we have built over the last 15, 20 years is almost impossible at this point to do it like a big bang migration.
So one thing I’ve been thinking about is how can we enable incremental but radical changes to our stacks in a way where the existing investments we have in the applications is preserved, but we can very quickly get benefits from server-side architectures, full-stack architectures in a way where the user gets the benefit, but also the business gets the benefit because the team working on this application.
becomes much more productive. I built this together with the team. I built… I don’t know how to describe it yet, and this is where I’m looking for feedback too. It’s a set of principles and a very lightweight library that I call Web Fragments. And what Web Fragments allow you to do is to take a legacy application that can be monolithic, client -side rendered SPA or PHP or whatever. It doesn’t really matter what kind of web application it is as long as it has a UI. And in that UI, you carve out a piece of that application and you say, this part of UI is business critical. We wanted to invest here and improve just this part.
Everything else we’d want to preserve because we don’t want to touch it, we don’t want to break it. But this part of the application, we want to upgrade, we want to rebuild on the new stack, possibly very radically different stack, but do it in a way where that part of the application becomes fully standalone, so the team can very quickly iterate on it and deploy it independently of the rest of the application. While to the user, a user doesn’t understand that they are using two applications all of a sudden. To the user, it still feels like they’re using the old application that has new parts that are suddenly just better for some reason, usually faster. And this is what Web Fragments allow you to do.
Web Fragments is a micro front-end architecture and a library that allow you to take your big applications, break them down into smaller pieces, and independently develop and deploy these pieces while still preserving cohesiveness of the UI. So to the user, the user doesn’t know that they’re starting to interact with federation of applications rather than one application. And with this approach, we’re able to take legacy applications that are often very troubled with a lot of technical debt, with bad user experience, about the pieces that matter the most, rebuild them using modern approaches, full stack approach with all of the developer and user experience benefits.
and deploy them to production and start receiving the benefits almost instantly. You don’t have to wait a year or a quarter to start receiving the benefits. You can start today. And if you manage to carve out a small enough part of the application and deploy the production today, today you can start receiving the benefits of this approach. And slowly, little by little, this allows you to migrate the entire application over to a new stack of your choice.
Natalia Venditto
Yeah, I feel very positive about this because, I think I’ve been experimenting with micro frontends for five years right now. And one of the challenges is precisely this, trying to load on the client side two different applications, but also consequently managing dependencies all the way down the stack. Right. And all the solutions I have tested so far, they had one trade off or another. I am feeling very positive about this new way of trying to migrate incrementally and not probably impacting the end user in a different way. Like, okay, you have a part of the application that is faster, but then you’re loading a lot more dependencies and that’s not necessarily a good trade off in the end. Yeah, looking forward to testing this more myself.
Igor Minar
Yeah, and anybody will be able to. So Web Fragments is an open source project. You can find it on GitHub. It’s very tiny. It’s 3 ,000 lines of code. We’re actually working with standards bodies to make it even thinner by pushing some of the code we’ve rolled down into the platform. It’s not tied to any framework. You can use it with anything starting from
PHP and jQuery all the way through Angular and React and Next .js and Remix, whatever you want. And you can move from any framework to any framework. if you want to move from, let’s say, Next .js to Remix, can use Web Fragments for that. If you want to move from one hosting provider to another, a little by little, you can do that also. There are so many possibilities with this approach.
And the main goal is to just allow us to incrementally upgrade applications without losing a lot of the investment we put into it. And at the end, improve the web experience to become significantly better by adopting more modern approaches much more rapidly than we would otherwise would.
Natalia Venditto
And you said something very important that connects to independent deployability. And this is what I was also hinting at before. When we are building an application of these characteristics, we need to make sure that we are selecting the right runtime, the right environment, where exactly each part of the application is going to be built and delivered from to ship it in the most optimal way. So I think this connects really great with that idea of
There are many ways of building an application and shipping it back to the users and the client side. And we can leverage it, but we need to do an exercise of correctly designing it from the get-go and putting every workload where it corresponds in the right way.
Igor Minar
Yeah. And it all comes down to scalability and…allowing us to reduce complexity. We often talk about, know, whenever we have a new functionality on the web or any platform, people start to get excited about it, start using these APIs, and over time start building more more complex applications. And I’ve seen this over the years so many times where every time we thought we were building for 10x bigger use case, we actually enabled 100x bigger use case, and then our solution stopped scaling anymore.
And we see this both in terms of technical complexity, but even more so these days, we see it terms of organizational complexity. So many of the applications today are not struggling because the tech stack is not good. They are struggling because of the organizational complexity of the engineering team powering that application. And we often see enterprise applications that are being built by 50, 100, couple hundred engineers as a single monolithic application. And at that point,
One of the challenges that we often see is that we have what I refer to as fate sharing problem, where everybody must do a perfect job for everybody to succeed. And in such a big organization, it’s impossible to be perfect. Like you cannot have an engineering team of 300 engineers and everybody’s the top notch, perfect engineer. You need to design for failure. You need to allow people to fail, but when they fail, they should fail in a safe way that doesn’t affect anybody else. They should only…
affect themselves or their part of the application. And this is something that is not baked into our architectures today. And this is what micro frontend architectures, and especially web fragments, allow you to do. They allow you to break down the application to smaller parts. These parts are owned by smaller teams. And these teams have their own fate. If they succeed, they succeed because of their contributions. If they fail, they fail by themselves and don’t affect anybody else.
Natalia Venditto
There’s also more autonomy because not all parts of the application need the same development cycle. They are not all developed in the same way or with the same cadence or we need the same kind of releases or even the same kind of pipelines and integrations or yeah, the same way of doing things in end. So this enables a real organizational split that fosters better governance in the end. I am very, very much a fan of this.
Kate Holterhoff
I love that we’re able to talk about code at a of organizational level. Take that higher up approach. Because I think when we think about maintainable code and strong, healthy organizations, we tend to get into the weeds a little too quickly. And so I think that that is important for thinking through this. And I also appreciate you defining why micro front ends are so important right now. It’s something that I hear come up pretty frequently. And I know it’s a little polarizing. But I like the idea that it can really benefit large teams. And folks are using it and finding a lot of value with it. But there are some of these kinks that need to be worked out. And so your open source project is going to help with that. What license is it under, by the way?
Igor Minar
MIT.
Kate Holterhoff
MIT, great.
Igor Minar
Yeah. The goal is to really make this accessible to everybody. Because ultimately, all of us will benefit. If we can move forward faster by adopting new technologies more aggressively without fear of regressions or loss of investment into whatever we’ve built in the past. I think we’ll be able to improve the web at a much faster pace than what we are able to do right now.
Kate Holterhoff
Yeah, that makes sense. I want to hear a little bit about your perceptions of open source. Foundations seem to be a really important part of where open source is going right now. Would you talk at all about your involvement with the OpenJS Foundation? And I’m thinking especially about how important folks are finding them in the wake of some license changes that have happened. So the Valkey fork of Redis, for instance, and the Open Tofu Project following the Terraform license change. It seems like foundations are really in the spotlight because they have this renewed value from the open source community. What is your perception of foundations, and why are you involved in them? I’m thinking Natalia especially, also, mean, Igor, you’re contributing to open source. So, you know, where’s open source right now? And are foundation’s an important part of that story?
Natalia Venditto
You want to go first? Since I’m more involved, maybe I’m more biased.
Igor Minar
Hot take. Open source is broken. It’s broken because it’s just the monetization. Open source is often seen as a way to get things for free without paying for things. And I think that is not sustainable. And this is like, I love open source because of ability to collaborate with other people that share interests without organizational boundaries, without political boundaries. Like it’s just amazing place to be and just intellectually work on problems that matter with people that want to solve these problems. But it cannot be done for free because all the people that are involved in building open source software need to live somewhere and have families and kids and they deserve to be paid.
And unless we fix the monetization of open source, I think we’ll be in trouble. And this is where I think foundations can play some role as an entity that allows this kind of collaboration and research and development and figures out the governance model and the financing model. But today where we are, I don’t feel great about future of open source because I feel like it’s unsustainable. So much hinges on just pure passion of people. There’s a very famous XKCD meme where like the world is built on this one library that is maintained by one person somewhere in India. And it’s so common. It’s not just like one library. They’re like… dozens and hundreds of these libraries that the whole world is built on top of, that are built by people that are just passionate about this, that don’t get paid. But there are corporations that are making billions of dollars on top of this free software and find it difficult to see that in order to make this sustainable, we need to find a way to fund this development in a way that is equitable and fair. And I’m the foundations can play a role there.
Natalia Venditto
Yeah, they should play a role in finding this equilibrium between private interests and that passion and that way of collaboration that we have found as software developers. Obviously, foundation’s towarding and providing governance is very important to make sure that every party is satisfied and can get whatever they need from software and it is protected also from the influence of specific agents or actors in the ecosystem one way or another. At the same time, we need the support and we need usually financial support as well from those bigger players. So we need to find ways to balance out what’s happening and what goes into a code base. Obviously.
Kate Holterhoff
Can you talk at all about how the OpenJS Foundation is ensuring that some of these big companies aren’t having too much sway over the projects that the OpenJS Foundation specifically is hosting?
Natalia Venditto
Well, there are people from many different companies and from bigger and smaller players that participate and even individuals that are not connected or related to any of those important or major players in the ecosystem. And that’s because everyone has the same ability to express their opinion and there are different committees and what we try is to find consensus and if we don’t find it, then things don’t move forward. Basically, that’s a way of protecting the code bases, the software and the community as well that depend on this ecosystem from having to accept whatever single private or public company decides is best.
And yeah, that’s how we do it. So the committee, the cross project council, what it does is it takes care of all that list of projects that are stored by the foundation. We don’t really issue any governance for them, but we try to make sure that things are mutual, all decisions are made in a neutral way. And at least in terms of security performance and certain concepts that are the foundations of reliable software, we can keep things on track, basically.
Kate Holterhoff
I can’t believe you run on a consensus model that seems so utopian. I’m thinking of, I know governance is something that Matteo Collina has spoken about as being extremely important for making sure that the loudest voices in the room don’t get more attention than maybe some of the smaller contributors, that it can become a truly democratic space. But I love this idea. mean, you must have like very lively conversations at some of these meetings.
Natalia Venditto
It’s very difficult and it makes things slow. But in the end, everyone wins, right? So we try to go in that direction.
Kate Holterhoff
All right. That’s democracy. I love it. And, Igor, so you are actually authoring some of these open source projects, are you planning on contributing or donating this to a foundation at some point? Or are you going to be the benevolent dictator?
Igor Minar
I don’t want to be a benevolent dictator. One of the things that I’m trying to, and I’ve been trying ever since I spent 12 years working on Angular. especially the last seven years, I was trying to figure out how to make the governance more open and how to bring more. But it’s difficult when you have a project like Angular that is sponsored by Google and Google wants to have some security around it. It’s very difficult when you have corporations that feel like they could lose something by sharing, especially governance. Sharing code has become more acceptable, but sharing governance has not.
And I think that’s the thing that’s the next obstacle that we need to overcome, or I think corporations and enterprises and businesses need to get more comfortable with open governance models where the governance is actually shared across many companies. Because my intuition is that that’s the path towards more sustainable open source, where you don’t have a single team of volunteers. You actually have corporations and businesses that are paying for the development of an open source software without fully controlling the open source software, allowing the community to have autonomy, still having say to bring business interests for consideration and road mapping, but not be the only entity that controls the roadmap. We haven’t fully sorted this out. OpenJS is doing some work in this area. But I do think that the future is open governance and sustainable open source.
Kate Holterhoff
I like it. All right, we are about out of time. So before we go, how can folks hear more from you? What are your preferred social channels? Are you planning on speaking at any events in 2025? How can we learn more about the OpenJS Foundation? How do we stay connected?
Natalia Venditto
I tend to post on Twitter. That’s the platform I use the most, well, X. But I’m not very active on social media right now. But you can find me on GitHub. That’s for sure. GitHub’s there. All right. Yes, have definitely, I have some conferences and events where I’m going to be participating of.
Igor Minar
NGPEs in December, we’ll be doing talk together.
Natalia Venditto
About SSR, by the way. But we don’t have any slides, anything defined. this is why I was hesitant.
Kate Holterhoff
Aspirational. That’s good.
Natalia Venditto
Yeah, I’m going to there somewhere.
Kate Holterhoff
How about you Igor?
Igor Minar
The easiest way to reach me. I moved from Twitter to, to Nostr because Nostr is probably something that most of you have not heard of, it’s, it’s a decentralized Twitter. That’s what it is. Open governance, open source, and nobody owns anything except you own your own stock. So it’s a sovereign platform where you your own content and it’s still shared in the same way as is on Twitter. And interestingly, there’s now a way to connect Nostr with Twitter. So if you post on Nostr, it actually is reposted on Twitter. So that’s what I use. you can also, if you are not ready for Nostr, you can still follow me on Twitter and you’ll get the content. The other way is igor.dev. That’s my personal website with a few blog posts and GitHub, of course.
Natalia Venditto
Oh hold on. I maintain a website on micro frontends, microfrontend.dev, but I always forget it.
Igor Minar
That is true. microfrontends.dev.
Kate Holterhoff
Yeah. I will include those in the show notes. Again, my name is Kate Holterhoff, senior analyst at RedMonk. If you enjoyed this conversation, please like, subscribe and review the MonkCast on your podcast platform of choice. If you are watching us on YouTube, please like, subscribe and engage with us in the comments.
Images are for reference only.Images and contents gathered automatic from google or 3rd party sources.All rights on the images and contents are with their legal original owners.
Aggregated From –
Comments are closed.