Offline functional applications require a different way of data management than traditional web design.  The client must own a local portion of the data and have it ready at hand to serve the users need.

In the traditional model, there are a variety of strategies used in modern design that helps to alleviate some of the pain of poor or intermittent connectivity.  These are often used to simply to improve the feel of the user interface, prefetching, caching data, and optimistic rendering.  All of these are only modest changes to the traditional server to client model.

Some buffering systems are placed on the inputs and outputs of the client to ease the network requirement.  But if we wish to produce an application that will function as a mobile app or PWA as a primary consideration where it is likely that there will be times with zero network connectivity this method does not work well.  We might be able to turn our outbound buffer more permanent and that would help with some use cases.  But often we still require that server data to do basic functionality within the app.

The minimum offline storage solution is to create a better store on the client to handle full offline use looks like this.

The picture looks relatively simple but there are some tricky parts.  Not only are we adding a significant amount of complexity to the client with the additional data management.  There needs to be a method or system to managed changes and updates between the two, or more, stores.  There is a good possibility that there are conflicts arising between the different stores.  Enter conflict-free replicated data types (CRDT).  With such a system of change management in place, it allows us to manage all the stores both on multiple clients and a server.   The stores will always have the ability to synchronize the data between them without unsolvable conflicts.

How does this work?  Basically we are using change requests as a means of altering the other stores rather than copy or caching the stores themselves.  When the client connects to the server, it doesn't download the whole store or some checksum of it.  Instead, we ask for all the changes that have occurred to the store since our last update and then the client can also apply those same changes to it's store and then the client will have the same store as the server or vice versa.  Changes can also be rewound and repatched if there is a necessary backdated change submitted by a client that hasn't connected in a while.

This is technology widely understood and used in the database world which makes it a perfect fit for this use case, tried and tested and now we can adapt it for user gratifying results in the offline use case.

This may seem like such a system that doesn't scale well into a large backend.  It would be generally unacceptable for a client to need to download a 100MB database in order to operate.  There has to be some kind of scale that the client operates at.  This view of the data could be scoped to their personal data, like in the case of Apple's Notes app that uses CRDTs to synchronize between devices.  Each user only has the data and changes relevant to their view and syncing only involved that data.  In the case of other useful data that may not belong to the user, another possible discernible view into the data can be used.  Recent threads the user has visited on a forum or social media system.  Topics of interest to the user on a news feed.

There are a myriad of potential pitfalls when selecting languages, frameworks, tools, and architectures for new projects.  I've seen so many mistakes that eat at schedule, cost, and customer expectations.  Many of the mistakes are relatively simple to fix if done early and with the right knowledge base.  These are decisions that a competent software architect is suppose to provide for your organization, group, or silo.  Only, I've seldom found a great software architect making those decisions at the various places where I have worked.  The pitfalls for picking poorly is software that is usually over budget, performs poorly, ages too quickly, difficult to maintain, never makes it to market, or multiples of these items.

What usually happens?  There seems to be a poor understanding of the position, and how it should function.  Additionally, it is mostly filled by the under qualified.  I've seen statistics that only 29% of candidates hired for architect roles fully meet the employer's requirements.  A specialist often fills the role, and then he is either incognito and almost never seen by the regular developers or he is fulfilling the role of a senior developer or team lead while also wearing the hat of the architect.  While all that is interesting, I'd like to give you my take of what a good software architect is and does instead of just ranting about the mistakes and problems in the industry.

