DEV Community: Dima Odintsov

Why should you use Flutter?

Dima Odintsov — Sat, 19 Mar 2022 14:02:57 +0000

Because i told you to. Flutter is the hot new framework and everyone else 's doing it, so why shouldn't YOU?

Seriously: There are plenty of reasons why you should use flutter.
Let's discuss what it offers over other cross-platform tools.

Flutter is an open source mobile application development framework by Google that allows you to use the same codebase for building iOS and Android output. You can write one set of business logic or UI codes and then just share it with either platform as long as the SDKs are available. The developer experience is very similar to React Native, but Flutter works better than RN because it provides a faster development cycle, more widgets support(all those material design components), and very smooth animations due to hardware acceleration.

The first reason why you should consider using Flutter is that there is no need to write additional business logic or UI codes because Flutter comes with excellent features like stateful hot reload, code sharing, deep linking support, and fast development cycle to make your dev experience much better than any other option out there!

Now back to our original topic. Let's discuss the benefits available when using Flutter over other cross-platform technologies like React Native or Xamarin.

· Stateful Hot Reload -
The stateful hot reload feature in Flutter allows you to change the code of your app while it's running. In other words, the changes you make to your source files will be applied immediately without restarting or recompiling. This is a life changer! You can imagine that when you're developing an application and even if it takes 2 minutes to recompile, that ~10 seconds of waiting really add up over time. So this feature alone makes a big difference in developer experience by making development a breeze. If this doesn't convince you enough, think about how much time you could save during refactoring when everything would work "as expected" even after changing your source files.

· State management -
Flutter allows the developer to manage the state of their app with an easy-to-use framework that provides all the tools developers need without creating too many boilerplate codes. Everything in Flutter is built around this concept, and it's really awesome! When you're working on iOS or Android projects, you would usually find yourself duplicating codes for routing which could be quite time consuming during development; but thanks to this excellent state management feature in Flutter, you can write one set of business logic/UI code and the framework will automatically route the user flow(navigation) by itself depending on how deep you are in the widget tree.

· Widgets -
React Native comes with only a handful number of widgets, while Flutter provides over 90 high-quality widgets to choose from. It's difficult to find yourself limited when it comes to the variety of UI components available for you to use during development thanks to this extensive support. Plus, all these widgets are customizable because you can pass parameters as needed. For example, if you need your image's background color or border radius changed, that's easy! Just pass those values as parameters and Flutter will do the job! In contrast, Xamarin Forms doesn't give you great default widgets like those provided by Flutter; instead, the developer must either write their own or use a third-party library, which can be time consuming and error-prone since the widgets themselves may not be standardized into a framework.

· Animations -
Flutter uses Skia as its 2D rendering engine. This engine is very performant because it takes advantage of every bit of GPU power you have on your device to make animations as smooth as possible. As I mentioned earlier, Flutter has its own hardware acceleration feature that allows for fast and efficient rendering on mobile devices with limited resources. Additionally, this animation system is completely customizable since developers can fine tune each layer by setting a tag associated with it.

· Platform integrations -
Flutter currently provides support for both iOS and Android. The framework is designed with the idea that it would be easy to integrate with other platforms in the future.

· Material Design -
Designing mobile UIs are often complicated due to differences between platforms, but not with Flutter! Flutter implements Google's Material Design UI guidelines which means you don't have to worry about things like making sure your widgets are consistent across platform because they're all based on Google's design principles. It also helps that there are many material widgets available out of the box thanks to our friendly community. Just look at ic_menu_share, this button was implemented using Flutter from the ground up using Material as a guideline.

· Future plans -
Google has been showing promising progress with Flutter. In fact, there have been talks about replacing Android's bad old WebView with a new modern engine built by Google that uses UI rendering from Chrome which means that one day all your web-based apps can be run natively on mobile devices.

· Great documentation -
Flutter is open source so anyone with the knowledge can contribute to our great documentation. The docs are very detailed and have diagrams, written in Google's Material Design language that is easy to read. There are examples of tests using each widget, too!

If you're writing code for both Android and iOS projects instead of just one type of project over another, you'd save time because the codebase would be less extensive due to not needing different implementations for each platform/device you support. You could easily make changes too without worrying about breaking something on another device or platform since you only have to write the code once.

