DEV Community: ITMAGINATION

Trends in Software Development 2022

ITMAGINATION — Fri, 01 Jul 2022 00:00:00 +0000

Earlier this year, Andrzej Frydryszak, .NET Developer at ITMAGINATION attended a few conferences on software development. The list we compiled is a list of the most significant points the attendees of the conferences have heard from some of the top engineering leaders in the US & Europe. Here goes:

1. Observability [Tracing, Monitoring & Logging] is crucial!

You are working on your software, and you are ready to deploy it. All tests pass, and test coverage is on a decent level. Knowing this, we may deploy our code, and continue to work on it in peace. As much as this is not the optimal scenario (and as rare as it is) our code may still fail. Yes! Therefore developers need to always observe their code, and have it report metrics all the time. In case anything fails, you need to have your systems ready to deliver your logs to you. As Andrzej writes:

Observability is crucial. Without it, developers are blind. It gives us an opportunity to react to every problem occurring in the system at any time.

2. It’s a good practice to use both the “serverless” & “serverful” approaches. In that case, we benefit from both approaches to software development.

Serverless is a way of running apps (seemingly) without any servers involved. Of course, it is a major simplification – there are always servers involved; only in this case you do not do anything with them, and they come preconfigured. It’s touted as the new black, except… It’s not a perfect remedy to all ailments. For starters, you cannot configure the underlying server, as we mentioned before. You don’t really know what’s under the hood, either. The main drawback is the approach’s major benefit at the same time. You don’t have to configure anything, so instead of deploy ⇾ worry, it’s more of a deployment ⇾ forget.

There are benefits of either serverless or serverful solutions. In the modern systems, it is common to join two approaches to gain most of the solution.

3. Containerize everything! Kubernetes is a hot technology!

Not all software development trends are good ideas. Do you remember CoffeeScript or Ruby? Sadly, we do. Luckily, Kubernetes (K8S) don’t seem as if they are going to join the two in the valley of sorrow. K8S are making DevOps specialists lives’ much, much, easier.

Here are the benefits you can expect by introducing containerization and container orchestration as a core tenant of your technology strategy:

You will be able to easily optimize your IT infrastructure costs
Your users can expect higher availability and better SLAs due to seamless scalability
Using Kubernetes enables your team to use multi-cloud solutions more easily
Since containers and container orchestration tools are technology-agnostic, you can build using any technology that you want with a leaner team
You no longer run into the age-old “it works on my machine” issue by containerizing

Beyond the obvious benefits, we’ll leave you with some case studies that, we hope, will inspire you and help you decide if using Kubernetes is right for you, as well as show more in-depth benefits:

Northwestern Mutual Case Study | Kubernetes: after acquiring a fintech startup, Northwestern Mutual had to consolidate workflows between cloud-native and on-prem processes, deploy more often, and unify their team’s operations to ensure their customers kept getting the same seamless experience they had been used to.

Using Kubernetes helped them increase their deployment velocity by over 25 times from 24 in a year to over 500 in 10 months, planned outages are a thing of the past, and infrastructure costs decreased significantly thanks to their API management being part of their overall stack that’s deployed on Kubernetes.

You can read more about these points, the transition to AWS, using Microservices, renewed developer autonomy, and keeping their 4.5 million customers happy with the quality and speed of their services in the case study.

Capital One Case Study | Kubernetes: in Capital One’s case, bottom-line is a big topic. Their estimates show that without using K8s’ ability to scale up and down automatically and easily, their AWS infrastructure costs would easily triple or even quadruple.

Other benefits they’ve seen by using Kubernetes is time-to-market for new products, which now takes as little as 2 weeks, whereas it could have taken 3 or more months before.

The main reason for starting to look at Kubernetes for their development? Capital One’s team wanted to increase the speed at which they’re able to process streaming data for key decisions in the areas of fraud detection and credit decisioning, as well as for other big data and machine learning applications that are critical to the day-to-day operation of the bank.

You can read more about these points, the deployment speed increases, how K8s helped unify Capital One's development environment, and more in the case study.

Other intesresting case studies worth checking out:

Pearson Case Study | Kubernetes: reducing time-to-market for new features, increasing provisioning speeds from months to minutes, and ensuring high SLAs for an education company serving 75 million users.

Prowise Case Study | Kubernetes: zero downtime between application versions, hours to seconds for new deployments, and new releases sped up by 3x in a complex development environment that includes many products.

Zalando Case Study | Kubernetes: the European fashion e-commerce leader used K8s for scalability, enabling multiple business use cases like same-day-delivery, multi-tenancy, increasing their offering and geographical reach, and enabled them to re-write and create all the SaaS products they had been using as custom software.

adidas Case Study | Kubernetes: e-commerce site load times were cut in half, releases were done multiple times a day instead of once a month, and developers have much more autonomy thanks to adidas’ move to being cloud native.

Booking.com Case Study | Kubernetes: after using OpenShift and learning the ropes of how to use Kubernetes, Booking.com’s team shifted to their own vanilla version of K8s to enable their developers to be more autonomous, independent, and not have DevOps be their perceived bottleneck.

Have any questions about how to optimize your K8s deployments or whether it’s the right choice for you at your current scale? Make sure to reach out to us to talk to Maciej Gos, our DevOps competency leader.

4. When it comes to software architecture, we should divide & conquer

Monoliths of large sizes are somewhat of a yesterday’s tale. They haunted developers for long, though not anymore. Splitting huge unitary codebases into smaller scale apps is the new way of doing things. It fireproofs your applications, reducing the frequency of errors, and making apps safer in case something wrong happens. The downside is, apps become harder to test, and it takes more resources to do so. For teams of a smaller size, it still makes more sense to maintain a monolith.

Divide a monolithic application into independent microservices.

5. Open-Source & Free Software are the ways of the future.

React, Angular, and Zuul, from Meta (which used to be Facebook), Google, and Netflix, respectively, are tools countless developers use in their jobs every day. Without the tools these organizations released at no cost to all those willing to use them, everybody’s job would have been much more difficult. Countless services would not have seen the light of day, as it would have been too hard or too time-consuming to write these apps. All because, before writing them, one would have to figure out how to e.g., write front-ends for scale, on their own, without sharing the lessons learned would be extremely inefficient.

This is why we have to praise open-source & free software maintainers, creators, and all others contributing to the creation and maintenance of such software.

Creation of a tool/technology and making it open-source (or making it free) gives the organization eternal glory.

6. Use Architectural patterns.

There is a common rule in software development – don’t reinvent the wheel. Knowing that we likely have faced the same problem as somebody else before, the rule becomes all the more valuable. This is why engineers and developers from around the world use Architectural Patterns to structure their projects – not to waste time on thinking about how to figure out solutions others already came up with.

Much of modern pieces of software use patterns like CQRS and Event Sourcing. Don’t reinvent the wheel, use the patterns.

7. Programming languages are evolving.

The fact that we have newer and newer programming languages isn’t a surprise. They all come and go, and leave to be replaced by others. Nobody codes in Algol or Pascal anymore. One old-timer, C, is still around, however, though that’s a topic worth exploring on its own.

One noteworthy aspect is the way in which they all evolved during the years. At first, imperative languages were the only ones around. Then the boom for Object-Oriented languages came, and now, some might argue, that they are being pushed out by languages such that are much more flexible, mixing some imperative, functional, and object-oriented features.

The way languages evolve is getting more and more independent of the systems we work on, and with. Modern languages are cross-platform. Thanks to the growth of DevOps, the language selection becomes less and less important.

Thanks to the modern infrastructure, complexity is moving from the application to the external platforms.

The classic infrastructure on a physical server in the basement is displaced by cloud providers and related technologies. We have VMs as a service, databases as a service and many other infra elements as a service. Major of planning in a software solution has moved to the high-level design of an infrastructure, since much can be automated based on it. Additionally, we have containers and container orchestration. It takes over the complexity, since we can divide the system into smaller and simpler parts.