A good software architect is a generalist, not a specialist.  He hasn't spent 20 years just coding desktop Java software, or just web stacks.  He has >15 years of total experience, but he's moved his career around a few times.  This will help shape his thinking, he won't have a narrow focus on just your industry but will have experienced wider and broader number of domains.  This will somewhat inoculate him from the development fads of the day and help him to make better decisions.  He will have at least 3 years of experience in your particular industry where you want him to architect.  This provides to him local domain knowledge and patterns of the industry with a recent historical context of where it is and where it's going.  The specialist, when hired as an architect, will have particularly good vision within his scope of understanding.  But he won't know what he doesn't know, and will tend to have false confidences about elements outside of his experience.  He will tend to leverage his own personal tools that he likes and knows well and see all problems within that context, even if that means taking a hammer to a screw.  If he realizes his limitation he will essentially outsource those aspects of his job, or if determined to do the position correctly, he will undertake the effort required to become the generalist he needs to be.  The generalist has a clearer understanding of his own limitations, he has been around specialists and he appreciates their depth of knowledge.  He has a good understanding of how various bits of a system fit together and has seen a number of technologies, stacks, languages, patterns and pitfalls that lay within them.

His role within the organization is to be that consummate generalist for the entirety of the domain in which he presides.  He will explore the latest development patterns, frameworks, and tools.  But he won't just do this himself, he will additionally task such evaluations out to the various senior engineers within the organization.  He will frequently speak with them about the warts and limitations of the current systems.  This is done individually where, hopefully, egos and politics are lower so he can get at those reservations that lurk under the surface and are seldom given voice in meetings.  He will come to know all their concerns, preferences, and ideas of where the current systems presently are and where they would like them to go.  He should also do some level of maintenance work, in some kind of organized rotation around the various products within his domain, which gives him personal experience with the current production code and a personal context for the discussions with the senior developers.  

He has access to budgets and costs for the projects so he is at least versed in the various systems' creation and maintenance costs.  He does not need to be an estimator, but that is a good skill for him to have.  He also has access to a summary of the customer feedback and satisfaction levels that he may know their view of the software systems.

Finally, where the rubber meets the road, he is the primary interface with management when it comes to sketching out new potential products.  He offers solutions that the company can fulfill, both technically and financially.  He pushes back to management on troublesome points on projects, there are often a few requirements on a new project that will absolutely drive schedule and cost to fulfill.  Maybe they are key and essential, but sometimes they are someone's half baked idea that can be jettisoned to bring schedule and costs down (something like this xkcd). Sometimes design ideas floating around in the management team are out dated or reflect inexperience, he must provide education in these places.  Basically, he protects the company from embarking on software disasters by fixing planning, expectations, at project launch.  He lowers their overall costs while improving end satisfaction, especially in the long term.

Every good project starts with a suite of tools.  Good tools make for quick, quality, and enjoyable work.  I really like vue.js combined with Quasar and see it's use as an important competitive advantage I have over those who have not yet found it.  Just as important as which front end rendering engine is chosen for browser rendering, less discussed but of high importance is a framework, like Quasar, that advances your starting position on a new project.  The fewer components that you need to custom build yourself the more quickly your application can be assembled while also reducing the complexity, maintenance requirements, and testing requirements.

Vue adoption has been growing in recent years and, I believe, for good reason.  I have used Angular, React, and Vue.  My favorite two are React and Vue by a long shot.  I would choose Vue over React for most any project today.  Vue is both easier to start, and when you return to a project or code you are unfamiliar with it is more readable.  There are aspects to JSX that aren't as intuitive, the over use of ternaries and logical operators to filter which parts of a component are being rendered, also the inability to use standard JavaScript comments within a JSX block don't lend to it's readability.  I also find the popular state management solutions to be easier on the Vue side.  I like vuex over redux.

Both React and Vue have good sets of frameworks to pick from that do a lot of the common tasks and heavy lifting for you when generating a new website or application.  I have found Quasar to be a stand out here.  It hits a lot of platforms out of the box for you, more than any other framework I've found.  Which means a minimal learning curve if you need to target a mobile device, a website, a PWA, or even a desktop.  Server side rendering for SEO.  All these are there, and I have found it easy to take it further and add wordpress plugin to some of my build projects.  It also provides you a high quality suite of components that give you a great starting point so you can concentrate on the unique parts of your application design rather than writing your own framework level code.  Most devs I know really like writing framework level code, but it's terrible for project velocity when you can use someone else's well maintained framework.