· Since Flutter doesn't use native components, you don't need to wait on the platform team to update you when it comes to features and bug fixes! The framework takes care of this for you because these widgets are very lightweight.

· Flutter provides great performance due to its built-in hardware acceleration system, which means that it'll be able to get your app running fast without needing too many resources. You wouldn't have to worry about closing other apps running in the background because it uses only 1 core's worth of processing power!

· Although not yet supported, Flutter is working towards integrating Google's instrumentation testing.

· Flutter provides built-in support for localization so it takes less time to build an app that supports multiple languages You can check out all of the widgets available here.

If you're interested in learning more, visit http://flutter.io for more information!

If you're not sure where to get started, don't worry because there are plenty of tutorials on the website that will help get your development started. I'd recommend checking out their beautifully written getting started guide. There is also a great tutorial on building beautiful user interfaces here!
Additionally, they offer many resources like videos and examples of applications made with flutter.

Make sure to visit my portfolio :)

Cheers!
Thanks for reading. ❤️

Top ways to become a self taught developer

Dima Odintsov — Thu, 03 Mar 2022 20:16:09 +0000

What are the top ways to become a self taught developer?

Knowing the different ways to become a developer and how you can go about it will help you figure out which way is best for you.

People who learn developer skills on their own tend to be some of the most successful.

Even if this learning takes place after they've already entered the workforce, these people often find that this new skill set helps them advance even more than before.

Developing your developer skills through self-education is not only rewarding; it can also bring in higher wages and open up your options for future career paths that may not have been possible otherwise.

Here's a look at four of the top ways to become a self taught developer:

1) Online courses
2) Boot camps
3) Teaching yourself
4) Degrees and certifications

1) Online courses:

Self-taught developer, David Haney, recommends online courses as one of the top ways to become a developer.

He says that these courses are often more affordable than traditional degrees or boot camps. But they also provide many of the same benefits of the other programs.

Online developer courses cover both theoretical knowledge and practical skills.
They can lay out a plan for students to follow towards passing developer exams like those offered by Microsoft or Java programming language.
Most importantly, though, they teach students all there is to know about coding; from new recent developer tools to industry best practices.

2) Boot camps:

Boot camps are developer immersive training programs that last anywhere from 3 months to 6 months. These courses can be very expensive; some costing up to $20,000.

However, they're also some of the most convenient ways for new developers to learn developer skills in a short amount of time.

Meanwhile, developer boot camps like Iron Yard require students to move into their campus while they take classes and work with instructors on projects; all while building developer portfolios during their course of study.

3) Teaching yourself:

The third way you can go about becoming a self taught developer is by teaching yourself developer skills on your own through online tutorials or books. Like developer boot camps, these direct-to-student developer courses can be expensive.

In fact, developer John Sonmez suggests that the price of developer books and videos from source publishing sites like Safari Books Online can cost anywhere from $30-$300 per book or video module.

However, these materials are well worth the investment for students who prioritize access to developer training over convenience or time saved.

4) Degrees and certifications:

Finally, self taught developer Mark Price recommends pursuing higher education as one way to become a developer.

Although he says that developer certificates are only useful in certain cases, developer degrees are well worth the investment.

To get developer skills this way, Price suggests learning about different developer educational programs available at local universities or community colleges in your area. You can also search for accredited international universities offering developer bachelor's and master's degree programs online.

Conclusion to conclude, many self-taught developers use developer boot camps like Iron Yard to gain developer skills while working on projects with instructors to build their resumes.

Meanwhile, online courses like those offered by Udemy offer more flexible study schedules; but might cost more than traditional developer boot camps or degrees depending on how much you prioritize convenience over affordability. Finally, developer degrees are worth the investment if you want to go to school for developer training.

Background information to use as knowledge:

Online developer courses teach both theoretical and practical developer skills.
Developer degrees are worth the investment if you prioritize developer training over convenience.
Developer boot camps are immersive programs that can last from 3 months to 6 months.
Self taught developers learn by reading developer books or watching developer videos on websites like Udemy.
Higher education is one way to become a self-taught developer. This entails either studying at local universities or international universities online.

Make sure to visit my portfolio :)

Cheers!
Thanks for reading! ❤️

Static Site Generation vs Server Side Rendering