Application code gets more independent of the platform. The complexity, however, lies in the infrastructure and operations. Application developers focus increasingly on business logic. DevOps engineers handle the rest.

9. SCRUM != AGILE

Adopting specific processes usually leads to learned behaviors, which ultimately lead to habits. At least, that’s the theory of it.

In some cases however, processes stay processes that people trudge through just to go through the motions, but the behaviors never develop. Think of it this way, how many development teams have you seen go through all the Scrum rituals but not actually working in an agile way? Too many? We agree.

So what can you do? First, team buy-in, this is always the first step that needs to be established. If your team does not see the value in working using this methodology, then all the processes and rituals will not move the needle much in the long term.

The second step is to make sure you have a great scrum master and project manager to ensure good practices are being passed onward and that any objections are being

The third step is to realize: forcing Agile values & the Scrum framework down people’s throats when it doesn’t hold any merit will get you nowhere, fast. We’ve covered this point and many more in detail in our post titled “Scrum isn’t the answer for every IT project (itmagination.com)”.

SCRUM can be agile, but it does not guarantee agility. Agility comes from behaviors, not only processes.

10. Continuous Security

As we wrote many times before, security cannot be an afterthought. We cannot simply “leave it for later.” Checking apps for security issues has to be integrated into the DevOps process, and into the development process itself from day one. Luckily, there are few tools we may use to make the process frictionless. One of them is Snyk. It’s a comprehensive tool to “[f]ind and automatically fix vulnerabilities in your code, open-source dependencies, containers, and infrastructure as code[…].”

We must apply security checking procedures in the development cycle. Security is a base of trust – the currency of the future.

11. Audit the prices of cloud provider’s services

As the three main cloud providers enjoy virtually no competition, and differences in services they provide are (more or less) arbitrary. The only difference that we may see, realistically, is the difference in the price of services. This is why, being biased about this one particular provider is not necessarily bad. There really is, mostly, little to no difference.

Choose whichever provider you are comfortable with, and already know. Assess as you go, and don’t be afraid of change.

Cloud providers have no virtual competition and no cost arbitrage. Cloud infrastructure costs are very dependent on inflation and recession.

12. Everything can be done “as a Service”.

Platform as a Service, Infrastructure as a Service, Database as a Service, Software as a Service, Backend as a Service… We spared you more examples, and you should get our point across. Everything you can think of can be done by a third-party and sold to you.

Using these services is a trade-off. You give up some control to become leaner, and to be able to iterate faster, as well as to save some money upfront.

Due to the growth of the importance of cloud providers and serverless approach, every piece of software can be done as a Service.

13. Everybody uses Visual Studio Code.

Visual Studio Code took the world by storm. The combination of having the backing of Microsoft, having an Open-Source license, being written in TypeScript, and allowing for an easy extension of functionality were great decisions. The text editor is, by far, the most popular choice among modern programmers. Other choices, such as Intellij-based Integrated Development Editors (IDEs) or Vim, are in Code’s shadow, though JetBrains’ Fleets might change that.

Thanks to the multiple extensions and customization tools, VS Code becomes the most popular IDE among developers.

14. TensorFlow is widely used these days.

TensorFlow, Google’s framework for Machine Learning is an incredibly popular choice among programmers. For one, it is in GitHub’s top 20 for the most starred repositories. Then, there are multiple ports, including the JavaScript one, which teams use in their e.g., React Native apps, or web apps in React or any other JS framework. This provides enormous flexibility, and allows teams to embed the solution in many solutions.

Thanks to TensorFlow we can implement AI solutions in web applications. The models for training are provided by the library. Developers should focus on training them.

A great long-term hiring strategy is to hire juniors and train them.

Hiring juniors is a good long-term strategy. While there is no “best strategy” that’s a fit for all companies, hiring juniors and training them is definitely one of the best ways to grow and retain in-house talent.

Hiring juniors is a great way to scale up your team slowly over time, and building an internal culture that is easier to mould when compared to hiring people who are possibly set in their ways. Juniors also give a fresh perspective and are more in touch with current trends.

There are a few cases where this isn’t ideal, for example when your company needs to scale and develop new features rapidly. It’s also not the best if you have a small in-house team who are constantly trying to catch up with their backlog due to unrealistic development expectations. In that case, hiring an external technology partner to help with development while scaling up the in-house team in tandem could be a great middle-ground solution.

Hiring juniors to train them as a strategy doesn’t come without pitfalls. Juniors who are on your team are not vetted by previous companies, they don’t have a work history, and it may very well be a hit or a miss. The unfortunate reality is that while this strategy can be great with appropriate compensation packages, junior employees may find themselves in positions where they can double, triple, or even quadruple their salary by simply moving companies, rather than waiting or pushing for a promotion or raise.

This is why it’s so important to have transparent salaries and pay scales to show people where and how they can advance in their career path. This is why it’s also crucial to have great onboarding programs to make sure that the time spent on training the juniors is well-spent and benefits both the mentors and mentees.

According to numerous studies, a great long-term hiring practice for software developers is to hire non-experienced engineers and train them into the ways of the organization.

Rust: The Perfect Language For Blockchain Development

ITMAGINATION — Fri, 25 Mar 2022 00:00:00 +0000

Rust, Graydon Hoare’s creation, is the famous language for creating fast and secure applications. The language is also universally well-liked, earning the top spot in the Stack Overflow Survey 6 years in a row!

It’s no wonder, then, that many major companies, such as Discord, 1Password, Dropbox, and Toyota decided to embrace Rust, the language developed in 2010.

What makes Rust different?

Rust’s design is unique, and crucially, it aims to answer the oldest existing question: how to eat a cake and still have that cake. In the simplest terms, it solved the challenge of having a tool for designing apps that do not compromise on performance while at the same time, save you from potentially dangerous flaws.

Of course, if you need to escape some of that safety, you may. Even though it is highly discouraged, a simple unsafe statement will do the trick.

Another key feature that many programmers always appreciate, is how easy it is to generate documentation. If somebody published a piece of code for others to reuse, you may find documentation for it on docs.rs. Frankly, there are few languages that even match that functionality (Go is one of them, of course).

The Gotchas

Of course, claiming that something is without flaws is delusional. The designer of the language, and the team behind it now, had to make tradeoffs.

One of them is the language’s excessive wordiness. Writing option.as_ref().unwrap().borrow() is a Rustacean’s (that’s how Rust programmers call themselves) constant companion for better or for worse.

Furthermore, the editor support appears to be top-notch, but only on the surface. There’s a JetBrains’s plugin for CLion, an extension for Visual Studio Code (VS Code)… Or is it? Suggestions are often a miss, and the functionality often crashes, and it’s slow.

Overall, there are definitely more shortcomings, and we can’t pretend there aren’t. The optimistic accent is how the wider project handles flaws and challenges. One example is how the community handled one highly requested feature: asynchronous programming.

See for yourself at https://areweasyncyet.rs/. In short, there was a popular movement of programmers to co-create the necessary foundations for the feature.

Rust’s Use Cases

Specifics aside, there are use cases In the same way that we won’t see a supercar making deliveries, or a delivery van race on a track - programming languages have their use cases that they're built for.

Rust excels in all the (most frequently) multi-platform, high-performance scenarios, where security cannot be an afterthought:

Blockchains
Browsers
Operating Systems
Cybersecurity Products

These all successfully use the airtight language to improve their offering.

There are some scenarios, however, where we have to resort to using C, or C++ instead. Embedded development is one such area. In this case, engineers have to apply solutions that are sometimes older than they are. It’s a sad necessity since memory and CPU speed are a luxury. Though that might be for worse. As a matter of fact, C may have been indirectly responsible for a series of car crashes, and billions of dollars of losses for one automotive company (pages 36, 38, 40, 43).