Just as important as how well maintained and usable a framework you use as your base system, is the documentation of that framework.  Vue and Quasar both have excellent documentation on boarding for new people is easy and straight forward.  And picking up and using all the features of the stack is clear and understandable.

Feathers is a really excellent back end platform.  It checks a lot of boxes for me and I would like to explain some of it's virtues.  I prefer to invest my limited learning cycles into technologies that show clear longevity and ease that also provide me with measurable competitive edges.

It's been around a long time, about 5 years, and while it is not extensively popular it has accumulated a solid support basis from the community including devs and funding.  It is a quite stable and actively supported and developed system that isn't likely to disappear or change radically on me (or you) in the next few years.  In an environment where community projects come in a matter of years to sometimes only months, this is important.  

At it's core, feathers is actually an abstraction for the traditional web transportation layers.  Which means that a feathers back end can communicate with a feathers front end with a number of intermediary transport layers.  Socket.io, REST, and GraphQL are supported.  I could use one of the transport layers directly, or write my data queries in feathers itself and get additional advantages.  If or when a new transport layer appears on the market, like say the slowly growing HTTP2 adoption or a superior implementation of a bi-direction communication package like socket.io appears - I won't need to change any of my business code to take advantage of it.  A feathers update and turning on the feature and I'll have the advantages available from it.

The main feature I was looking for when I found the system is reactive data for clients like meteor and firebase provide.  A real-time API.  This is where back end updates are pushed to the client as they occur.  Which is an excellent feature that I have always been a fan of, especially when using a system that largely does that work for you.  Because it's not easy to do if your underlying technology choices do not support it and you have to build it yourself.  Traditional REST and GraphQL implementations that I have used and helped to build generally do not.

Feathers is not opinionated as to which type of database you use.   It has a solid stock of default database adapters including in memory, localstorage, file system, mongodb, SQL, and elasticsearch.  It's flexibility has been a boon to the number of projects which I have found it suitable for, and I find myself using a variety of the adapters depending on which one is most advantageous.  I've had some small projects that I've built for embedded systems where having a database dependency is extremely painful.   I can instead just use the best combination of in memory and file system and have a clean implementation that retains the necessary data while minimizing flash wear with a minimum of complexity, memory consumption, and no external dependencies.  

Feathers comes with an authentication system.  Which you can use instead of writing your own, and it's generally not a good idea to write your own.  Or you can plug into one of several existing auth systems.  

Feathers provides a CRUD and query operation suite that's useful for getting running quickly similar to a system like loopback that helps you get an API off the ground.  The hooks into that system allow you to build out permissions or perform necessary modifications to the data while it is in flight to or from the database.

Feathers is a simple system that provides this core feature set and then gets out of your way.  This simplicity makes it reasonably easy to pick up and learn as well and is good at not getting in your way.  I highly recommend it as a tech to pick up and learn in a small project to put another tool in your tool bag.

You stare at the computer screen.  Knowing that you need to get that next card completed in the current sprint, but somehow you are struggling to muster the energy to do it.  That card just sucks.  The discipline to overcome your internal impediment is not there, and you find yourself wandering over to open and read The Onion instead.  Just one more story you tell yourself...

There are many ways in which we experience stress.  I will make a few metaphors here to create a visualization of my concept here.  The first of which is a spring.  Consider a slow motion spring.  A stressful event will begin to compress the spring.  When the spring is compressed, it does not have more give to give.  In the usual run of things and our every day stresses, it doesn't compress very far, no where near our actual limits and will generally naturally decompress.  There are times where we struggle.  The spring isn't bouncing back like we expect it to normally.  When the spring is flat we find it difficult to operate normally.  I would also say that we have multiple independent springs, mental, emotional, and physical (there may be even more, hormonal/endocrine, etc).  If any of them are flat, our general performance will dive and if some are exceptionally strong it can help out some of the others a small bit.  The physical spring is generally one of the most understood.  You have a workout or get injured (compress), then you rest with low activity and sleep as well as provide your body with good nutrition and in time you recover (decompress).