Dima Odintsov — Fri, 18 Feb 2022 18:06:19 +0000

As a web developer, one of the most important things you need to care about is performance.
How fast the page loads while providing a good user experience is extremely critical. At some point or another, we have all wanted to know if SSG (static site generation) or SSR (server side rendering) is faster in terms of page load times and availability for users.

In this little article I will talk about SSG vs SSR and which technique is the best when it comes to speed and user experience.

The server side rendering vs static site generation debate is one that has been discussed for years, but it seems to be picking up more and more steam this year. So what's the difference between server side rendering and static site generation?

Firstly, server side rendering (SSR) is an approach where server-side code generates HTML on the server at build time. This can include preprocessing languages like Pug or templating engines like Twig or Handlebars . These templates are then rendered on the server with data from your database or any other service you might depend on. The result of this is Server Side Rendered HTML which is then sent to the browser as a single page application (SPA).

Secondly, static site generation (SSG) refers to a range of techniques where server-side code generates static HTML pages. The server simply returns the HTML as a response without any further logic.

The thing that needs to be known is what SSG actually means:
It's when your rendered HTML pages are saved on disk as static files - think of it as a snapshot of your website. So SSG is very beneficial because no matter how slow or low quality your web server is, you can serve pages that are saved on disk to any device near instantaneously. SSG is different than SSR in that SSG doesn't need a backend and all pages rendered with SSG will be static- SSG only needs the HTML in markdown format and for SSG to work properly, there can't be any external <script> tags in any page.

As I previously mentioned, SSG uses files stored locally to generate websites so when you add new content or update existing content, the changes need to be uploaded manually by updating the which take time especially if you want to update and change a lot in your SSG based website. SSG becomes very slow when it comes to updating existing content especially if there is a large amount of content that needs to be added, updated or removed.

The benefit SSG has over SSR is SSG uses no server resources - SSG can be hosted for free on github pages (we will get to this later) and all you need is a GITHUB account. SSR requires backend requests from the client browser which takes up server resources when processing the request; SSG doesn't have this problem because all requests are served from the local web directory that SSG renders pages from.

Server side rendering, on the other hand, is SSG's complete opposite. SSR is when SSG pages are rendered to be sent to the client browser and then SSG pages are served- SSG is much faster than SSR because SSG doesn't require backend requests and SSG doesn't use any resources from the server. SSR requires a SSG backend which takes up server resources; this is why many people believe SSR to be slower than SSG because of how resource intensive SSG backends can be especially if there are a lot of pages requiring heavy loads on the backend like Medium or Wordpress do.

Server side rendering has an advantage over static site generation in that all pages will need to load assets (css, javascript) from external sources and since these external SSG pages are SSG pages as well, SSG will take up a lot of resources consuming them just like it would with backend requests.

The server side rendering's disadvantage is server side pages need to render those SSG pages before being sent to the client which takes up server resources. Static site generation doesn't have this problem because all it requires SSG backend for server requests and then server caches SSG website as a whole beforehand- you wouldn't have any problems updating your content every now and then even if it was a large amount of contents requiring updates, deletions or additions.

In conclusion, server side rendering has its advantages over static site generation since server side rendering doesn't require server resources but SSR can be resource intensive if there are many pages on the SSG website that require heavy loads of backend resources making them slower than static site generation.

Make sure to visit my portfolio :)

Cheers!
Thanks for reading! ❤️

Svelte VS React, which one?

Dima Odintsov — Fri, 11 Feb 2022 19:57:49 +0000

React is a web framework for rendering web components written by Facebook.
Svelte is a web front-end framework using web components under the hood.
The idea behind these two frameworks are to help web developers use components more efficiently.
This article will compare how React and Svelte approach this problem of component creation, what problems they are trying to solve, etc.

The main difference between React and Svelte is what they are trying to solve.
React focuses on components, while Svelte provides components optimization. A component in web development is basically a web page or web app that can be reused many times. Components use HTML, CSS and JavaScript code combined to create the web page/app that you want. This allows developers to minimize coding because you can reuse components as much as possible throughout the website/web app you're developing.

Another difference between these two frameworks is how they implement components within their framework's code structure. In React, components are created using JSX syntax which looks similar to template language but with JavaScript embedded so it would look something like this:

