In this article you will learn few secrets not spoken by tutorials creating developers. These are things that many tutorial creating developers aren’t saying, because they don’t know them or realize them. Many colleagues are often too attached to the tool they are using. It has become their fetish. Other times these things are purposefully ignored. They also may pass around the minds of software engineers, because they make money from the technical detail and knowledge. Especially when people have children and family – the ignorance is forcefully placed above, because of the needs of means of life.
Who is responsible for Authentication and Authentication
Identifying a user against some database or any third party platform is in majority – mostly – a back-end problem. The front-end could provide:
- username/email and password
- permission and approval of access to third party system
- permission and approval to client-side protected and secure software or hardware. The Operating System may offer access to software keys after user authorization. There are several options for authenticating user with hardware – biometrically – fingerprint, face recognition, eyes recognition, or with smart card/sim card/read-only flash drive/ electronic signature holders.
After that – it is a task for the server software to recognize, find, authorize access to resources. The front-end may decide what to show and what to hide, but the leading role has the back-end system.
What I’m having a problem with is – the need for including all the stuff on the client side – all the time. I am not saying have different code for every single separate page, logic or feature – as it was 20-25 years ago. I have internal philosophical problem with bundling it all into one. And the problem is not only mine. Look at the many code splitting implementations. Why you would bundle yet another dependency into the already fat front-end?!
Fat Client
Flutter compiles very very fat code for every platform including JavaScript or Web Assembly for Web, because it draws everything. Here is an example how to authenticate a Flutter Web Front-End – without including any additional dependency – beyond the redirect for authentication and the check for authorization state that will be neither way needed. I’ve coded very simple Flutter Web App available here: https://programtom.com/dev_examples/independent_login/. I’ll probably write more about it in another article with more technical details.
Becoming Dependent
It seems to me that – I am the only developer that talks about this corporate sh*t. When you use Google Firebase, Authentication, Fire Store, Push Notification, Storage and hosting – you are bowing to the power of the Big Corporation. Yes, they are also the ones owning Flutter Itself, so it seems obvious to also be dependent on everything else to them.
Well, Amazon also published their version of the developer stack – and you could get attached to the other Big Brother. Bezos’ Amplify is very similar framework and it has almost the same features and services.
There are also other third parties for every single thing you need – authentication, storage, push notifications and more. But you will probably not heard about them too often and you will not try them without corporate need, because it seems impractical. Well, that is why the dependencies are growing.
CSS vs JavaScript in Visualization
I know the comparison between the two technologies is somehow meaningless. One is only for making the user interface beautiful with little to none possibilities of business logic. The other could have the all business logic and it also has the features set to visualize. So, this here is strictly my personal opinion.
CSS is Faster, smaller and better performing than JavaScript
Size
Most CSS Frameworks have top size of 100-200 kilobytes – after removing the white spaces and they are even uncompressed. This is the upper size. There are options with a lot less styling that are less than 10kb.
Have you seen the size of the JavaScript Frameworks lately? Have you seen the size of the Flutter Web Apps?! Megabytes and megabytes of code that is doing visualization! As far as I’ve seen the new Web Assembly format that is better in execution phase is not helping much in this direction. If you are targeting high end customers, it is not a problem, but, whenever you think of less super-powered users – you will be out of luck.
Performance
There are several points here.
- CSS is parsed and only applied when matching DOM criteria is found. JavaScript is parsed, interpreted and executed.
- Leading from the size – the bigger the amount of code – the slower it will get. It will require time for parsing and time for execution.
- APIs and optimization – There are CSS instructions that use hardware accelerations. While JS also has a lot of APIs that take advantage of the lower level stuff, it is still far away terms of results in speed.
The only convenience I see is – having one source base targeting every platform by using minimal amount of plugins and native features. It is good for start-ups with no or low money and an idea. It may increase productivity and delivery of business logic to all platforms – faster – while still being able to go to the lower levels with the plugins.