Consider a more extreme example of some of the other springs.  In this hypothetical example I went out to lunch with some co workers and we had a good time.  On my way back, as a pedestrian I almost get hit by a truck going 40 mph.  I come within a hairs breath of just being dead or the next thing to it after lunch.  I have several seemingly slow motion moments of seeing the truck and then some combination of my moves and the drivers results in me just being missed.  I get back to the office.  I'm mentally and emotionally tied up in knots trying to process the event.  A couple of my springs are pretty flat at this moment, primarily emotional though you may also have a hormonal decompress coming.  Am I going to just be able to shake it off and work?  Unlikely.  I believe that these springs do work like muscles, the more and deeper that you use them the stronger they get.  At least when they are springing back to a healthy normal with a generous amount of give, you get stronger.

In this extreme example we are in a very flat or compressed state.  How do we cope with it?  One of the primary methods in our culture is numbing.  This is illustrated in the opening example.  We don't like the flat state so we hide from it by doing something nominally enjoyable but with the real purpose of covering up or distracting us from contemplating our flat and stressed state.  This can be a chemical numbing via drugs.  A pleasurable numbing via food, stress eating.  Or a multitude of other activities, movies or TV shows, games, chats or social media, and reading interesting novels or websites, etc etc.  

The material point is that this numbing does not really help us actually decompress the spring.  They aren't productive activities, and moving us forward, but with them we are trying to avoid something unpleasant (which need not be as extreme as the above example).  With them we are not processing the event to move beyond it, we don't make any progression forward in our works either.  This realization that we are not being productive but consuming time with a fruitless pursuit becomes another stress point to put on top of the original source we are trying to avoid.  Then the compulsion to remain within the numbing activity just ratchets up and we enter a compulsive cycle that gets harder to exit rather than easier over time.  This is what many addicts experience.

Continued productivity depends on avoiding even the minor contributors to the numbing cycle.  To do that requires that you identify your personal numbing behaviors and don't even start them, to know them for what they are. I believe that the surest keys are that you sort of enjoy it but also find the behavior compulsive.  The primary purpose can be seen as masking something else rather than the savor it provides.  You want to do it again, again, and it takes some will power to stop. These are items that you should blacklist in your life. Avoiding them entirely will enable you to make room for both the works, and the truly enjoyable activities and relationships that will much more readily decompress your springs.

I'm sorry Mr Smith.  We can see that you are a reliable employee, having worked at Acme Inc for 15 years.  But what we need are people who have experience with Doodadz written in Unicornium.  This Python you have worked with has been completely phased out of our software stack 5 years ago.

Over my career in development, I've learned a few habits through experience that I believe help develop a career.  Most of them are simple things, but they take some discipline to do frequently.  Keep your eye and ears on the market movements for your chosen field.  Develop your skills and expand upon them with new skills, tools and frameworks regularly.  Use those sharpening opportunities to build a personal portfolio.  And finally, keep a constant look out for new and better opportunities.

To keep your eyes and ears on the market movements is pretty easy if you like news.  For this exercise, stick to industry relevant news.  With the internet, there are a ton of good sources and a simple search brings up a multitude of potential avenues.  I believe that one of the tricks to this is to find a few good sources and then limit your time on them.  Information overload is a real potential issue, and it is generally an addictive activity.  I advocate being current on the trends but also limiting your time spent to about 1-2 hours a week.  For software developers, I like to visit places like http://pypl.github.io/PYPL.html every couple of months to get a pulse of where the overall industry is going, and any similar break downs for your particular industry (say, web development, mobile development, freelancing, department of defense, embedded, etc) as well as in your region (geography does impact some of the trends) for which languages and stacks are most popular.  This populates your inputs for the rest of the topics in this article.  You don't always have to stick to the up and coming or the most popular language.  But it is very handy to be aware when something is falling out of favor.