<MyComponent>Hello World</MyComponent>

This JSX code that's component is wrapped in an internal function so when components are rendered, these components are written to the DOM at run time. The component getting created in this internal function is just for convenience, it doesn't actually do anything until it's instantiated (or called) but components can be instantiated anywhere in the web app/website - they don't have to be written within this internal functions. This process of writing HTML tags inside JavaScript functions goes against what React stands for which is avoiding any 'stateful' Javascript because altering these components (or HTML elements) would alter this internal function's state which changes how components are rendered, so React components are immutable.

Svelte components are written in HTML view language which looks similar to CSS but with JavaScript embedded so components would look something like this:

<my-component>Hello World</my-component>

Svelte components don't have any internal functions written according to the framework's documentation. This makes svelte components reusable just like normal components that developers create themselves without using a web front-end framework because Svelte component code is pure Web code. The benefit of using Svelte over creating pure Components on your own is not having to write/write again HTML tags for each. With Svelte you can write one component and Svelte components are all compiled to components at run time which is how web front-end frameworks work, but the difference between writing components on your own or using svelte is that with svelte components, they are automatically optimized for performance because Svelte compile away unused code so you don't have to worry about cleaning up these optimizations yourself when developing websites/web apps. This makes Svelte perfect for big web applications that use a lot of components.

Another clear benefit of Svelte is how much easier it is to achieve code reusability than React because in React web page layouts often need to be written in JSX and this can get messy pretty quickly. With Svelte, web page layouts can be written in HTML which is easier to maintain.

Svelte are compiled to components at run time so this is where Svelte provides web-component optimization by compiling away unused code. React components are created with internal functions according to the framework's documentation and these components are immutable meaning you cannot delete/remove any of the HTML tags within the component or remove any JavaScript that was initially used when creating the component because they would change how things rendered (HTML elements/tags) and therefore alter what's in the DOM which renders how these components look on a website. This process of writing HTML tags inside JavaScript functions goes against what React stands for which is avoiding any 'stateful' Javascript. With React components, web page layouts need to be written in JSX which gets messy pretty quickly because there's a lot of components that need multiple web page layouts and then you have to write web page layout code inside each component's internal functions - there's a high chance of overlooking something important when writing web page layout code inside these internal functions.

Although Svelte has a steeper learning curve than React, it can do what React can do and more so svelte is favored by web developers who are concerned about how much time they spend on programming because less time spent programming means more time developing websites/web apps while still achieving the same goals.

Conclusion: This article's comparison between svelte and react components provides web developers who could be interested in Svelte components (but might not know much about it) with a clear explanation of what these components can do compared to React components. The decision on which one is the best between Svelte and React components depends on where web developers want to spend their time while developing websites/web apps: if they want to spend more time programming than cleaning up code/improving performance, then Svelte is their best choice; otherwise, if they prefer spending more time programming but would also like clean code that's easy to maintain and good performance because HTML web pages can get messy very easily when components are involved then React is their best choice.

FAQ:

Q) What web front-end framework is Svelte components compatible with?

A) Svelte components have no compatibility issues because they compile to components which means they can be used on any web page regardless of what web-front end framework (React, Angular, Vue) the web page is using.

Q) What web front-end framework is React components compatible with?

A) React components can only be used on web pages that use React web-front end frameworks.

Q) Why would web developers choose Svelte over React?

A) Svelte components are compiled at run time meaning they provide web developers with benefits such as being able to optimize how their website/web app appears because unused code will not be included in the final product which means there's less of a risk for bugs while developing websites/web apps if these optimizations were developed by hand. Another reason why web developers would choose Svelte components is because it has deeper learning curve than React so web developers can spend more time web programming and less time web cleaning up code/improving performance.

Q) Why would web developers choose React over Svelte?

A) web developers who prefer spending more time web programming than web cleaning up code/optimizing performance because it's easier to do so when writing React components compared to creating these components by hand or using a different framework that compiles into components at run time. Another advantage of using React is that these components are compatible with other frameworks such as Angular, Vue, Ember etc. whereas Svelte doesn't work with other frameworks at all due to their compilation process which means you have to create your website/web app from scratch using components that React components can be used with.

Make sure to visit my portfolio :)

Cheers!
Thanks for reading! ❤️