Sadly, the affair happened before 2010, therefore the only way to produce better code back then was to voluntarily adhere to standards.

In cases of web back-ends, developing them in JavaScript, Java or C# are the best suited tools. It’s an active sacrifice of the app’s performance for quicker iterations and shorter development time. Little do people know, however, that Rust apps make terrific front-end web apps.

Did you know that Figma allows people to create their designs using the super safe language under the hood?

Blockchain projects running based on Rust

Safety, easy multi-platform development, speed, and quality is just what blockchain developers need - and where Rust excels.

For all the enthusiasts out there, you may even find a dedicated newsletter updating everybody on advances of “Rust in Blockchain”. The amount of high-profile projects in this area alone is impressive, just to mention Zcash, and MobileCoin.

We want to highlight different projects, however. Some higher-profiles ones are:

Solana

The project started in November 2017 and had one goal from day one. They wanted “a blockchain built from the ground up for scale.”

‍The story began in 2017, with a scientific paper by Anatoly Yakovenko. Few years down the line, and we have a top project with numerous contributors, and a strong community. Solana and Polkadot are fighting Ethereum on their quest to become the choice for Web3. Will they be successful? Only time will tell.

Question: how do you build something extremely fast, and safe at the same time? The Clear Answer: You develop it in Rust.

Engineers from Geneva, Switzerland, use the programming language to ensure the highest levels of safety and speed. To achieve higher efficiency, the team even restricted the language features available.

The effect? “710,000 transactions per second on a standard gigabit network if the transactions are, on average, no more than 176 bytes.”

Note: The name Solana is “a nod to a small beach town North of San Diego called Solana Beach, where Anatoly, Greg and Stephen [the founders] lived and surfed for three years when they worked for Qualcomm.”

Polkadot

Polkadot, a London-based organization, “envision[s] a Web where our identity and our data is our own – safely secured from any central authority.”

That’s not their only goal either. The team sees their mission being “connecting private and consortium chains, public and permissionless networks, oracles, and future technologies that are yet to be created” as well.

How do they want to do all that? You guessed it: build a solution on top of Rust.

While the team, primarily based in London, explicitly highlights the foundation is Hoare’s child, the project also states that Go and C++ are among the languages in use “making Polkadot accessible to a wide range of developers.”

Hyperledger Sawtooth

If you played “spot the odd one out”, then here is the correct answer. A little different from their colleagues, Hyperledger solves other problems altogether. While the former two are public blockchains, Sawtooth is an “enterprise solution for building, deploying, and running distributed ledgers.”

The company, based in San Francisco, USA, uses Rust to “to give application developers and administrators more control, more flexibility, and greater security for their blockchain networks.” The team switched to Mozilla’s language from… Python.

Guido van Rossum’s creation had one purpose: to facilitate prototyping. After a year, in 2019, the team decided to rewrite the project to Rust, enabling them to ship better code. Teams have “account for all possible error and edge cases”, thus low-quality code will not get a pass from the compiler.

Comparing that to C++, or even Python, the solution will be of higher quality, due to the strictness of the language and its compiler.

Conclusion

But… is Blockchain development, and low-level (advanced operations where speed is a must) development the only things I can do with Rust? No! In fact, full-stack development is not only the domain of JavaScript. Maybe a Nest.js and Angular (JavaScript frameworks) are enterprise favorites. However, nobody says you can’t make an app with Actix Web, and Yew (Rust alternatives to the aforementioned solutions) just as well! If you prefer to keep your current web engineers, then that’s quite alright as well. You may just compile your code to run inside, e.g., a React, Vue or Angular app.

Whatever you are using Rust for, should you want to have a conversation about your project, don't hesitate to get in touch with us here to talk about our Blockchain Development Services. We would love to talk to you.

Developing Your Web3 Decentralized Application: 3 Things To Consider

ITMAGINATION — Wed, 08 Dec 2021 00:00:00 +0000

Web1, the grandparent of Web3, was all about decentralization. Everything was community governed and open. Value was not in the hands of the service providers, but at the very edge — in the hands of individual users and groups of multiple users.

“Web 2.0” was a term coined in 1999 by Darcy DiNucci, later popularized by Tim O'Reilly and Dale Dougherty during the O'Reilly Media Web 2.0 Conference in 2004. In this chapter, the power resides, and has always resided centrally, with the platforms, such as Facebook, Google, and Twitter.

This has caused many problems (Cambridge Analytica anyone?). The argument for the new name was different, however. It was that before the new era, content was mostly static, while Web2 was about dynamic content. Not all agreed (not even the creator of the internet himself), but the name stuck.

Fast-forward to now, we are possibly living at the start of the new era, the time of Web3. The time when we have decentralized apps that run on blockchains. Now, we can finally make things right. The next iteration of the web aims to fix many of the shortcomings and flaws of the previous version.

The code that governs transactions, and runs on, e.g., Ethereum’s (ETH) virtual machine (EVM), is visible to everybody in its entirety. There are no surprises here.

Web3 apps are also much safer. That is because the authenticity of your code is ensured by all the Ethereum nodes around the world. Of course, ETH is not your only option, which is a blessing, as the chain does not have the highest bandwidth possible. In practice, the network is limited to only up to about 15 transactions per second, which some alternatives solve quite well. These are Solana, Polkadot, or EOS.

With the problem of scalability gone, there is one concern that does not go away. No matter which solution you are using, the complexity of new apps sharply rises.

Complex? Not necessarily.

Despite what one might think, Web3 apps are more complex than their Web2 ancestors. Sure, you don’t really write your back-end code anymore in a way that you used to, nor do you manage your backend like before.

There is not exactly a server you need to worry about. The lack of a traditional backend could be seen as a positive. There are so many things you don’t need to worry about or configure.

On the other hand, traditional servers scale much better. You do have to start adding resources eventually, though, though definitely you will not run into a brick wall. The difficulties start when your product becomes known to more and more users.

Ethereum cannot handle too many operations at a time, which it has a bad rap for. The limits can become painful, too fast. There is a light of hope, however. The Eth2 update started on October 29, 2021, with the aim of making the chain more scalable.

The complexity is a result of bypassing the limitations of Ethereum. IPFS to store data, Layer 2 solutions for increasing the number of transactions possible at a time.

The graphic below illustrates what an app’s architecture can look like.

Decentralized? Absolutely.

Web3 does not resolve the issue of centralization fully, either. We still have to host our web apps somewhere. It more often than not will be on the servers of a cloud provider, such as AWS or Azure. There is always an option to host everything on your premises, though we definitely see a trend to do otherwise.

Http is not a necessity, however. The traditional way to access websites (including ours), is not the only way for your clients to access your new app. The Interplanetary File System (IPFS) or Swarm can be the alternative routes to your service. Of course, the majority of your users will not have the necessary extensions installed. Most likely, you will have to host your service in both the “traditional” way, and the Web3 way.

Costly? It depends.

Even though we do not have to have a database, saving all our generated data to the Ethereum chain can become very costly, very quickly. If you feel it would be better not to run out of money too fast, you might store data off-chain. There are a couple of options for you to do that. There is the IPFS, and Swarm.

IPFS may serve as decentralized storage for your app, though as it aims to replace http, your clients would have to at least have a custom extension installed to view the website you’re sending them to. Swarm is another solution to the problem. You may host your websites on the network, and also enjoy the benefits of hosting your app on a decentralized network.

There are some clients There is also a Chrome-based browser, Brave, that comes with an IPFS functionality built-in. If you want a good Web3 compatible browser, that would be the best choice. Another browser that comes with the native IPFS support is Opera. Both of them might be too niche for your taste, so if you want to keep using your current browser, you may download the IPFS Companion extension.

Conclusion