Armed with current industry knowledge, you should then pick a skill, language, tool, or framework to learn - or learn in greater depth.  30 minutes a day 4-6 days a week.  Some employers are interested enough in your personal development to allow such learning to happen on the job.  Even if they don't though, this is an important step to developing yourself.  I prefer to use regular time every day over larger binges at longer intervals.  This keeps the projects and learning moving forward and I believe that the concepts sink in better.  For me, I am less likely to forget and slack off in this supplemental learning with the regularity.  With this time, you can learn new features in your IDE.  Try out a new IDE.  Try a new language.  Try a new framework. View instructional videos about all of the above.  When trying a new language or framework, I would do so with an eye towards completing a distinct project that's useful to you.

Completing projects is important, especially early in your career.  There are always pain points and more enjoyable points.  Getting to The End will help you develop the discipline to push through the pain points as well give you a well rounded experience with that item, from creation to deployment.  Going through the entire exercise also helps you accurately identify where those pain points are, how that technology might be used effectively and where it might not be a good fit.  And the final payoff is to have something to show off in your portfolio.  Which brings us to...

Make a portfolio.  Such self promotion is alien to a lot of engineers I know.  However, having one makes the job interview a lot easier.  More importantly, it helps you look passionate and engaged by your work as well as present your skills as a developer that no white board development challenge is going to be able to match.  Just do it!

Last of all, always keep a casual eye open for new opportunities.  Even if you are happy in your current position.  Times change, both technical and business.  The industry moves on quite rapidly and in 10 years the landscape will look very different from what it looks like today.  Regularly evaluating companies for fitness as well as a good professional fit for you will help you.  You will learn things about your industry that may help you in your current position, both in making good technical decisions for the future and in knowing your market rate in preparation to re-negotiating your rate with HR.  This means keeping a resume up to date.  Keeping your LinkedIn profile up to date.  Checking the job boards at least once a quarter.  When something interesting does pop up, an application is quick and easy.  Interview skills won't completely decompose.  And when the next big wave of industry change occurs, you'll be able to ride it to success rather than end up washed up on a beach trying to figure out where you went wrong and then forced into an unpleasant career change.

Business photo created by yanalya - www.freepik.com

I've been in professional development for about 17 years.  If you add in classroom and hobby development that number goes up to about 25.   That's a modest history in the industry, and not nearly as much as some people I've had the privilege of working with.  With my time, I've seen several fads come and go.  Developers or managers may consider the tool or process to be the greatest thing and implement it everywhere, even when it is counter productive.  These ideological strategies can be found in management formulas, languages, frameworks and include such concepts as object-oriented, functional programming, agile, scrum, story points, test driven development, lambdas, factories, micro-services, and pair programming.

Some of these are great ideas and represent some nuggets of wisdom accumulated over the years.  However, they also frequently have drawbacks.  Especially when used within a rigid dogmatic environment that does little self review or internal introspection when seeking for improvements.  You are also blind to the drawbacks when your available experience pool, including devs and management, does not understand when these tools are good and when they are not.  The result is often handing out hammers when we are trying to put in screws.  To make it even harder, even with excellent teams with broad and deep experience, the project can still be sufficiently new and unknown that mistakes are still made in selecting the baseline process and tools to move forward.

There are some general principles I try to use that help guide teams to customize their process as well as allow for fluid technology choices that provide higher development velocities and result in better systems.

Frequent Common Sense Reviews

This is the first cultural item to have present.  Review the usefulness of the processes followed.  Review the systems being build, the languages and frameworks being used.  Don't be afraid of a pivot if the cost/benefit ratio justifies it.  I do suggest that this be both formal, informal, and anonymous.  

Many details and struggles just don't come out in formal inquiry, especially from management.  There is an unstated expectation that performance be good, and devs like to look good.  There is also a vested interested in decisions already made.  Though some lines of questions do help this.  "If you could start this project over again with what you know now, what would you do differently?"

In informal settings.  "I really love that build system Frank put together, it's so slick.  What's your favorite bit of code?" and it's brother "I really dislike the release process of this framework, I find every update is a royal pain.  What part of the system do you least like to touch?"

