Awesome. Good morning everyone. Um, thanks for having me here today. Uh, so modern frontend development, a little presentation I've put together for you guys to explain what front-end development is and what the industry is like. So a small introduction, my name is Martin Gier. I am a front-end developer for DBT in Johannesburg. I have experience with front end, back end, and business. So today's talk is going to be composed of a few parts. So we'll start off with what is front-end development. We'll do a brief introduction to frameworks. We'll compare the different frameworks that are
available. And we're going to do a quick Angular demonstration. We'll do a day-to-day life of a front-end developer, myself, and what you need to know. And then I'll be free to answer any questions you might have. So what is exactly is front-end development? We'll have a look at the following core items. What is front-end development exactly? We'll discuss the history of front-end development and we'll discuss where we are now as well as discussing where we are going in the future for the future of front-end development. So, what exactly is front-end development? In the simplest form,
it is what the user sees on the page and how the user interacts with the application. But it's not that basic, unfortunately. There's a lot more to front-end development than just basic layouts and buttons with some forms. If It were that way, my job would have been a lot easier. At the core front in development though there lies three main technologies which I'll explain with the concept of building a house. So your foundation is HTML. Imagine building a house. You start with the foundation then the walls then finally the interior design. HTML is like the
foundation of a website. It is the basic structure that gives shape and content to a web page. So think of your headers, your navigation bars, your anything any elements on a page and they are mostly defined either by predefined HTML selectors like a navbar or a section but mostly it's custom divs. It's quite basic actually. So next up is the CSS. It is the interior decorator of your house. So imagine you've built the structure of your house with HTML. Now it's time to make it look beautiful and inviting. CSS is the interior designer and the
exterior decorator. It's the language that you use to style your web page. Um, determining the colors, fonts, layout, and overall appearance. CSS, short for cascading stylesheets, describes how HTML elements should be displayed. And then lastly, the main thing is JavaScript, which is the brain of any web application. So imagine your house is now fully now beautifully decorated with CSS, but it's still just a static structure. To make it into active view and dynamic, you need JavaScript. This is like the brains of your house controlling the lights, alarms, and other automated features. JavaScript is a programming
language that brings web pages to life. It adds interactivity, functionality, and dynamic behavior to websites. So where does all this come from? The first website on the internet was built with very basic HTML by certain Berners Leads, a European nuclear research organization. It was a very basic website that just described the concept of the worldwide web. And the cool thing is is that the world website is actually still available today. So, we can actually have a quick look at what the first website looked like. And it's not very pretty, but think of the time. I
think it's it's pretty amazing with what they did. And any HTML document that you run locally would end up looking like this without any CSS or JavaScript. So, it's just you've got a header, text, and hyperlinks. So, very basic. So, let's go back to the rise of JavaScript. or let's let's go back to basic HTML was great and all, but the people felt the need to build more interactive websites and more people were gaining access to personal computers and the internet. So early in the early 1990s, the internet saw more and more websites implementing different
fonts, images, and basic animations. While these weren't fully dynamic in today's sense, they marked the beginning of user interaction beyond static content. So in the year 1995, this the same year that I was born, giving my age away here, a very smart man by the name of Brendan Ike, who worked at Netscape Communications in the USA, introduced the world to Mocha, which later renamed to Livescript, which was again later renamed to JavaScript as Java was and is still a very popular language. However, they are still quite different languages, so there isn't much of a relationship
between the two languages. JavaScript emerged in 1995 as a solution to slow and inefficient process of validating user input on websites. JavaScript was designed to enhance web interactivity and JavaScript Quickly became a cornerstone of web development. Due to the intense browser wars of the time and still is going on, Microsoft created its own JS recognizing the need for standardization. JavaScript evolved into ECMA script and today JavaScript is ubiquitous with powering everything from simple web applications, animations, and even server side development with no.js. However, as all things in life, the limitations of JavaScript were found with
time and in true programmer fashion, a man by the name of John Reesef created jQuery. jQuery emerged of in 2006 as a response to the complexities of early JavaScript. Created by John Res, its primary goal was to streamline DOM manipulation and Ajax inter actions. Inspired by CSS query library, jQuery introduced a powerful selector engine and simplified common tasks like event handling, animations, and Ajax requests. Initially released under the creative common attribution Sherlock 2.5 license, jQuery rapidly gained popularity due to its ease of use and cross browser compatibility, its impact was significant, influencing the development of
other JavaScript libraries and even shaping the future of JavaScript itself. Just for some background, DOM manipulation refers to the arts of changing a web-based structure, style, and content using JavaScript. Think of it as dynamically updating a live document. So along came frameworks. Obviously, a lot happened in web between the time of jQuery to frameworks. But for the sake of time, I'll focus on the emergence of web frameworks today. As web applications grew more complex, managing JavaScript code became increasingly challenging. Vanilla JavaScript, while versatile, lack structure and organization for large scale projects. This complexity spurred the
development of front-end frameworks. In 2010, Google launched Angular.js, which brought a comprehensive framework with two-way binding, dependency injection, and a focus on large scale applications. In 2013, Facebook created React, which revolutionized front-end development and its component-based architecture and the virtual DOM, enhancing performances and performance and developer experience. In 2014, Vue.js was also introduced, known for its simplicity and flexibility. Vue.js gained popularity with its progressive framework approach, allowing developers to adopt it incrementally. But not all frameworks are perfect. Although Google along with other companies adopted AngularJS in 2016, they made quite the U-turn by launching a
new version of Angular called Angular 2. Currently, we are sitting at Angular version 18, which has been quite the change up since Angular 2. My first web application that I actually built was in Angular 2. So, I've experienced all the ups and downs of working on it. I'm also very fortunate to have missed out on Angular.js as it was very complicated and a lot of companies built products with it and are currently stuck using it because it's too big to replace. So some notes about Angular. AngularJS the original was built on JavaScript and relied heavily
on the scope object for data binding. While it was groundbreaking framework at the time, it faced performance issues especially in large scale applications. Its struct its structure while functional was becoming becoming increasingly complex to maintain. Angular often referred to as Angular 2 plus was a complete overhaul. It adopted TypeScript, a supererset of JavaScript for better safe type safety and code code maintainability. The framework shifted from a controller based archite architecture to a component based one offering more modular and scalable structure. So why did they change? Google the creator of Angular realized there was limitations to
AngularJS when building large scale applications. A good example is Gmail. If you look at the Gmail page, it's it's quite basic. It's a inbox with messages, but there's a lot going on. And they quickly realized that this isn't going to work. Performance issues coupled with the desire for modern and maintainable architecture led to the development of Angular. The new framework aimed to address the following challenges by offering improved inform performance through techniques like ahead of time compilation and more efficient change detection mechanisms. So a good example for this is if you send yourself an email
from your phone to your web browser, does the email the new email pop up automatically or do you have to refresh your page? That was one of the change detection issues that they came along is there wasn't a way to dynamically update it without jumping through a bunch of hoops and Angular solved it by having live change detection on components. So if you send yourself an email now without refreshing the page an or a new message appears on your feed. So they also introduced better scalability a component-based architecture that promoted code reusability and maintainability. So
essentially in Angular you have a bunch of separate components which only do one thing. So think of them as the the Message bar. All it does is it contains a message and looks differently based on whether you've clicked on it or not. And this was possible with the introduction of um code or uh component based architecture. There's also been an enhanced developer experience with TypeScript types tasty and more intuitive simplex syntax made for made development smoother. So just a quick rundown is TypeScript is JavaScript. It only has type. So if you think of a type,
it is a a quick example is a response from a server. There is values and you type it with an object. So you say the ID, string, username, string, um cell phone number, number or string, and then if you use that and you want to access a value that isn't defined on the object, it throws an error and won't compile your code. So in JavaScript, it just compiles and at runtime, you get lots of errors. It says object is undefined. And at a big scale, that is very bad. You don't want that. So even React
at the moment is adopting TypeScript. And if I can give you one tip of advice is always type your objects and rely on TypeScript to save you in the long run. So Angular also introduced a mobile first approach with a a focus on building responsive applications and in essence Angular was a response to the evolving needs of web development and the limitation of its predecessor. It represented a significant leap forward in terms of performance, scalability and developer experience. So where are we now with regards to front-end development? Component-based architectures. So a component-based architecture is a
design approach that breaks down a complex application into smaller self-contained units called components. These components encapsulate specific functionality and can be reused throughout the application promoting code reusability, maintainability, and faster development. So an example of this is a button. If you want to make an app that has the same button on each page, it's not ideal to create a button on each page with its own styling because what happens if you want to change the button, you end up having to go to each component where you've used it and update it there where instead of
where you can instead just create a reusable component that is called your general button and then only have one source of truth for the button. So updating it is a lot easier and also your if something goes wrong with the button you know where to look for the issue and this reusable component architecture is very important not just in front end but back end where you want to write as little code as possible to do as much as possible and that's a very flexible term because there's limitations to reusability and you don't know what the
limitations are until you reach them and that's usually where you have to decide you can extend the component and um use it as a base and then just change stuff or you can just create a new component and the same goes for services in backend development. Um so there are various tech stacks available these days some notable ones Include the lambstack where you use Linux, Apache, MySQL and PHP. I would say a lot of I don't know what the percentage is but quite a lot of websites on the internet use the lambstack but not new
ones anymore. Then you have the mean stack where you use MongoDB, ExpressJS, Angular and Node.js and then also the ME stack which uses MongoDB, Express, React and Noode.js. ASP.NET is not strictly an acronym but a Microsoft web framework using C# or VB.NET for backend development and often paired with SQL for databases. There are many more tech stacks using an array of different techniques and technologies. However, they all rely on the same concepts. Firstly, you need a backend framework such as ExpressJS, NestJS, Spring Boot for Java, and ASP.NET for C#. You'll need a database. So, think
SQL, NoSQL, or if you're brave, a distributed database. And then you'll need a front-end framework such as React, Angular, Vue.js, or even just plain HTML and CSS with JavaScript. And then lastly, you need a runtime for everything to work together. So examples of these include Node.js, Java virtual machine, and .NET runtime. And if you want to, you can mix and match any of these technologies because at the end of the day, you just need to get data from a database and send it over a network to the front end and vice versa. So I'll quickly
touch on progressive web applications as well. And all I can say is they are now a real thing. I don't know if anyone has ever visited a website on their phone and there comes like a little pop-up at the top that says add to home screen and that is a progressive web app because if you add it to your home screen there's a not There's an icon on your phone just like a regular app but it opens a web view. So that is a progressive web app is essentially a website that functions like a native
mobile app. It leverages modern web capabilities to deliver to deliver an app-like experience. PWAs combine the best of both world web and mobile apps. They use standard web technologies like HTML, CSS, and JavaScript, but also incorporates features like service workers and app manifest to enhance functionality. So what is a service worker? So a service worker is a script that operates in the background enabling offline functionality, push notifications, and also improves your performance. An app manifest is the file that provides metadata about the application such as name, icons, and a start URL allowing it to be
installed on the home screen. So what are the benefits of progressive web apps? The benefits are mainly speed. So progressive web apps load quickly due to it features like caching and service workers. Um so a good example of cache data is if you go to a regular website and your internet connection is down, it just shows you a 404 web service unavailable. Whereas if you are offline on a progressive web app, it still functions like an interactive web application and you can store data so that you can have true offline functionality for times that you
don't have access to data at all. They are reliable so they can work offline or in low connectivity environments. They are engaging so push notifications and immersive user experiences can enhance enhance user engagement. They are installable. So progressive web apps can Be added to the home screen for easy access. So instead of going to your browser, searching for a website, you can just open the app and it works like the website. They are also cost effective. Developing and maintaining a PWA is generally cheaper than building native apps on multiple platforms. So if you've got a
idea for an app but you don't know how to write C or swift or um cotlin to do Android and iOS apps you can do a PWA and mimic the style of a regular application. So and also later on I will touch on hybrid app development and give some examples and how it differs from a PWA. Um so in essence PWA's bridge the gap between web and mobile apps offering a seamless user experience across multiple devices. So, why are there so many frameworks? It feels like I'm going to say the word framework 100 times today,
probably even more. But the reality is that there's a ton of them, and the framework development space is not slowing down. There's your three main frameworks, namely Angular, React, and Vue.js. Some people will argue about it that there are better ones or bigger ones, but if you look at the statistics on the internet, these three are your main ones. But it seems like a new, better, faster, easier, and improved framework pops up every week. So, a lot of developers who build with one specific framework end up getting bored or they want more features or they
think they're faster, so they build their own. I mean, that's what people do for fun. Each do Their own. Um, and it's hard to keep up with what's going on. I find it easiest to choose one or two and focus on them. um because it does it kind of comes down to that master of or jack of all trades master of none and I' in South Africa the most companies use either React or Angular. So let that information steer your interest. State management is also a very important concept to learn when learning front-end development. So
state management is the process of handling and updating data across different components in a front-end application. It ensures consistency and predictability as the user interacts with the app. While simple applications can manage state locally within components or local storage, larger applications require more robust solutions. This led to the development of centralized state management libraries like Redux, NGRX and VX. So, an interesting story. I I can't remember where I heard this, but React created um Redux because they had two notific. There was at the top of the screen was a little message bar and at the
bottom was your chat bar that opened up your chats and they struggled to keep those two numbers in sync because they got they had different sources of truth and updated differently. So they decided to create a a state management framework that instead of having each component using its own source of truth have a centralized source of truth for information like message counts. And that's why if you look at your Facebook, you'll see your message count at the top is now in sync with the bottom one. And that pattern of Redux has spread over to Almost
every framework I know of. And it's a very powerful thing to use. Another example is if you're on your banking application and you make a payment, your balance should update as well. And what happened in the past is a bank would do the transaction and then call get balances for each account you had. But instead of doing that now, you can just use state management to deduct the amount off your account balance while not having to make the service request until you reload the page again. So it just makes things a bit better because I
don't know if if you make a payment and the payment doesn't deduct it irritates me a little bit. So state management libraries provide a structured way to store update and retrieve application data making it easier for to reason about the easier to reason about the applications behavior and build complex user interfaces. So um another thing is performance is king. Mobile devices and desktop computers are getting faster and more efficient than ever before. But that doesn't mean code can get slower. So runtimes like bun.js which is similar to Node.js are trying to replace NodeJS to improve
speed and efficiency even more. So next up we can talk about where are we going. Web browsers as mentioned before are getting faster and more capable every single year. There's quite a lot of functionality inside a browser and the gap between native applications and web applications are getting smaller and smaller. So think of large companies like Adobe for Photoshop, Microsoft Office, Google and many more are launching a desktop application that you can install as well as a literal clone that runs in your browser. This offloads the processor processing off the user's computer and leverage the
potential better processing that's in the cloud. Think of running a GPU or CPU intensive application like a video editing software and instead of having to rely on your computer's hardware to render and encode data, you can just simply let it happen on a supercomput somewhere in a data center. This could allow people to have smaller and more efficient personal computers. There's also an emergence of cloud gaming where your game runs on the server and you just it just gets streamed to you. But obviously there's still limitations to it. So if you're playing a RPG game,
that's possible. But if you're playing a very input latent latency reliant game like Counter-Strike or Valerant, it's not ideal because you still want that millisecond speed that you can actually um feel. So another thing that is interesting is web assembly is speeding things up even more. So what is web assembly? Web assembly or as it often is referred to as WM is a binary instruction format for web browsers. So think of machine code. It allows you to write code in languages like C, C++, R and Go and then gets compiled into a format that can
efficiently run in the browser. Web assembly is beneficial because it offers significantly improved performance compared to JavaScript for computationally intensive tasks. It also enables developers to reuse existing code bases written in other languages for web applications. So an interesting example I have of this is a guy that I Know did a talk at DevCon this year where he ended up doing consulting work for an engineering company that I think did aerod a airplane stuff and they had to do a web UI and they had a lot of libraries written. actually no it was a Python
um library and they had to get the old C++ code that works and let it go into Python that can be done on the web and they ended up compiling all the C++ code to web assembly and importing them and using them as functions in the Python. So it just shows you like the importance of it and then the use cases of web assembly include game development, video and editing software, augmented reality and other performance critical applications. While it's still a relatively new technology, platforms like Figma and AutoCAD AutoCAD web utilize web assembly for specific
functionalities. So the future of performant web lies in technologies leveraging the power of web assembly. So I'm just quickly going to do a example for you guys. I've got a C++ function running here that calculates Fibonacci to the 30th number. And if we run it, we can see it used 3.5 megabytes of memory and the execution time was close to 0 seconds, which is very good. But if we do the same function in JavaScript, we see that there's 06 seconds and 44 megabytes. That doesn't sound like much, but if you're thinking of, let's say, Avionics
or very intensive data processing software that that runs on the web, those seconds and memory allocation adds up very quickly. Um, so it's it's very cool to see that you can actually run C++ at this speed, compile it to web, and just let the web do the inputs and outputs. And I'll quickly jump back and um I'll talk about some serverless front-end development. So a big issue in the past was that in order to write code for the web, you needed to do to run a server and you needed to know Linux, you needed to
know about proxies and ports and all those not so easy to understand things. So along came serverless technologies which you actually just means that you don't have to manage your own servers. It's just the container on the cloud on a cloud provider server that you can use. So unfortunately the name serverless doesn't mean no service. That would have been quite cool though. Serverless computing is in is a cloud computing execution model where the cloud provider dynamically manages allocation of machine resources. Developers focus solely on writing the code without worrying about infrastructure provisioning or management. So
a good example of infrastructure provision is if you've got an application that has 10 users, you can use one server. But let's say at every day at 12 a million people log into your app. The server that you provision for 10 people is just going to buckle under the pressure. So serverless Provisioning means that as more requests come in they deploy more containers that just clone the um request to each one handling it. And if the people are done they just scale back to one server. So you don't have to pay for a thousand servers
anymore. you only pay for a thousand servers for two seconds a day, which is actually quite cool. So, the benefits of serverless computing includes cost efficiency and mainly just being you pay per use. So, if you've only got one person or 10 people using your server, it's going to be very cheap, but it also means that if there's a million people, you're going to have to pay for the service to handle a million people. It also improves scalability, so there's more time to worry about the actual code than having to worry about booting up a
new server. And it does all the booting up automatically. And it also increases the de developer productivity that way. It's ideal for applications with unpredictable traffic patterns or those that require rapid scaling. So think of the application that only gets a million users once a day. Um, a good example for this actually is uh Escomush. So they from what I understand are running on Firebase. And if you think about it, people only open the app when the the notification for loading comes in. So the servers are pretty quiet and then there's a notification that there's
stage five. A lot of people open the app, do a bunch of requests, the servers scale to meet the needs of all the people. And when people are not using the app anymore, everything just scales down. So there's some examples of serverless functions and these include API endpoints, data processing jobs, image resizing, and real-time chat applications. Popular server platforms are AWS Lambda, Google Cloud Functions, and Azure Functions. Platform as a service is also a cloud computing model that provides a complete development and deployment environment in the cloud. Think of it as full renting a fully
furnished apartment where you only need to belong bring your own belongings and your belongings referring to the code. Platform as a service handles the underlying infrastructure including servers, storage, networking, and databases. Developers can focus on building and deploying applications without worrying about managing the infrastructure. Some examples are Heroku, Google App Engine, and Microsoft Azour App Service. And now there's a bit of a taboo subject sometimes, but it is AI powered front-end development. I personally think AI is cool, but it has a lot of limitations. It's just like a a a thing to use. I don't
think you have to worry about losing your job to it in the next in the near future. I can say that. So, this is a little bit of a Pandora's box with students, especially knowing that lecturers don't want students using AI understandably and but you kind of want people to learn about how powerful it is, but you also want people to learn coding without using AI first. Um, and AI is everywhere at the moment. Doesn't matter where you go, there's some form of AI jumping at you on the internet, on your computer, on your phone.
I mean, it's it's just crazy. But it's mostly used at our level for code checking, for checking quality of code and giving ideas as the biggest limiting factor for Most AI is context of a whole application. So AI can definitely fix a thing on your screen, but it won't fix the whole application that's broken because it doesn't know what's going on. And there has been AI that does apparently things like that. There was Devon recently and it turned out to be a big scam and not very helpful. But you can also um if you've got
a Nvidia RTX graphics card, you can run a local LLM and provide your whole application as context and ask questions about it. Like because it's not very wise to upload your whole codebase to a cloud. I wouldn't recommend doing that. So, I'm still very excited for the future of AI in front-end development, but I wouldn't be concerned about it taking jobs away from us in the near future. It's a tool and not a replacement. As we'll later discuss today, there's a lot more to front-end development than just writing code, which the AI does. Um, so
next we're going to talk about the future of the framework wall. So, the top three, as mentioned earlier, are Angular, React, and Vue.js. And these are the best to learn and grow a career with. The core concepts stay the same between them. And if you know one really well, you can very easily pick up any other one. And there's going to be a lot of new frameworks in the future, but trust Google and Facebook um to be the driving factors in the growth as they have enough money to fund the two of them for a
very long time. A lot of big companies are also deep into the framework holes. So they won't be changing to something anytime soon. So an example of this is a lot of corporates in South Africa over the world decided to use either Angular or React 5 or 10 years ago and they kind of you're stuck in in whatever you're using because you've got domain expertise, you've got core applications running in it. So it doesn't make sense to just rebuild something in a new framework because somebody on YouTube said it's a good framework. Um there's a
lot of companies that just make it work as it is. So, front-end frameworks, it feels like I've said front end quite a few times already and haven't really gotten into what exactly it is. So, what is a framework? A front-end framework is a collection of pre-written code and tools that help developers build user interfaces of a website or web applications more efficiently. It provides a structured approach to web development, offering reusable components, libraries, and utilities. Think of it as a blueprint that speeds up the construction process while ensuring consistency and maintainability. And let's get off
let's jump into what the difference is between React and Angular for example. The main differences are not much to be honest but also quite a lot. So React is a JavaScript library used primarily on building user interfaces through components. It emphasizes flexibility and performance offering a component-based architecture that encourages reusability. React doesn't dictate a specific project structure giving developers freedom in choosing tools and libraries. And this is a double-edged sword because freedom means more potential to do amazing things, but It also goes the other way where more freedom and less control over what goes into
your code allows a lot of bad code to go into production. And Angular is a fullyfledged framework that provides a comprehensive structure for building web applications. It's built on TypeScript offering a strong typing and better code maintainability. Angular offers feature like offers features like dependency injection, two-way data binding and a command line interface for scaffolding projects. So in essence, React is more of a building block that you can use to create custom solutions while Angular provides a complete framework with predefined structures and conventions. The choice between the two often depends on project requirements, team preferences,
and developer expertise. And I can honestly vow to that where a bad framework in good hands is worth more than a good framework in bad hands. It's in the end what the code that you write that's the most important where also react gives you more power but can also go quite wrong if you don't have enough experience with it. Angular is very strict in the sense that there's very opinionated ways to do things which is harder to learn but may lead to less catastrophic events in the end. Although Angular can be quite catastrophic if used
incorrectly as well. So who builds and maintains them? Angular has Google, React has Facebook, and in essence, it's big money giants trying to prove to one another that they are better. So, as an end user, you are safe choosing either one of them as they won't be going out of business in the next 3 years. And I'm mentioning next three years because in three years a lot can happen. Um, so it's I like to think of things technology wise especially in that time frame. So, which companies uses which Frameworks? So Angular, I can give some
examples is ABSA in South Africa, Standard Bank, Google. I'd hope they use Angular knowing that they wrote it. Blizzard uses Angular, Starbucks, Mastercard, and ClickUp. And there's many more examples. And some examples of React is Facebook, Airbnb, Dropbox, Uber, Netflix, Discord, and WhatsApp. What WhatsApp for web. Now, let's get into how hard it is to learn a framework. So learning a framework is easy, but it's also hard. Um, my biggest suggestion for learning a framework is to start small. Think of doing the most basic thing you can think of, which is a button that does
something or a to-do list. Um, because a to-do list is essentially creating a CRUD app, which is create, read, update, and delete. And if you think about it, everything on the internet is just one complex CRUD app. Um, so after starting small, another source is reading the documentation. So if you go onto Angular, you see they've got a cool website and then they've got the documentation. Everything you need to know is on here. So from installing the um installing it to information about components and also just an example of starting it they've got a built-in
web IDE for you and there's in the tutorials there's videos essentially we're in a very good time on the internet with Regards to access to information and free information as well. So, YouTube, lots of blogs, there's definitely not a lack of information. And so, yeah, I would say read it, read the documentation, but don't don't have to study it in complete detail, but do the tutorial that's on this website and then build something with it. Think of anything you want to build. Do the most basic form of that and find an issue with what you're
busy building or an error and fix that error by googling your solution, talking to people or just finding out what's wrong and always remember what errors you made. Because at the end of the day, somebody that's a very good developer is just someone who's made a lot of errors and remembered how they fixed them. So which framework should you learn? So I' I'd say start off with basic HTML and CSS. There's actually quite a lot you can do with it. Um CSS is very powerful. Um there's different ways of doing things, animations and yeah, you
can get quite far with that. And for beginners, I would say React might be easier because there's less structure. But Angular has a steeper learning curve. But it's quite rewarding when you know what's going on. And another takeaway is I would say focus on one framework at a time where just learn one and before because if you jump between them there is a bit of a context shift and you don't want to bring principles From one into another one because you sometimes see company code where you can see this was written by a Java person
or this was written by a react person because and it just doesn't look good. So as mentioned before is where do you learn about these frameworks? As mentioned, I would say start at the official documentation. There's a lot of information. And then also YouTube. Uh YouTube has a plethora of free educational videos about each with basic and advanced concepts. Udemy and Corsera also have good courses, but they are paid for. And then I would say if you decided to get one or learn one, your first bigger project would be to just build a CRUD app.
So, a to-do list where you create items, you read them, you display them, you update them, and you delete them. And then you should also be able to have an idea for an application or if you've ever dreamed of building your own startup, just build it. Like even if it's terrible, you learn so much by building something you really want to build and use. And then if you're like me that's terrible at design, you can go on to a website called Dribble. Um, I'll quickly share And on dribble, you're able to find a lot of
designs, let's go mobile, that are usually a bit out of reach for most beginner developers, but it gives you an idea of stuff you can build if You just want to focus on refining your front-end skills. So, for example, you can make this page with this image, you have the slider, these are all components. It's it's a very good so cloning and also I know of people that go to websites and try to build their own copy of it and practice all the techniques used for that. And so I don't know if you could tell
but I'm a bit biased towards Angular. So let's talk about it. So Angular 2 was so I can't really compare the original AngularJS and Angular 2 plus with each other um because they're quite different but Angular 2 was launched as previously mentioned by Google in 2016. So it has quite a lot it had quite a lot of time to grow, refine and improve itself over the years. It's matured quite a lot and with every release um just for information we are on version 18 at the moment there's been some good improvements. The most notable changes
is a stronger focus on developer experience um and performance. Angular has introduced features like IV which is a rendering library and its new rendering engine as well which drastically improves improves application load times and reduces the bundle size. Um because quite a while ago, a few years ago, if you compiled an Angular application and deployed it, your bundle size was quite large and React apps were quite small just because there's less included modules in Angular or sorry in React. But the way they've updated the tree shake ability. So tree shaking is essentially instead of importing
a whole module to have functionality, you can Now import individual features of a module. So it just saves on space and just makes it a lot faster. And additionally, there's been a shift towards simplicity and flexibility. The framework has become more approachable with features like optional strict mode, um improved type checking and streamlined dependency injection. So optional strict mode is quite good for beginners because if you don't define a type exactly as it should be, the app just didn't run. And that's quite frustrating if you're working with data that you don't know yet. Angular has
also embraced modern web development trends by incorporating features like reactor forms, service workers as mentioned in progressive web apps earlier and dynam dynamic component loading. These enhancements make it a powerful tool for building complex and performant web applications. So why do I believe Angular is a good framework to learn at the moment and for the future? Angular is a comprehensive framework. It provides a robust structure including components, dependency injection and routing making it suitable for very large scale applications. There's a strong community in Angular as well. There's lots of forums and the biggest thing is
it's backed by Google. Google is massive. Angular also has a vast community on GitHub and on other forums as well. And it offers extensive resources, libraries and support. TypeScript integration is also very important. Um so by utilizing TypeScript, Angular promotes better code quality, maintainability and scalability. Another thing is performance. Angular has made significant strides in performance optimization making it suitable for very Demanding applications and the job market. So proficiency in Angular can open up numerous career opportunities due to its widespread adoption in the industry. Um so I would also say learning Angular provides a solid
foundation for understanding front-end development principles and building complex applications. um because there's quite a lot of overlap of Angular and other frameworks and even backend languages. Um so companies that use Angular as mentioned before it's AppSize, Stan Bank, Google, Blizzard, Starbucks, Mastercard and ClickUp and a lot more like there's a lot of companies using it and then job security and availability of jobs in so your main Angular customers are banks in South Africa um and there are many machines so there's always good job security there and browsing LinkedIn shows a lot of open positions in
the Angular space as well and if you go on the offen uh survey that they do every year, you'll see that there's a lot of people working in Angular and also wanting to learn Angular. So before we jump into the demo I'm going to do with you guys today is I'm just going to go over some core concepts in Angular. So it all starts with the command line interface. It's your basic way to interact with the application over the command line. You can use it to create new components, services, modules, and pretty much anything else.
You also use it to run your application. You also run your test your application and you can also build your application with it. Next up is modules. So, Angular Modules are containers for organizing and managing application code. They group related components, directive, pipes, and services into cohesive blocks, promoting code reusability and maintainability. Modules also facilitate lazy loading, allowing for efficient application loading by splitting code into smaller chunks. Angular components are building blocks of user interfaces. They encapsulate presentation logic, data binding and life cycle management. Each component defines defines a specific part of the UI such
as a header, footer, or a product list component. Components can be nested and reused creating hierarchal and modular application structures. Services. So, Angular services are reusable classes that provide shared functionality and data across components. They handle tasks like data fetching, communication with APIs and state management. By separating business logic from components, services enhance code organization, testability, and maintainability directives. So, Angular directives are custom instructions that modify the behavior of the existing DOM elements or create new elements. They extend HTML vocabulary enabling developers to create reusable UI components and manipulating the DOM dynamically. Directives can also
be used for data binding, structural changes and custom element creation. Routing. So essentially routing is a mechanism for navigating between different views within a single page application. It allows the user to define routes that maps the URLs to specific components, enabling users to interact with different parts of the application without full page reloads, providing a seamless user experience. So, think of routing as a way of going between pages without if if you think about it, if you do an index.html page and you have an about page and you click on the about page, it reloads
the whole application. So instead of having to just reload everything, you can just swap out the views and that means you don't do any page reloads at all. And then lastly, state management. So Angular state management refers to the process of handling and managing application data across different components. It involves storing data in a central location, updating it when necessary, and ensuring consistency throughout the application. Think back of the Facebook message count icon problem. Angular provides tools like NGX and state management patterns like Redux to help developers manage complex state effectively. So I think it's
time for a quick demonstration. Um so the prerequisites are I've installed Node.js the latest or the latest longtime support version as well as the Angular CLI that you can get on the documentation. So to start a new application we interact with the CLI with a command called ng short for Angular. So we can do ng start ng one new. So it asks you for a name. So we can call it demo today. And then we have to choose our our CSS syntax. And my default and the default for almost everything is always a CSS. No
for server rendering now. And now it just installs all the packages we need. And this usually takes a minute or two. And also is another note I would like to make is a lot of time spent as a developer is waiting for something to install or run on a server. But fortunately, we've been blessed today by a speedy install. So, we can just CD into the demo today code um folder. And then I've got a built-in code opener. And if you look at this, here's our new Angular application. So, inside VS Code, it's always cool
to use the terminal that's built in so that you don't have to tap between windows. Um, we can just use ngserve. So, no. And if you go to localhost 4200, you can see we've got our app. Um, but this is all good and all, but what can we really do with Angular? So, I've thought of some things I can share with you guys today is instead of Showing this, I'm going to have a router outlet, which just means that this is where the router should do all of its um loading. So if we go back
to application, there's nothing left because we've deleted everything. But I think we can start by generating a component and displaying it. So to generate a component, we use the ng generate component. And we put it in a folder called components test one. And you'll see that this generates a test component. But the question is how do we display it? because we can't just put it here and hope it shows up because what if we want to do something else with it. So this is where the router module comes in. So as defined your router module
comes empty and it defaults to wherever the router output is. So let's add a route for our new component. So in a sense essentially what happens here is the default path. So an empty path is just where your first page is. The load component then goes and imports the main component and after it's been imported imported um asynchronously it loads the test component. So if we go back we'll see test one works and that's pretty awesome. But let's say we want to do a second component and we don't want to route to the test Component.
We want to display test two inside of test one. So what we can do is we can add app test 2 on here and you'll see it breaks because it's not imported into the component that's importing it. So import the component and now we'll see test two works inside of test one. Um, so that's essentially your two ways of displaying components is either directly in the template like this or via the router. Because if we add a second one called path two and just change test one to test two, we'll see that if we go
to localhost part two. So just make sure you've got your paths correct. two component uh I think it's complaining about this. Oh, it's complaining about the for slash. So that's another important lesson is you get errors and you have to fix them. So we can see test two works on this part and if we go to this test two works but it's inside of test one. Um so that's components in a nutshell very basic overview and next up I would like to just demonstrate what services are. So in essence we can um use the ng
generate service and we put them in a folder called services and we can call this the data service and we'll see there's data service and what does a service mean? So, we can use this to provide information to pretty much anything. But for today, I'm going to use it to just and we can do get data and I've saved this before, but essentially this is just an API that gives data. Um, so for this HTTP client to work, we have to import the the HTTP provider. So inside your application config, you'll see there's a provide
router which creates the routes. But in order for the HTTP to work, we also have to do provide HTTP client because this tells the whole application that we're using HTTP client. Uh so if we go into our main component one we can import the data service and then inside the constructor. So inside the constructor just means this run every times the component is created. Um so if we go we can see there's all this data and this is coming from an API but in Order to display the data we can do a data and then
just assign this data to data that would work if we show but there's a better way to handle this and these are called observables. So essentially the data and observables are also denoted by dollar signs. Uh the data is the data that gets returned to it by not being subscribed to. So if we go into our template now and we want to show the data uh it's not going to work. It just says object object and if you look at the value it's an observable. So in order to access the observable value, we have to
um use the async pipe. So it's complaining about not seeing it. But we have to import the async pipe as well. But if we have a look at the data, it's still just object object, but now it's an array of objects. So in order to access the values we have to p pipe them over to JSON. So to do that we import the JSON type JSON pipe. And now we've got all the data. But this is where a thing called structural directives comes in. So structural directives refer to modifying your templates by either using an
ngf or an ng4 and or there's even an ng switch case or it's it's like any structural Functions that you can run. So let's do an ng4. So first we have to do a div and then we do ng4 let data of data and we have to async it as well and then we can do uh test two item and you can see there's a complaint which means we have to just import the ng4 and if we bring it up we can see it looks the same. Um and now it it's so what we see
is it loops over the data but it doesn't show the data. So this is where a important concept of inputs and outputs come in. So inside the test component we define an input of data by the type of any. I don't recommend using anyies at all. you will get shouted at. But for today, we can just do anyies. And inside the child component, we can now do a div. And then using template data, we can just JSON pipe. We can loop over all the test two items. So a mistake I just made is you have
to define the data for the input. So inputs are square brackets and we'll get to outputs in a second. Those are always round brackets. So we can see all the datas here. Um let's just give the div a little bit of styling. Give it flex. background color pink and then padding. So there we've got all these data items. But how does the child component so the ping component communicate with the parent component which is the component one. So there's a cool thing called outputs. So an output essentially is an event emitter. So whenever something happens
it event emits a value. So we can define a handle click and we just say this data is this data click true and then we emit the value. But we need to bind the value or the click value to this. So square round brackets click function name handle click and just for demonstration if we click nothing happens. But if we have a data change function that has a input of event data. We can go and create the function for handle change. define the event of type any and then we can just console log the event
or window alert the event. So now we've got all these Child components and if you click on it we have local host says object object. It obviously doesn't know what the object is but that's in the main essence how components communicate with each other. So back to presentation Sam we can go to uh a word about hybrid applications. So what are hybrid applications? Wouldn't it be cool to write code once and have it deploy on your web iOS or Android devices? And the answer is yes that is very possible. Um with frameworks like ionic, React
Native, Flutter and Zamarind. And there's a few more. Uh so native applications need to be written in Java Cotlin for Android and Swift for iOS. However, hybrid applications take web code and then compile them to native builds. Plugins like capacitor also allow you to write web codes and access native functionality like the camera, gyroscope as well as Bluetooth. Ionic and capacitor is also a cool thing because ionic is an open source library or UI toolkit that empowers developers to build high quality crossplatform mobile and desktop applications using technologies like HTML, CSS, and JavaScript. It provides
a rich library of pre-built UI components, gestures, and tools that closely mimic the native look and feel of iOS and Android. Capacitor, on the other hand, acts as a bridge between your ionic web app and the native device capabilities. Allows it allows your app to seamlessly access Features like the camera, GPS, file storage, and push notifications, essentially turning your web app into a fully functional web um application. Ionic apps are essentially web apps running inside a native container or a web view. Capacitor facilitates the communication between this web app and the native platform. When you
build your ionic app, capacitor generates the necessary file native project files for Xcode on iOS and Android Studio for Android and index a small JavaScript bridge into your web app. This bridge enables your web code to call native APIs and access device functionalities. Capacitor also streamlines the process of adding native plugins making it easier extend to extend your app's capabilities. Um, so there's also React Native which works in a very similar way. Um, where React Native is a popular open source framework developed by Facebook and it allows developers to build mobile applications for both iOS
and Android using a single JavaScript codebase. This means that instead of having to write separate code for each platform, you can leverage your existing web development skills and create truly native web application or native applications that can feel like they were built using the platform specific tools. So there are a few benefits of hybrid applications. So hybrid app development offers a range of benefits that make it attractive option for business and developers seeking to create mobile applications effectively, efficiently and cost effectively. Primarily it allows for code reusability across multiple platforms, eliminating the need to develop
se separate native apps for each. This significantly accelerates development time, reduces cost and simplifies the maintenance efforts as updates and bugs can be fixes applied universally. So hybrid apps are also pretty close to near native experiences. There are some limitations and um it's also easier to learn because you can just use your existing web knowledge instead of having to learn swift or cotlin for native. So additionally hybrid apps are typically easier to maintain and update compared to native app apps because it's one codebase. Um hybrid frameworks often come equipped with the rich sets of pre-built
UI components. So I know ionic has its own components for each platform. So buttons that look like iOS buttons and buttons that looks like web buttons or Android buttons. And it does the switch automatically. So if you build it once, it it looks pretty good on each. So there are some drawbacks. Despite its numerous advantages, hybrid app development comes with certain drawbacks that developers and business should consider. Primarily hybrid apps can sometimes suffer from performance limitations compared to their native counterparts, especially for graphics intensive complex applications. The reliance of on a web view and a
bridge between web and native code can introduce overhead and latency leading to a less smooth and responsive user experience. But I think this is only a problem with rendering or like big applications like games or stuff. So another drawback lies in accessing the latest device features and APIs. So all the access to device features relies on libraries written by people that maintain the code. Whereas if you use native code for web or not for web for iOS and Android, if a new feature comes out on Android, you can Immediately access it with um Cotlin. So
additionally, hybrid apps might face challenges in achieving a true native look and feel. While frameworks like Ionic and React Native have made significant strides in mimicking native UI elements, subtle differences between animations, transitions, and platform specific design patterns might persist. For applications where achieving a pixel perfect native experience is critical, hybrid applications may require additional effort and customization to to seamlessly blend in with the platform's visual image. So we'll also quickly touch on serverless fullstack. We have touched on civilist before, but this is more how front-end developers can leverage it to essentially be a lot
more productive. So, Firebase is a very good example of a tool that a front-end developer can harness to get themselves a full stack developer credentials. You only have to worry about consuming your data and displaying it in an ele elegant way while all of the service provisioning and scaling is done by smart people who work at Google. There are several other hosted platform as a services as well such as Superbase, AWS Amplify, Azure Apps App Service, and Azure Functions. There's endless possibilities with the modern cloud. If you can think of something, there's probably an AWS
service for it. Um, and that's something I think a lot of people realize when they go on the page. And the same goes for Google and Azure. All services communicate over the same REST APIs or any APIs you want to set up for yourself. You can connect your app to almost anything on the internet, send it and essentially send some data, get it processed on the cloud and get a response back. There are however some limitations. Cost is a big thing. Um cloud services can become very expensive At scale. There are free tiers but they
if you run out you are being charged and a good example of this was a startup I think in Brazil created a Firebase project and used cloud functions and they wrote a cloud function that triggered itself. So, it just went on forever until it crashed and they got a bill of about $40,000 that they had to pay unfortunately. But I do think they negotiated their way out of it. But still, if you're not careful, you can incur some expensive bills. Um, so it would sometimes just be cheaper to rent your own servers if you're running
a very large scale. So, thank Facebook. if they had to use um AWS, they would make a lot less money because AWS is expensive at a scale of a few billion people. Um and also your availability is directly correlated with their availability. So if Google goes down, you go down. But fortunately, Google doesn't go down quite often or AWS or even. But if it goes down, it's quite spectacular and all of your competitors are down as well as they are probably using the same services. And another thing is the speed isn't always as good. Um
so serverless functions or any serverless services have something called cold starts where it's running one instance while not being used and when you ping it the first time it has to boot up and get started. So your first call is always a bit slow but you can mitigate that by doing like a ping service and pinging it like every few minutes just to keep it going or you can define in the startup that you want to Keep it alive all the time. Um, and then limited control and con customization. If you get to really complex
issue and you're relying on your cloud provider to help, it's not the easiest thing to get out of. And then also vendor lockin. If you go onto Google or AWS and put all your services there and you want to use something else, you're it's it's quite hard to get out of it. And some security concerns. Um, so while cloud providers implement robust security measures, sharing resources with other users on a multi-tenant platform can introduce potential security risks that need to be carefully addressed. Uh, I wouldn't say it's the biggest problem because they know what they're
doing and if your code's good, they go is good. But hacks can happen anywhere and everywhere. So that's been a lot of theory and a little bit of practical, but uh, I think I I can start with like what I do in a day. So I drink a lot of coffee. I work from home. I go to the office once every two weeks. I use Google a lot and I attend lots of meetings and go to bed early because I was born before 2000. Um, but that's actually not what I really do. So, the life
of a front-end developer has gotten quite complex recently because it's more than just displaying stuff or making interactions. So, there's the part where you have to analyze project requirements. Um so a stakeholder in the company would come to you and say we want to build this and you're directly involved with the whole process because you have to make sure the services are doing the right thing. You have to make sure the designers are designing something that can be built and this is quite it's quite a hands-on process from idea to actually being deployed. And I
also gather and document information. Um, so any code that's not been documented needs to be documented or when you're exploring a new project, you have to gather all the information and document it um to make sure everyone knows what's going on in the future. And then I work with stakeholders. So any everyone from business analysts to product owners to designers to backend developers to testing front-end developers are involved with pretty much everything. I help refine ideas. So essentially if somebody comes with a big bold idea we have to go on and get it to a
workable solution because anything is possible with enough time but you're always constrained by time or money. So you have to refine something into a product that is actually deliverable inside the the expected time and then also provide practical solutions to complex problems. So there's always problems if you're working in development. Uh and a part of your job is having to figure out how to provide solutions. And a lot of solutions are sometimes straightforward, sometimes it is a bit of a hack, but as long as it works. And then one thing I love saying I do
is I manage expectations. So as a front-end developer, you can't you have to bring people down a bit because there's everyone has their ideal of what they want to be want to be done. But in the end, the front-end developer is stuck with time and just resource allocation To build something. So you have to manage the expectations of everyone involved so that when your code actually comes out, it's not that I'm saying like you're writing bad code. It's just if somebody brings you uh they want to build YouTube for dogs, like you kind of have
to bring them down a little bit and say it's it's not really possible. So another part of my job is I mentor junior developers. So, where I'm at at the moment is there's a grad program at the bank and I am responsible for the grad as well as transitioning him from being a grad to a junior developer. And we have one-on-one sessions every day and I teach him stuff and also just help him through any issues he um gets. And then reviewing code. So, we're a team of more than 30 people and there always has
to be two approvals. Um, so a big part of your day is also just seeing people's code, giving feedback or just approving it. And then surprisingly, lots of I also write code. Um, so that's a big part of it. And then delivering cool products. So the feeling of delivering a product to a product owner after seeing their excitement six months ago is quite cool. It's a very rewarding feeling. And then learning every day. So not just learning courses or but learning mistakes you made mistakes that could have prevented other people's mistakes. You should always try
and learn something every day and then coffee of course and that brings us to the end where I can give some recommendations about what you as a third year might need to know. So the first thing I want to talk about is that it takes time to get comfortable as a software developer. There's a lot of things on the internet where you see people writing their own compilers when they were 16. And unfortunately, it's that's the minority, but because it's the internet, it feels like everyone doing software is working at Google, writing their own open
source project, projects after work. Um, so it's it's quite daunting, but it it takes time to really get comfortable. And even if you're experienced, if you move to a new company, it takes a few months to know what's going on there, learn how they work. So it's it you should just be patient. And then secondly is enjoy the ride. So everything from your first app to being a senior developer is it's a journey and you should really focus on enjoying everything because if you enjoy it, you it's a lot less taxing on yourself mentally. And
another thing is always be curious. Um so always wonder why things happen or if why something is the way it is. go into documentation, see how companies work, read blogs about other companies, like always learn, learn something. And then lastly, or not lastly, but one thing that I like to live by is this came from Mark Zuckerberg when he built Facebook, is move fast, break stuff. And I don't recommend breaking stuff intentionally, but I definitely recommend moving fast and iterating your ideas, iterating your knowledge, and just going at a pace. It doesn't have to be
perfect to be able to learn something, but you should always strive for good quality. Um, always be willing to help and also be willing to be helped. So, that's a thing I see is a Lot of people, I don't know if it's ego or something, but they don't like receiving help and they also don't like giving help, but just reaching out for somebody technically or emotionally or just reaching out to someone um is a really rewarding thing. Um, and then also learn how to talk. So, everyone hopefully knows how to talk here, but there's going
to be different people in your company who understand things differently. And as an effective developer, you have to explain concepts to people that don't know about them. So, if you have to explain technicalities to a non-technical person, that's a whole skill on its own and kind of only comes with experience. But yeah, it's it's definitely something. And also it's there's nothing wrong with raising your voice and not shouting but bringing up things that aren't correct or asking questions. I think it's it's very good to be a part of a conversation even if you're just starting
out. Um because the sooner you get involved, the easier it is to get involved. And then be open-minded. Uh that's a big thing in software is people have very strict ideas about what's right and what's wrong. And there's people that say Java is the only thing you need and people say. it and angular is the only thing you need but react. I think it's it's not good to live with your eyes closed in a world with so much technology. You should always be open-minded and explore all the technology, find something interesting, learn from other languages,
and not just have your own block of knowledge that you rely on because also being open-minded with regards to technology means you're more adaptable and that's a very important thing as a skill. And that brings us to the end of today's presentation. Uh, thanks for having me and has there been any questions? Usually your first week at any job is very boring and there's a lot of technical information about setting up your networks and everything. Um, and I would say getting started, stay calm, take things day for day and um, meet the key people that
are involved. So you'll see there's a tech lead, there's senior devs. um just meet meet the people and ask them anything because it's part of your job to answer all the question answer all the questions. So that comes back to the how to talk and how to um how to interact with people is just focus on that in the beginning and everything will fall into place after about a week or so. Um, so there's also a question, how would you one decide if a program is too complex or large for React versus Angular or does
it not cause a big of a problem? So this this goes back to what I mentioned is it it all goes down to what experience you have. No program is too big for React or Angular. Um, it just goes down to what your experience is with big applications. Um, if you don't have experience with big applications, you will quickly find out where the limitations are. Um, and I don't think there's a there's a specific way to figure out. Um, I think it would Come down to what you know better. So even like I said, a
bad language in the hands of a good developer is more powerful than a good framework in a bad um hand. Uh then another question is as a front- end dev have you used nextj s2? I know of people that use it. I haven't used it myself but I do know it is quite on the up upwards trend as well and works quite well. So definitely something to learn as well. Um so another question is if you have this dream of being a developer is it wise to be picky like say you will strictly look at
Java. Um yes and no. So I would say it's good to be picky in the sense of learning one language at a time. Uh so become really good at Java because Java translates very well into other languages and frameworks but also don't label yourself as a Java developer for life because you can maybe get um into uh C#.NET or maybe go into Cotlin for Android. You never know. So I think it's it's important to start with one language, learn it well, and then uh end up being more open-minded. But if you want to do Java
and focus on it for the rest of your life, there's enough possibilities to do that. And so which technology stack would you suggest an aspiring de developer to use on with Angular? So Angular, it depends. If you want to focus on front end, I would say just use Firebase for free. So if you want to create like user Interfaces and stuff, but if you want to do the full stack, I would say the mean developer is a very good thing to to learn. So that's MongoDB, Express, Angular, and Node.js. Um, and if you don't want
to use Express, you can use NestJS, which I've been using recently. It's it's very cool because it looks like an Angular application. And yeah, so I would say mainstack for sure. um dependent on what your requirements are and it's simple enough to run on your own computer don't have to like you can run MongoDB locally you can run express locally so you don't have to pay for anything which saves um simple question is TypeScript or JavaScript the same thing yes and no so TypeScript is a subset of JavaScript it just adds more features and functionality
and is very strict in the sense of using types and there's a few syntax differences but they use the same core language if that answers your question. And here's a question. Have you worked in Flutter? And if so, what was the experience? So, I haven't worked in Flutter professionally, but I have worked on it on my own. And it it's actually a very cool language because it's it it looks very similar to React where you've got components on top of each other nested and also it uses Dart as a programming language which is almost better
than Java but it's it's like if Java and JavaScript had combined and it's so I would say Flutter is also very good. there are a lot of jobs for It and you can do flutter for web you can do flutter for iOS and Android and it's also I think it's not a Google product anymore but or I think it is um but yeah it it it comes from a very strong background and I know the good example of a flutter app trying to think I think escom is flatter and firebase um so yeah definitely worth
learning and a question is what common challenges do you face in front-end developments and how do you overcome them? So, your most common issues are comp compilation errors where you end up not um like not importing something properly or you're missing something and a big part is just googling your your errors that you get in your console. Um and then also sometimes you just don't know how to do something and that is where you have to do some research about how things work, how and like ask questions and ask people above you or below you.
Um and then also on a personal level like working at a corporate company it's very hard to make a name for yourself especially in big meetings. So, a big challenge as a front-end developer is getting yourself out there and saying, "You should listen to me because we build the end product." Uh, but yeah, that comes with time. I remember when I started working, it it was one of the hardest things ever to do. It's just talking up in big meetings because you've got very senior people and then somebody who just started out and like why
would they listen to me? So, but they actually do listen to you. Um, and so here's another question is you're not a backend dev, but do you think Django rest framework is a proper API platform or is it not your vibe? So I think Django with uh Django can be a very good web API. There's a lot of things you can do with it and yeah, I've never used it myself, but I do know it is used a lot and also Python is a very good language for data science and AI and all those things.
So, it's definitely worth exploring and yeah, so if you want to do a Django back end, it it refers back to the slide I did a bit earlier about the different text stacks is at the end of the day, you just have a runtime. So it would be Python runtime in this this instance a database so no SQL SQL anything you like and then just the front end and um a server so that would be Django in this instance so you can mix and match it as you want. If you prefer Python you can go
for it. I don't think there's any limitations towards what backends can do or not do. Obviously they are but uh definitely worth exploring. Cool.