There are always obstacles to overcome when any new tech reaches the phase of Early Majority – do not be discouraged that it’s the same way this time. Obstacles can be overcome in some of the ways we have described.

These obstacles are no mountains that one cannot climb. If you are discouraged by the limitations we have now, it would have been similar to claiming something like “Netflix will never work” back in the dial-up modems days. Sure, it would not have worked then. What was needed was a couple of breakthroughs that did come, in time.

Once you overcome these obstacles, there is a whole another world waiting for you and your users. A world where you and your clients literally own parts of the web. A more democratic world, than the one we have now. If you need a hand stepping into this world, feel free to check out our blockchain development services and contact us!

Originally published on https://www.itmagination.com/blog/developing-web3-decentralized-application-3-considerations

Change Blindness

ITMAGINATION — Fri, 19 Nov 2021 00:00:00 +0000

Designing interfaces always happens with a goal in mind, whether it’s a purchase, sending a form, or performing a calculation.

A properly designed UI may influence an outcome of a task dramatically. The way it’s built may mean the difference between failure and success. It’s because in the midst of all tasks, schedules, and to-do lists — it’s too easy to miss a change.

Were you ever in a situation where you wanted to attend a meeting on Teams that either already happened in the past, or one that is coming up in the future? If so, it might have been because you missed a change in time; especially in a situation when your calendar is frequently updated. Our senses are relentlessly bombarded by the constant waves of triggers that can overwhelm our brains.

Change blindness is you missing new visual details added to an existing canvas.

The Gorilla In The Room

Daniel Simmons & Christopher Chabris have conducted an experiment at the University of Harvard, during which they showed everybody a video.

In the video, you will see two teams playing with a ball. One is in black t-shirts, while the other team is in white t-shirts. Scientists asked participants to watch the video and count how many passes the two teams completed. Please watch the video, and let’s see if you will get the number right.

Now that you have watched the video, have you gotten the number correct? More importantly, though. Noticed anything unusual there? Maybe a gorilla? Watch the video again now.

This time, don’t count the passes. During the original study, almost half of the participants did not notice the gigantic monkey. Did you?

A Good Old Switcheroo

In another experiment, a passer-by asked a stranger for directions. During the conversation, the person asking for directions was replaced by somebody else. Yet again, almost half of the “victims” did not notice the change.