These conversations should happen, and they should form the basis for some of the reviews of the potential problem areas.

Do the Hard Part First

I've been part of a lot of waterfall (successful and not) and agile (successful and not) designs, big projects and small projects.  I believe that this bit of wisdom is not widely shared or represented in the popular development methodologies today.  I've seen projects stall out with schedules that extend meeting after meeting with a customer upset, managers frustrated, devs shrugging with consistent reports along the lines of "we're trying, we're not sure..." as they struggle with the unknown.  Where as previously, the project was generally on track.

It can be tempting to dive into the funnest parts.  Or for those with more discipline what you consider the foundation of the system.  You may schedule it all out, and find it tempting to put that high risk stuff at the end.  I've done that myself!  And then I paid for it.  Experience can be a harsh teacher.

I have found it is worthwhile to dive into what will be the hardest or least understood part of the project first.  Leave all the well understood parts scaffolded or stubbed out and build that unknown piece first.  Eliminate your risk as your first development priority.  This is a pre-MVP trial run or proof of concept.  You may have to do it with a few disparate unconnected pieces.

Of course we make the best choices we can, and these choices are going to be the most costly to modify in the long run.  I believe that the more or larger the unknowns that are present in the system the more important it is to validate these choices while it is still within reach to change them.  If your choices will show themselves to be less than optimal - this is how you get to that revelation faster than if you start somewhere easy or fundamental.  "This isn't the best language choice for this problem..."  "This framework does NOT help us here, it's getting in the way..."  "This architecture is PAINFUL...".  After these choices are pounded into the wood by building the easy stuff, it's a lot harder to extract that bent screw.

Experience is important in this process.  The set of unknowns will be smaller when you have good senior level talent to guide you.  Especially with experience in building that system or a similar one.  With less space to explore you can finish the trial, then validate and pivot if necessary with less time and cost.

No Sacred Cows

The pros and cons must be weighed as objectively as possible.  Write it down, and be honest with yourself, acknowledge your preferences.  "I LOVE this pattern", "I hate non-OO languages", etc.  Pull extensively from your experience pool in this as well as the best industry voices you can find when reviewing the lists of tools.

Don't be afraid of some trial time and small projects to expand local experience and vet tools.  I believe that healthy tech organizations will be doing this reasonably regularly with many techs to create a broad base understanding of the tools in the industry and which ones would be most beneficial in certain circumstances.

Making programs fast has always been an interest of mine.  Most of us have seen that system that a small breeze can knock over and render flat.  Where the request time graph looks like an altitude map of mount Kilimanjaro when any real load is applied.  Up, up, and away!  But system speed isn't the only kind of speed in development, and often times isn't even the most important.  There are other measures of speed, like development time.  How much time it takes a user to learn your system.

Back in college I was given the opportunity to build and tune a ray tracer as an exercise in algorithms.  Ray tracing has been around since 1968, and has been explored quite extensively and it was thought that we had pretty much explored all the acceleration options possible in the 30+ years between the concept's origin and when I took that class.  Our professor challenged us to improve things, but also still held the position that we had pretty much explored everything.  Only, I found something new in that class.  It was a variant of what already existed, but it still had fundamental advantages and differences from the existing strategies.  My structure was faster to build, faster to render (depending on the scene it was 5%-50% faster), and used perhaps 5% more memory on average with more variability on the total memory used.  I had other metrics I deemed more important than the classic measurements at the time, such as the sum of the total volume of the bounding hierarchy at a given depth.  I had a good time tuning this system and thinking through the various approaches and their limitations.  I was eventually cited in a ray tracing book written by a fellow student, cited in an academic paper, and even was invited to update the school's RTRT (Real Time Ray Tracer built for a massive parallel system) all as a shiny new undergrad.

This experience, however fun, has not proven similar to any industry system I've helped to build.  In my experience with developing products in modern languages I've found that about 95% of your code just doesn't matter how efficiently it runs.  Correctness, good design, maintainability, and development velocity are generally more important.  The remaining 5% can spend significant amounts of time being run, and is usually at fault if your system is slow, this is where it apparently attempts to climb mount Kilimanjaro before getting around to your request.

I shall call this 5% the critical path.  Some projects don't even have one, this is common in front end and desktop software I've built, but every API or server I've worked with does.  This critical path of code should get some extra attention and avoid certain types of operations that tend to be slow.  The main sneaky culprit in modern systems I've found from my experience is allocating memory and this article will focus on that.  In my ray tracing algorithm, I deviated only slightly from this theme where I thought it was prudent and I was right.  But rarely does your O(n) really matter for most software and that has held true for 95% of the software I've written since school.  All the common operations are already solved for you, baked into language features or libraries, and you should not generally spend time re-writing them.  Even when building and considering extensively your O(n), memory is king, and if you ignored it whatever your other advantages you might have found will be swallowed up in the sting of bad memory management.  

Many junior, and even not so junior devs don't have a particularly good understanding of the memory system operating underneath them to support their convenient high level language features.  Every developer ought become sensitive to how the innards of the system he is building with operates.

Some new development fads, like functional programming, insist on the immutability of data when passed into functions.  Which means if you are performing operations on a list, you end up with multiple copies of that list as you perform operations on it.  Weather you need those copies or not.  listData.map().filter().map() will end up with ~4 copies of the data, depending on how much filter() removes.  Not a big deal if it's not on the critical path to use memory in this manner.  But if it is, that data adds up quickly.

Some caching strategies clone the data that is extracted from the cache for use. Every single JavaScript cache library I've looked at on npm does this. This is intentional to avoid allowing altering the copy to alter the original, a behavior which the language generally allows you to do.  But this also makes an operation you believe will help speed the system up, by potentially avoiding additional requests to APIs, and turns it into one that will also slow the system down significantly under load.

Why is allocating memory so bad for performance? CPU cache thrashing isn't normally on the radar in network based systems, but a similar concept is. That allocated memory must eventually be freed, which means your virtual machine needs to find it and release it back to the managed heap. It takes time to find which segments of memory are no longer needed, those are cycles built into the language for every bit of memory you need to use. To make things worse, it's not even linear. As you allocate more memory more quickly the search space becomes larger and thus, takes longer. On top of this the garbage collector needs to run more frequently to keep up.

With all of these compounding factors eating at your cycles, if you are careless with management you can enter a state where upon reaching a certain load the application performance craters and the majority of your application time is spent in the garbage collector and it may not even show up in your performance statistics why the system is so slow. I've seen such thrashing in various systems. In one case the developer I worked with doubled down on the caching being employed, which happened to be of the cloning variety in a JavaScript system, which ultimately did very little to solve his fundamental performance issues.

I've also seen systems that try to paper over the issue by throwing more resources at the problem bits from the cloud. Micro-services are another path people take to that end.  Performance issues can be solved by paying more!  That certainly is a valid route that works, and it's a trade off between that and paying for the engineering time to make a better system.  I believe with an accurate view of some of the primary culprits that makes systems slow the costs can be clearly in favor of making a better system.

I have answered this question for various clients.  I have experience building applications in multiple stacks and so I can compare and contrast a few of them in their current states.

I have a lot of requests for React Native development.  It is in high demand and is quite popular in the current market.  It is work I willingly do for clients that have already chosen this road.  However, when asked for my opinion on their technical direction I recommend against using it.

If you are looking for an efficient method of using one code base to hit multiple platforms.  A goal I find to make a lot of business sense.  I recommend a straight HTML5 approach to mobile apps.  I advise this route for about 80% of my clients as it serves their needs best.  It checks a lot of important boxes that meet their business cases and does so for less impact to their bottom line.  It's not a 'hip' solution, there are few, if any, major or popular companies promoting HTML5 standard for mobile.  And ever since Facebook famously abandoned it in favor of native development back in 2012 it seems to have slowly declined among the 'hip' developer's mind share.  All while it has quietly improved, phones have gotten a lot faster, and it has consistently had solid support for a long time.