Despite our best intentions, we can only focus on one task at a time (we're looking at you, people who talk over their phones while driving).

Vans - Off The Mark

Another example of Change Blindness is the now changed mobile version of Vans’ website.

When a user chooses a size that is not available, the button label, saying “Add To Cart” changes to “Out Of Stock.” The difference was not visible enough, however, as the difference in text was not big enough.

In the current version, if a shoe size is not available anymore, you may see it right away, and the button to add it to cart is disabled.

What could be a factor in “change blindness”?

What we say is transformed and interpreted by our brain. To make the world comprehensible, it has to prioritize what is the most important for us to reach our goal. On the flip side, it filters out anything that is unnecessary for us.

Any pauses in our perception, such as when a website loads, or when we blink, will most likely not get picked up. Sadly, even the best designed communication, be it on buttons or progress bars, if noticed by your user, might mislead them.

If we want to support your users in reaching their goals, you have to remember a few things.

How can you design better interfaces?

Changes need to be signaled clearly

If we filter data too fast, the person on the other end might not notice the change. It is therefore necessary to appropriately accentuate the shift with the right alert that something happened, or that something is about to happen.

Take a look at a notification you get when your phone battery is low. It is close to impossible to miss it, and probably after getting it, you started to frantically look for your charger.

There is a good rule of thumb — your change will likely picked up if you will be able to notice it even if you lean back and squint your eyes.

The right positioning

A good practice is to design your interface to place key information close to the place where your users might be working on their task.

For example. when somebody is filling out a form, make sure to display feedback right next to the place where somebody is editing data.

Animations

Animated icons or feedback after an action moves somebody’s sight to the place where it is required. Thanks to that, any alterations will not go unnoticed.

Remember not to overload your app with animations because there is a risk that a key shift will be missed among the chaos.

In conclusion, remember that your users need clear communication when something changes on a page, especially if this is a critical alert. The ways you can avoid change blindness are through clear signals, good positioning of those signals, and animating this signals when appropriate to make sure that there is a clear change happening for the user.

You can take a deeper dive into Change Blindness in this piece published by the Nielsen Norman Group and by checking out the dangers of change blindness in other cases like driving for example and how we are overly confident in our abilities to track and respond to changes.

Developing Performant Mobile Apps Part 3: Cross-Platform Apps

ITMAGINATION — Fri, 19 Nov 2021 00:00:00 +0000

There was once a time, when there were more mobile operating systems than just Android, and iOS. Some of you might remember Windows Phone, Firefox OS, or Samsung’s Bada. Out of the 3 niche platforms, only Microsoft’s OS enjoyed decent popularity at its height. Back in the day, when companies went primarily native, one extra platform to develop for meant so much more work for everybody.

That is a part of a reason why we don’t have Windows Phone anymore. Third-party support was mostly negligible, because of all the extra resources required to target an additional platform for developers. A lose-lose scenario for both users, and businesses — because of all the money that was on this untapped market. Cross-platform development, even though not new by any means, is now in a state where it’s increasingly chosen as the go-to by more and more companies.

Frameworks

There are few frameworks, that are standard choices for quickly developing quality apps, which we will cover. First, it is important to distinguish between the two main types of cross-platform frameworks. Even though they achieve the same goal, they do it in an entirely different way. There are the Web-based frameworks, such as Ionic, that, in the simplest terms, package web assets to apps.

‍Then, there are frameworks, that make use of native elements. Examples of these frameworks include Microsoft’s Xamarin, and Facebook’s React Native. As it is often with life, there are shades of gray. This is where Google’s Flutter is. Flutter does not use native elements. Instead, it renders everything itself, thanks to the superfast Skia engine.

When it comes to using JavaScript to create cross-platform apps, apart from React Native, you also have NativeScript, and Weex, though they are somewhat niche options. Your best bet in this situation is to go for the industry-standard, Facebook’s framework.

In this article, we will be talking about Xamarin (and Xamarin.Forms), React Native, and Flutter because they are the most popular in their category. We will also be explaining how the name “Xamarin” is the song of the past, and what comes next.

Let’s dive in!

Xamarin and .NET

Xamarin is the framework for developing apps with C#, and F# programming languages. In your apps, you may use almost all the underlying native APIs from the comfort of either C# or F#. Should some feature you are looking for be missing, and you can easily call Java, C++, C or Objective-C code, giving you a wide range of options.

Xamarin is technically divided into three subprojects. There is Xamarin.Android for Android development, Xamarin.iOS for… you guessed it, iOS development. Both of them are often referred to as Xamarin.Native. Then there is Xamarin.Forms for when you want to achieve maximum code reusability across the targeted platforms. The code governing interactions, and the actions, will be the same.

The difference is in the code that determines how the user interface looks like. In one case, it’s specific to each platform. You have to write everything specifically for the platform you are targeting; iOS code will be different from the Android code. In Xamarin.Forms, almost 100% of the code that lays everything out on the screen is the same.

The future of Xamarin

With .NET 6, some changes are coming regarding the structure of the projects. Xamarin.iOS, and Xamarin.Android will become .NET for iOS, and .NET for Android, respectively. Xamarin.Forms will become .NET MAUI, or .NET Multiplatform App User Interface. The name highlights the main focus of the platform: code reuse.

React Native

One person once said, that if something can be done using JavaScript, it eventually will. As JavaScript’s importance grew over time, it became more, and more, apparent. Facebook’s developers had a big part in that, with their release of React, and React Native. The big benefit is the reuse of code that dictates what happens behind the scenes between the web app and the native app.

Twitter took things even further. What they’ve done is, adapt their mobile app using ‘react-native-web’ to run in the browser. It effectively allows them to use their mobile app as a web app as well, with less work than it would have been otherwise required.

React Native is by far the most popular solution to develop mobile applications using JavaScript. For a good reason. For better or worse, React is a standard choice for web development purposes. It is mainly thanks to its flexibility, and an overwhelming third-party support. The transition to React Native is a smooth one; much smoother than if you required them to learn e.g. Xamarin all of a sudden.

How does React Native work? Your JavaScript code gets executed, but it does not “speak” to the phone’s platform directly. That is handled by the bridge that talks to the native modules.

The solution enjoys huge 3rd party support, even from companies such as Microsoft. Not long ago, the company from Redmond shared their React Native for Windows, and macOS. The company even switched to the JS framework for their wider UWP app development purposes.

Developing user interfaces can be somewhat painful. This is a tedious task since everything you do, you need to do yourself. The set of shipped elements available out of the box is underwhelming, at best.

There is one thing to note in this section. As of the time of the writing, the library’s version is at 0.66. This means, that there was no stable release yet. Even though it’s battle-tested, and used by the biggest of the biggest, we are still waiting for the version 1.0.

Flutter

Flutter is one of the default options for creating apps for the upcoming Google’s new Operating System Fuchsia. It is pretty impressive, what can the framework do today. You may target iOS, Android, Linux, Windows, macOS, and the web using one codebase.

The problem that many companies face is the “exotic” language that you are forced to use. It is the Dart programming language. Dart is not bad in itself. It’s a pretty good, and it’s relatively easy to pick up for Java, JavaScript, or C# developers. As with every new environment, however, the issue is that it forced everybody to learn a new way of doing things, again. One cannot reliably use Dart on the server side, as well, as it's the case with JavaScript, and C#.

Perhaps the greatest feature is the rendering engine, Skia. It is a complete 2D engine for rendering text, images, and more. It promises smooth 120 frames per second (!) without difficulties in the world where many frameworks aim “only” for 60 frames per second (in reality, 60fps is more than enough, however). Another great advantage is the enormous depth of provided elements out of the box. Material Design or not, it’s impressive.

Now that we know what are the main solutions available, what are the pros and cons of cross-platform mobile app development? Even though the solutions we mentioned achieve their goals differently, they share about the same pros and cons.

Pros and Cons of the Cross-Platform Approach

Pros

Cross-platform apps sit right in the middle between native apps, and PWAs in terms of all the aspects. There is a reason why, when facing uncertainty, people flock to the safe middle. You are likely choosing one of the safest options, without experiencing extreme effects.

Exactly, so your apps will be quick. Not quite as quick as native apps, not quite as slow as Web-based solutions. You won’t have to pack too much additional assets required, but you still will have to ship some; in case of Xamarin is the Mono code. Even then, the apps will be quick enough. Your users will likely not notice any “hiccups”, should they occur.

Cons

Sadly, not all native APIs are accessible to you. Usually, that won’t be a problem, however. If something is not available by default, there are third-party packages available for you. An excellent example for the community support is React Native. The amount of additional functionality brought to you by the community is overwhelming.

With great power comes great responsibility. 3rd party packages can introduce numerous bugs and security flaws. Let’s look at React Native, again. It’s not uncommon for vulnerabilities to pop up in npm packages.

In September 2021, a package enjoying big popularity got hacked, allowing for the execution of arbitrary code. Another example features the ua-parser-js package where a malicious party uploaded to the central base where it was downloaded by the unsuspecting developers. It enabled hackers to download additional files to your PC. Even though all the flaws were quickly fixed, the bad taste remains.

We will note, once again, that an app’s speed is lower. Of course, as Unity games run pretty well highlighting the potential of high-performance cross-platform apps, they are slower than they could have been.

Xamarin vs React Native vs Flutter

React Native

Each framework has their unique pros and cons as well. React Native will feel familiar to React developers, you use JavaScript and TypeScript to write apps, though you have to do everything manually unless you use 3rd party packages. The documentation is rather poor, though the community has got you covered.

Again, we have to note that we are still waiting for the 1.0 release, which means we are yet to receive a truly stable version. Don’t be fooled, though. The biggest of the biggest rely on the framework to write apps, and it definitely is battle-tested.

Examples of apps developed using React Native

Soundcloud Pulse
Facebook
Instagram
Walmart
Bloomberg

Flutter

Flutter is an excellent project, wowing everybody with the speed of development, and the breadth of user interface elements available right out of the box. Apps are lightning speed as well. Sadly, the Dart programming language can be a bit of an obstacle. Concerning the design system, you are locked in to Google’s Material Design. While it is a flexible design system, it’s necessary to keep this in mind.

Examples of apps developed using Flutter:

eBay Motors
Tencent Apps
My BMW
Google Pay

Xamarin

Xamarin, or should we say .NET for iOS/Android and .NET MAUI, are great for big enterprises — C# is an immensely popular language already. The ability to develop for a multitude of platforms using the same platform is a great benefit. Being highly opinionated is always a good aspect in environments, where your product will be developed by many developers over many years, often without documentation.

One has to admit, however, that .NET isn’t as loved as the other two. Sure, .NET Core was the most loved platform in 2020, according to Stack Overflow. Xamarin, specifically, was not as lucky, placing much lower than Flutter (which came in third), and React Native. It was not particularly highly desired.

Examples of apps developed using Xamarin:

Bitwarden
The World Bank
Fresh Direct
Microsoft News

Conclusion

One thing is certain. No matter which one of these frameworks you pick, you will be able to develop a quality app, should you follow the appropriate process. If we are to make recommendations, we would definitely recommend React Native, and Xamarin, without hesitation. The nuances of all the approaches are far too deep to be discussed in a single article, however. If you have any more questions about the topic, feel free to contact Marcin Dąbrowski, our Chief Innovation Officer.

ITMAGINATION Is Certified As A Great Place To Work® For The Third Year In A Row!

ITMAGINATION — Mon, 15 Nov 2021 00:00:00 +0000

Our team voted, and the results are in! ITMAGINATION is certified as a Great Place To Work® for the 3rd year in a row! 🎉

The Great Place To Work Survey is an anonymous survey sent to our team every year around October, where we collect their feedback and see what we are doing well and what we can do better. This year, we have been awarded the Great Place to Work® certificate for the third time in a row, after becoming a laureate of the Best Workplaces™ award in Poland for 2021 — and we couldn't be happier!

“The Great Place To Work survey is an essential part of our feedback collection and continuous improvement processes at ITMAGINATION” says Dawid Łaziński, Co-Founder and Board Member at ITMAGINATION.
‍

“The Great Place To Work Certification is a clear indicator
that we are listening to our team and improving based on concrete and anonymous feedback — as well as continuing to do what they appreciate in the workplace at ITMAGINATION.”

This is a prestigious award from the American institute, which, as a result of assessing the feedback of our employees, shows that we have a great atmosphere and favorable working conditions in our House of Innovators. Similarly to last year, we will soon release more detailed results about areas where we excelled, as well as which areas we will be improving over the next year — stay tuned!

Join our team!

Take a look at our open job opportunities here.

Meet the Innovators with Krzysztof Nowocin

ITMAGINATION — Fri, 05 Nov 2021 13:56:10 +0000

In this podcast episode, Krzysztof Nowocin, Data Developer at ITMAGINATION, joins us talking about his hobbies, work-life balance, remote work, and his career path moving from System Admin to Junior Data Developer and then to Data Developer.

Interested in joining the team? We have many open opportunities available to develop unique data solutions!

Are you more of a podcast person? Listen to the episode on Spotify!

Read The Transcript

‍

Aleksander: Hello, and Welcome. My name is Aleksander Jess. I am a marketing specialist at ITMAGINATION, and today I'm joined by KrzysztofNowocin, who is a Data Developer at ITMAGINATION.

Hello, Krzysztof. How is the sea today?

Krzysztof: I hope that it's warm, probably today I will walk by the sea, so I can check the temperature.

Aleksander: Warm by the Polish standards or by normal standards? Because that's a “warm” by the Polish ones is 15 [degrees Celsius]. And you're calling in from Gdynia, right now.

Krzysztof: Yeah. I live here and I work from here.

Aleksander: So, that's somewhat remote work for the win. If you had to describe yourself using three words, what would they be?

Krzysztof: Yeah, the hardest question at the beginning?

Well, I guess that I like to skill up. I don't like staying at home too much. As far as you said, I have a sea nearby, so I really like to walk [along the coast]; do all the other activities probably; also spend some time on my hobbies.

Aleksander: Right. You like to spend time outside, so I guess that we're not playing any time soon…

Krzysztof: Yeah, unfortunately, I guess that's as [long] as the weather is fine, I would prefer to have fun, walk over [the neighborhood], by the city, go to [a café] outside, rather than staying home and just playing computer games. But I guess that in two months, I will join you.

Aleksander: Ok, I'll take your word for it. So, you've been actually living by the sea, all your life. Are you doing any water sports after work?

Krzysztof: Well, I have to say that I like to test everything, so I have an open water diver license; I've tried some water skiing by the lake and soon. But if I had to be honest, it didn't go as well. So, I prefer all the of the sports where you can wear your shoes rather than the water ones.

Aleksander: Understood. Understood. You also are quite a photographer, aren't you?

Krzysztof: Yeah, I think photography is a pretty cool hobby. You can do[a lot] with your camera… There are [many] possibilities. You can make a portrait… You can take a landscape… Sports… Long exposure… And so on. So, I like to have fun and [use] different, different, techniques, so, it's never boring.

Nevertheless, I'm just an amateur photographer, so sometimes, from time to time, I go, and help my friends take the photos of their weddings, of their any other celebrations, and just having fun.

Aleksander: I'm hearing [numerous] possibilities and a lot of different things going on because you do a lot of sports. You said you like outdoors, photography… Is your work life the same as your private life? Many things going on?

Krzysztof: Yeah, I think [so], yes, my journey with [being a] data developer started with, I may say, like a back end where I was preparing some data warehouses, some ETL processes. One day, I've just had a chance to pick up a Power BI project where I had to prepare something more…some UI/UX skills and had to test it myself.

So, I've done a report, done another report, and each [and every] next [was] a bit better. This tool gives you, just like in photography, many possibilities to present the data in many, many ways…

Aleksander: …and getting better each time you prepare something?

Krzysztof: Getting better and better. The tool is being upgraded [each]month, so you need to, well… Follow the latest updates, to, well… To prepare the best solution for the banks.

Aleksander: How is the tool getting updated?

Krzysztof: Yeah, so each month they bring some new tools and new features; some of them are just in preview, so you can test [them]. It's not the final release, but you can use [them] on the report.

There is also… Each month, they present them in a cool YouTube video, so I try to follow them and know about the latest, the latest things. For example, last month, they added a new possibility; some conditional formatting which was missing and some visuals I was using. So, it's pretty fine. And stuff like this.

Aleksander: Would you say you have a chance to use new features at work often or… How is it?

Krzysztof: Well, it's not that often, I may say because some big features which were presented [towards the end] of 2020 which I was using. We were waiting with the client for the feature, which enabled two methods of work- which was connecting the live connection to the data and an import, which wasn't available but was really missing.

We were waiting for this feature to be present for like three or four months because it was announced that it will [appear]. Finally, [the new release] came with it, so we had the chance to try it out.

Aleksander: Ok, I see. So, you are now a data dev, and it seems like you're loving it, but you weren't a data dev to begin with because you actually began as a network admin.

Krzysztof: Yeah, I did. I was working in my previous job, as I may say, a System Administrator where I. Well, basically everything that should be connected to electricity and work was on my shoulders.

So, I was doing stuff: from switching the keyboards up, [through] starting Windows [machines] up, [to] the administration of some small network, area storage and stuff like this. So if you are doing it for a few years, you are getting bored, I might say because you do things again, and again, and again, so you are looking for some new possibilities.

That's why I was thinking about [making] some change. And [when] my newest friend started [to work as] data developers, well, uh, I spoke with him. He told me about how does it look like. I decided that maybe I will try out myself at working in this profession as well.

Aleksander: And you're at ITMAGINATION for three and a half years now, aren't you? How did it start? How did the journey at ITMAGINATION start?

Krzysztof: Yeah. Basically, the fact I was speaking about is one of the employees which is working a few months more than I am. So, he basically told me about the job, as I've said previously. So, I've just earned one Microsoft Certificate to [showcase]some skills in [presenting] data, and I've [sent my résumé]. That's how it started.

Aleksander: Ok, I see so. He also received some monetary bonus for a referral. For a successful one.

Krzysztof: Yeah. He did, that's why he was probably very pleased to grab my CV, but he described me as a good person, as I've heard from the manager[during the interview]. They found out that I was a good candidate, I hope. He also got the bonus.

Aleksander: So you began as a Junior Data Dev, and now you are a DataDev. How was it? How was the transition?

Krzysztof: Yeah, I had to say that I had an awesome, awesome team[when] I started, I had a few friends. I could really ask for help. They taught me a lot of different, different things about the data, about SQL, all about the SIS, which is this ETL [Extract, Transform, Load] tool I was speaking about, previously.So, I had the chance to skill up really fast thanks to the people I've met in the company. So it is pretty awesome.

If I had to be honest, I started to be a Data Dev [starting out as a] Junior in just a few months, so it was quick. But I guess that I have to thank the people I've met here.

Aleksander: Because from what I've read on LinkedIn, you have two recommendations and both of them are talking about being a team player. And you're a team player, both in private and in work life as well. Well, how important is a good team for you?

Krzysztof: Yeah, I think that I think having a team is critical because it often happens that something doesn't go as planned in the project. If you have a good team, know how to shuffle your tasks between the people; some of them are really doing everything to make everything work or sometimes stay a bit longer to end the task, so you can end your tasks the next day, it's very, very important. Also, sharing the knowledge; solving the problems is everything that makes up way much easier when you have team members that can help you.

Aleksander: Right. I totally agree with you. And on that note, it's time to end. Krzysztof, thank you so much for your time.

Krzysztof: Thanks a lot. Have a good day.

‍

Aleksander: It was a pleasure to talk to you, and have a good day as well. Cheers.

Next.js 12 - 5 Changes You Should Pay Close Attention To

ITMAGINATION — Tue, 02 Nov 2021 20:00:00 +0000

When developing a website, configuring your framework or library used to be a headache. You used to have to enable numerous crucial features manually, which took some time and a whole lot of patience.

Next.js was created to simplify the development process, and developers really appreciated that. It is the most popular framework in its category for React, and perhaps the most popular hybrid web framework in general.

Last week, Vercel (the company behind Next.js) shared that they are releasing Next 12 — the next major upgrade. There are a few features that should make the Developer Experience (DX) even better, while there are also some novelties that allow for entirely new solutions to be developed.

Rust Compiler

Compiling a big website can take a lot of time. Vercel realized it, and introduced a new compiler written in Rust, which is faster than the predecessor. Based on SWC this move is a part of a broader movement towards tools written in Go (e.g., esbuild), and Rust (the aforementioned SWC), as you can easily compile code in these languages to lightning-fast WebAssembly.

The speed is something to admire. The company shares that Fast Refresh is now three times as fast, while builds take five times less time. Comparing SWC to Babel alone, the Rust-based tool is a staggering 17 times quicker. In case you were wondering what codebase was, the benchmark run on, the results were “from using the new Rust compiler with large Next.js codebases.”

Middleware

A new introduction to Next.js, Middleware, gives you an opportunity to call code before a request is completed. Thanks to that, you may modify the response by “rewriting, redirecting, adding headers, or even streaming HTML.”

This gives you a lot of space to maneuver in, and a chance to do a lot, including:

A/B testing
Bot protection
If your site is non-compliant with GDPR, you may restrict traffic from the EU
Analytics on the server side
Much, much more

It all works out of the box, of course, and Middleware will work on the Edge as well, with few restrictions on what is available in this environment for you. For details, please refer to this page from the official documentation.

What Exactly Does “Edge” Refer To?

Speaking of the Edge (no, not the guitarist from U2): in the simplest terms, it’s computing done near the request to cut down on latency.

Native ES Modules Support

ES Modules are nothing new. In fact, they were introduced all the way back in 2015. It took a while to adopt them, however. Node.js started to natively implement ES Modules in March 2021! Browsers were a bit faster. Firefox was the last major browser to adopt them in 2018 with Firefox 60.

The new modules are a big deal because they enable developers to ship less code, making your apps snappier. ES modules also run in the “strict” mode, outputting some smaller errors that otherwise JavaScript would not mind. When using CommonJS modules, developers had a choice whether to use it or not. There are of course many other benefits of using ES Modules over CommonJS; however, an in-depth look is beyond the scope of this article.

Dynamic URL Imports

At the first glance, many will miss this new feature. Seemingly unimportant, this does change a lot in the JavaScript & TypeScript ecosystem. While NPM as a central store for JS packages worked, and works, some developers might opt out of its monopoly, preferring to store their packages elsewhere. Here is where Content Delivery Networks (CDN) come in.

In short, instead of pulling packages from the centralized store, you may now install them from wherever you want. Next.js then caches them, and they are ready to go.

The only requirement is for you to let the framework know what is the domain of the CDN you want to use, and it’s done!

This is how to do it:

Preparing for React 18

React 18 will bring numerous new features including Server Components, Concurrent Rendering, and Automatic Batching. All three of them aim to make React snappier, and lighter; the opponents of the library often said that Facebook’s (Meta’s) creation is too heavy and too slow for what it’s doing.

If you want to take a look at the new features of React 18, go to our GitHub repository.

React Server Components

Perhaps the most “cryptic” change coming to the newest major update of the front-end JavaScript library are the Server Components. Vercel also mentioned them in their presentation as one of the main features. Why? What are the benefits? There are many. First, they reduce the bundle size. By quite a lot, actually. Let’s say you want to render markdown on your website. Simple enough. You need to sanitize markdown, and then render it. For markdown, we have “remark”, and for sanitation, we either have “sanitize-html” or “dompurify.” That used to require additional ~29 to ~66kb. With the server components, the additional JS size goes down to zero.

Additionally, we can load data directly from the server. We don’t have to wait for the client to request some data, and later to load it. Web apps will become faster and respond quicker. This is a win for the internet.

Although Server Components sound like Incremental Static Generation that Next.js allowed for, for some time now, ISR will most likely not get deprecated, and the two APIs will coexist together.

Breaking Changes

As is sometimes the case with major updates, there are some breaking changes the team behind Next.js decided to implement. Luckily, more often than not, they are not going to cause any problems to developers.

The one change that might become an issue is updating Webpack from 4 to 5. As the team wrote on their blog, they have “worked closely with the community to ensure a smooth transition to webpack 5.”

A few minor changes that should not impact you too much is that there is no need to set target in next.config.js anymore. The option had been introduced in Next 8, though the team quickly realized it was not ideal, creating @vercel/nft. It detects what code is necessary, automatically.

The other two breaking changes is that next/image now uses a span as the wrapping element instead of a div, and the minimum Node.js is now 12.22.0. This is due to the native ES modules support.

One thing that was not mentioned, is the breaking change in removing the possibility to switch React for Preact. It used to work without a problem in Next 11, while in Next 12 it may cause cryptic 500 errors. We do not recommend doing that, anymore.

Conclusion

Next.js enables developers to write quality React apps quicker. The new major update won’t disappoint React developers, and it will most likely be accepted with open arms. Should you want to try out some new features yourself, we have a project you can clone in no-time. Visit our repository by clicking this link.

Like developing React apps? We're hiring!

Do you like writing React apps, and think you are one of the best in the area? Do you like new technologies? See our open jobs — we work with the biggest companies in the world to deliver great web apps.

Solutions for Creating Mobile Apps. Part 2: Native Apps

ITMAGINATION — Tue, 02 Nov 2021 00:00:00 +0000

Modern mobile app development began with the first iPhone. Even though Progressive Web Apps were the first to be proposed for the device, they had some pressing problems. They were sluggish, and it was hard to create native-looking interfaces.

Apple released a remedy quickly after their announcement: an iOS Native SDK. Fast-forward to 2021, and creating native apps is the default. They are simply faster, and more performant than their non-native rivals.

Speed = Better User Experience

Speed is the ultimate feature of all apps. Mobile apps that can steadily maintain the steady 60 frames per second threshold without any rendering lags feel the best. One has to ensure any breaks are not longer than 400 milliseconds.

Naturally, the easiest way to achieve the goal is to use the programming language that will be evaluated directly by the phone’s OS. In other cases, your instructions have to be first translated to get picked up. This is a rather costly process, and it is not the fastest.

New Generation of Languages

Objective-C and Java are not the most well-liked languages in the world. In the most recent Stack Overflow survey results from 2020, 44% of developers declared they “loved” Java, with Objective-C earning a measly 23%. Respondents count as loving the language if they are “developing with the language […] and have expressed interest in continuing to develop with it.”

In comparison, Kotlin earned a respectable 62.9%, with Swift earning 59.5%. The language from JetBrains fixes many issues that plagued Java, such as the fact that the newer language handles “null” values much better, and the fact that one can avoid writing a lot of “boilerplate” code.

Swift

Swift can also be seen as a big step forward when comparing it to its predecessor, Objective-C. For one, the language is statically typed, which can catch bugs ahead of time. Furthermore, the company behind the language shares that the new language is up to 2.6 times faster than the previous one.

Additionally, Apple is constantly improving the language. This year, during the WWDC, the legendary company from Cupertino has announced a few exciting features of the language and the wider iOS development ecosystem. The language utilizes memory better now. It will automatically reclaim memory quicker than before.

You may now write async/await code, making non-blocking code easier to write. Three, and the “structured concurrency” (concurrency is referring generally to the execution of code at the same time), and the improvements around the area will surely excite all Swift developers. The new additions allow for safer, and problem-free implementation of faster apps.

Kotlin

We have talked about Kotlin in the past — Jan Radzikowski, Android Developer at ITMAGINATION has shared his positive opinion on JetBrains’s programming language in the past in our weekly series 360° IT Check:

I would say that Kotlin suits me much better than Java, but I’m speaking from the Android Dev point of view. The first benefit that comes to my mind is legibility. Kotlin is quite concise and could be used in such a manner that you can read it almost as a novel.
‍
Another advantage Kotlin has over Java is that null references are controlled by the [Kotlin's type] system (NullReferenceException anyone?). You don’t have to annotate them at all.

From the specifics, there are no raw types, which in my opinion makes the language more consistent. What else?

Lambdas and inline functions

Extension functions! - they make a huge difference and improve readability and coding speed (when used correctly, of course)

The concept of primary constructors

Data classes

Objects and how Kotlin deals with Singletons

To end with, coroutines are a major benefit. They are a great way to replace the RxJava library and to be able to write easy-to-read and thread-safe asynchronous code.
The takeaway from this section is simple — the native development experience is improving constantly, thanks to the new languages.

Full Feature Set of Devices

Not all APIs are available to developers writing PWAs or hybrid apps. Every so often, one has to find an alternative solution to their problem, or write native code. All in all, at the end of the day, if you are forced to develop natively, then you might as well go all in, right? Especially that we are not talking about access to advanced functionality. E.g., to implement calendar event creation in React Native, you have to call Swift and Kotlin code from your JavaScript — there is no other way.

Application of Native Interface Elements and Practices

As we mentioned before, your users will be the most familiar with the design of other apps, not yours. One can easily leverage that fact by designing your app to give users the same feedback, work similarly, and utilize the same visual patterns. Where do people spend the most time? Inside system apps, of course.

If you are writing code, using native patterns is the default option. By default, your app will feel much more familiar; in-place.

This is not so obvious when you are writing an installable web app, or a cross-platform app. Web apps cannot use native UI elements, while some cross-platform frameworks, such as Flutter, forgo the option of native elements, in favor of rendering custom components, using Flutter’s Skia engine. Of course, there is React Native, which uses native elements; however, it does not implement all of them.

Double the Code, Double the Updates

If you are planning to embrace a truly native approach, it means you will have to write the same app twice. Once using Swift, and once using Kotlin. Of course, algorithm implementations can be more or less the same across languages, and therefore you do not spend literally twice the time on development. You may experiment with using data that your apps receive from a server as a way to determine what’s on the screen.

A few years ago, Airbnb described how they have experimented with server-driven apps as part of a series on “[s]unsetting” React Native, and moving to the native development. Server-driven apps are apps that render screens based on the data that phones receive from the backend. As a result, your code on all platforms looks, and feels more or less, the same while cutting down a lot of time on development. That is about as far as good news goes. Platform-specific bugs still will occur, creating different problems on each OS, and the need to hire platform-specific developers still will drive the costs up.

Conclusion

Native apps will be the fastest. They will also feel the most familiar to your users. It does not come without certain trade-offs. The development time will certainly be longer. They are also much more expensive to develop, as you need more people, and resources to write the same app twice.

Native apps, Progressive Web Apps, or Hybrid Apps — we are here to help you develop your app.

Creating Cross-Platform Mobile Apps. Part 1: PWAs

ITMAGINATION — Thu, 21 Oct 2021 00:00:00 +0000

With Mobile Phones increasingly speeding up over the years, we have long ago reached the point when they can run regular versions of websites without a hiccup. There is, however, a clear advantage of having your clients install your apps on their phones. For one, they are always one tap away.

There are so many solutions to the problem of developing mobile apps, that we decided to go ahead and walk you through all of them one by one. The problem we will be solving is — your business wants to develop a cross-platform mobile app. What should you do?

Progressive Web Apps (PWAs)

We know, we know. They are technically not mobile apps. We will count them as such, however, because an increasing number of native APIs are available for web apps, they are installable, and run offline. We are not the only ones to think that, too. Little do people know that PWAs is what Steve Jobs envisioned for iPhone apps during his presentation in 2007. Fourteen years ago, Apple’s CEO foresaw the future.

Of course, we know how everything turned out — Apple did release an iOS SDK to develop “native” apps, with the App Store launching in 2008. The decision to initially double down on web technologies for apps was deemed a “blunder” by Forbes. Steve Jobs’ could have been seen as controversial, sure. At the time, phones were not powerful enough to do what developers envisioned using JavaScript, while the language was also not in the best shape back then.

Fourteen years is a lot of time, however, and we do definitely see that — with phones often “rocking” eight cores, six gigabytes of RAM, and capable of running demanding software. Today they are now more than ready. Apple’s legendary CEO was simply ahead of his time — it’s a shame he did not live to see his vision become reality. A little glimmer of hope was Firefox OS — a niche and discontinued operating system that had apps written in JavaScript, only.

What are the benefits of PWAs, then?

Code Reusability To The Fullest

There is often a key question — does one develop a web app or a mobile app first. The answer that PWAs provide is… why not both?

Creating apps that often share 100% of code is frequently a reality. There is simply no reason to adjust your code. You can prompt users to install your app in the same way on all platforms that Chrome runs on — Linux, Windows, macOS, Android, iOS… With one codebase.

No App Downloads

The heading might feel misleading. How can it be that there are no app downloads, if clearly, one has to download the code for the website? That is true. Your users still have to download your website. There are a few key differences in this case, however.

You are reducing the number of steps one has to take to install the app
The size of the app is much, much smaller
The app is easier to discover, and your users are not seeing your competition’s ads in Play Store, or App Store

Quicker Time to Market

Before your product hits the market, there are very few metrics than the expected Time-to-Market. A true blessing is the ability to cut down on it, while not compromising on the quality of your solution too much. Especially, that all your team members can focus on one goal - completing the web app.

Platform Independence

Apple to a large degree (Google to a lesser one) has a monopoly on the market of software distribution on iOS devices via App Store, and Google Play Store. There are no real solutions to sideload apps on iPhones, in an effort to make the phones have airtight security for all. Installing apps on Androids from outside the official store is much easier, though the majority of users still choose the official way of getting apps.

Companies big and small (Epic, Spotify, Basecamp, Protonmail, Deezer, OpenDataBot, and others) realized, and more than a year ago formed a “Coalition for App Fairness”. Its goal is to “advocate for freedom of choice and fair competition across the app ecosystem.”

There is a way to distribute your app, that you control, from which you can collect all the profits, and which makes your app easily discoverable. What is it? Your website. PWAs do not face as many hurdles as native apps do, which is a big win.

Easy updates

By having to run in a web browser, your apps can be updated each time your users connect to the internet whilst using them. This provides for an effortless and quick update process. You control the update policy through the cache (caching = saving your app in a temporary location for faster access) configuration. You can choose to serve your app:

Cache-only (not the best way)
Network-only (not the best way)
Cache falling back to the network (offline-first apps)
Network falling back to the cache (apps that update frequently; the process can take a bit longer in case of a patchy internet connection)
Cache then network (apps that update frequently; better user experience) You may see the details, and example implementations of said approaches here.

Surely, the solution has to have some downsides, right? Yes, there are.

The Cons Of Using PWAs

Slower Than Native Apps

The major reason why Steve Jobs and Apple backed away from embracing web technologies to the fullest was the lacking power. The speed was not enough. Developers had to switch to Objective-C instead.

For Android, the language of choice was Java. The approach allowed for the creation of much faster apps, and, perhaps more importantly, opened up a steady stream of money to Google, and Apple.

Even though the phones nowadays are on-par with performance with some desktop computers, native apps, or hybrid apps, are the more popular solution. One reason is the speed of execution, still. A website running on top of a browser will be slower even on the fastest of computers, anyway.

With the interfaces running smoothly at 60fps, one has to wonder whether that still is a valid reason to forgo PWAs.

Some Native APIs Still Not Built-In

Even though Chrome can: access the contact book, access the native file system, implement NFC solutions (NFC is how, e.g., contactless cards work), and, handle Bluetooth connections;

there are still numerous things it cannot do. Thanks to Project Fugu, the list of things that web developers cannot do is getting smaller, and smaller, luckily.

Nevertheless, sometimes, developers have to pick up native SDKs to be able to solve their problems.

People Are Not Used To Installing Apps In-Browser

One “Law of User Experience” says that:

Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.
In practice, this applies to the way you want users to install your app as well. If the majority of your competitors, or even companies that operate in an entirely different sector, have their apps working differently than yours, your users can be a bit confused.

This is the biggest obstacle that companies have to face before fully embracing the web-first approach. There is no obvious solution to the problem, either.

When should I decide on PWAs?

Startups have to be the biggest beneficiaries of Google’s attempt to make all significant native APIs usable through Chrome. Should you have a relatively small software development team, you will be the happiest. The same applies when your app will be rapidly updated; there is simply no way to update the apps faster than by creating a PWA.