Why not a hybrid platform like React Native?

The biggest glaring issues are the platform maturity and developer experience.  React Native has some beginnings of excellent tooling and clearly there has been a significant amount of effort behind it.  It is, however, not "there" where platform bugs are far and few between and relatively minor with respect to the impact they exert on your application and the required upkeep hours.  I've used professional grade development environments for over 2 decades.  I know what good tooling feels like.  React Native scores poorly.  In contrast, HTML5 has excellent and mature tooling for development.  Browsers have relatively good compatibility (especially compared to years past), and the inspection and plugins suites are excellent.

With all major frameworks, long term outlook and maintenance of the framework must be factored in it's use in major company infrastructure.  Facebook is the prime mover behind React Native.  Right now Facebook is embroiled in political controversies, struggling to recruit, and is having public leadership turmoil.  I don't think Facebook is going to disappear, but the volatility is a concern.  This is not an environment I really want to trust for important long term investments.  It's true that React Native is an open sourced project, so it may well survive Facebook's turmoil or even abandonment.  This environment still does not inspire confidence in me and I believe that it's chances are rather poor if Facebook ceases support for it.

Next we have the available labor pool.  It is much easier to find HTML5 devs than React Native devs.  Long term staffing is clearly much easier on the HTML5 side of the fence and will be for the foreseeable future.

Metrics on React Native vs HTML5 fall in favor of HTML5.  My experience with production applications are as follows on my hardware (Samsung S5 Active running the latest Android OS, it's older but serviceable).

Application cold start for two applications of similar complexity, React Native: 3 to 5s (varies), HTML5: 3s.  I have a simple HTML5 app with no network requirements that loads up in 1.5s.  Slight edge to HTML5 here, but pretty similar overall.

Application feel overall with similar complexity is so close that I can't really tell the difference.  It's dominated by backend latency, request time, technical design and architecture decisions, not local render speed.

Bundle size for apps of similar complexity, React Native 27MB.  HTML5 2.4MB.  Really big difference here, and the biggest that will be visible to the end user.  The minimum sizes of both approaches are about an order of magnitude different.  When every byte counts on a mobile network, especially for updates, this really matters.

I won't lie to you and say that being a contractor has been all roses for me.  It hasn't!  My reasons for making the move are both simple and complex.  The main driving factor behind this leap is that my family's health requires flexibility that is difficult to find in the market of full time employment.  This has been a slow learning process over my last 3 or so full time positions.  And with this understanding we have struck out on this trajectory of independence.

The road has been slow to start.  I worked my known contacts for available work.  I reached out to the recruiters who were open to this kind of referral.  I even registered to Upwork and a couple of other similar freelancer sites.  At first I got no bites or work.  I did lots of bids and proposals for various people and agencies.  I also prepped my business site, portfolio, as well as a bit of spit and polish in my online profiles.  Then I went exploring the avenues that I could think of.

My first breakthrough happened on Upwork.  I landed a pair of contracts for work on some data mining that turned into a fairly major contract for updating some old website software for longhorn pedigrees ( https://play.google.com/store/apps/details?id=com.sharpsoftware.longhorn ).  I loved working with the client, and he reciprocated ("Brandon you are basically the strongest asset anyone could have", "Man this is amazing. I'm over the moon with your work!"), which made for one of the most fulfilling projects of my career.

Since then I have had some minor contracts but the more interesting avenues are that I have found a couple of needs where I can build my own products rather than just doing work for others.  And these avenues are quite appealing to my soul.

My lessons learned so far.  This is a train that takes quite some time to really get moving, and not a casual move I can turn on and off like a job.  It is highly rewarding personally to perform the work, much much more so than the full time employment work I have ever done.  I enjoy interacting directly with my customers. I do look forward to the challenges and rewards that will result in my upcoming efforts.