Are you an Android developer? iOS developer ? Or maybe you're into web ? Using React or Vue ? Or even Angular ?
Flutter, sure. React Native ? Come on over let's talk.
I have built/contributed to production apps using all above technologies. And here is a ๐งต ๐
Small disclaimer: While I have worked with multiple mobile and web frontend frameworks, I have spent 10+ years on Android, and have written 2 very popular VueJS libraries. So maybe some of this can be biased towards that.
The first rule of frontend development: Do not get married to your framework.
The second rule of frontend development: Do not get married to your framework.
Zoom out a little bit. Most of frontend development is same, regardless of framework.
To be put more simply - all of frontend development is about 3 things
- breaking down into reusable components
- state management (this is a bitch)
- routing
From a purist's perspective, routing is part of the state management problem, but still...
Third rule about frontend development - If you feel a framework is choking you. You are unable to "think" in a certain framework. Quit. Try another one.
For most problems, frameworks pick an opinion.
Mutability
Composability
Templatisation
There are no frameworks "better" than others *in general*, but there ARE frameworks "better" than other *for you*
Some people think in functional/composable way, they love
- React
- Flutter
- Jetpack Compose
- SwiftUI
Others in templates
- Vue
- Angular
- Android XML
- XIB
From a language perspective, some langauges like Javascript are very flexible, and allow both highly functional as well as super object-oriented approaches
Again, you'll find those who swear by React classes and Vue 2.0 style.
Others prefer React Hooks and Vue Composition API
Fourth rule of frontend development: Only think about components, state management and routing.
Views are dumb. But they need to be broken down into smaller reusable pieces.
Learn to look at a design prototype and immediately visualise a tree
(love this in the Vuejs docs)
State management is a hard one - because most learning around it focuses too much on implementation.
People learn Redux, MobX, VueX, RxJS/RxJava, LiveData, StateFlow, BloC and what not, before understanding the essentials of what state management is.
MVC vs MVVM vs MVP ๐คท๐ปโโ๏ธ๐คฆ๐ปโโ๏ธ
State management from first principles is not hard.
Model = data which actually triggers business logic
View = representation of the data the user sees.
In ideal world they should be same, but keeping them in sync is the fundamental job of frontend developers.
Understand what is two-way data flow and one-way data flow. Neither are bad or good. Situations demand one or the other.
Implement accordingly.
Do not become "immutable state" purists who start flame wars (some Flutter and React folks sadly are).
Take a financial app. You make a transaction. It would want the transaction to actually take place on the bank's servers, and sync the data to your app's local data, and then show the updated $ values on frontend.
Twitter on the other hand updates the like count immediately you hit the heart button and then eventually syncs the API call to its backend, and if somehow it fails, it will revert the heart back from โฅ to โก and -1 the like count.
Speed vs accuracy are product needs.
Learn to work with observable data structures - which you can tie to a view and keep auto updating.
Learn also to work with non-observable data, where you need to wire the "onchanged" functionality yourself.
At a primitive level nothing is "observable" by default.
Understand the cost of rendering a frame, and understand how big a *ripple* on the view does changing a data create ?
Will changing a variable trigger a render from the top of the view tree, or only the nearest required node ?
Optimising for this is the single biggest perf hack
Rule five of frontend development: One page at time.
Break down your user flows into pages. And then visualise the order in which they are traversed.
Mentally you should be able to create graph of it.
Many IDEs and tools can do it for you these days too
Embrace URLs. Do not try to circumnavigate them. From the onset of making your project, URLs (and URIs) should be the backbone of navigation.
URLs are... eponymously.. 'universal'. They can be shared across platforms, they get hyperlinked. They are very powerful.
Billion dollar companies exist like Branch[.]io because developers shit all over the place on understanding something as simple as the importance of URLs.
A single link that takes to a particular location, whether on website, mweb, ios/androi app or desktop app is invaluable.
Apart from popups and modals and alert dialogs, almost every other state that the app currently is in should be reproducible via URLs. (Mobile developers have a cooler name called "deeplinks". Potato potato).
The current URL *and* the backstack together are part of state too.
Rule number six of frontend development: No inspectors, no debuggers.
No I don't mean to say do not use them. Some great people at Google have spent eons polishing tooling, whether it is in Android Studio, Chrome DevTools or now Flutter Inspector. Lots of respect, but...
There will be 2 very usual cases that occur.
1. Unable to inspect UI. Some rendering - like via Skia on Android or Canvas on web cannot be inspected to smallest of details.
2. Unable to debug. The moment you attach debugger, concurrency and threads behave differently.
Single most valuable tool for a frontend developer is to learn to debug issues when inspecting and debugging cannot happen.
Fun fact - at a talk on how to create Vue plugins at VueConf 2 years back I used 2 hillarious examples
Watch from 11:45
Spoiler for the above video: I showed a plugin that adds border: solid 1px red; to all elements in a Vue app, and another plugin that flashes the screen red for 50ms every time there is mutation to the state.
Don't laugh - these are actually super useful debuging tools for me.
When I repeatedly called out the fact that PM CARES fund is not under RTI, was not needed in the first place when PM Relief fund and National and State Disaster Relief Funds existed, I got chastised by relatives, friends, everyone for criticising a "positive effort"
Well so, fuck all of you who said that (I remember all of you).
But, gladly, this time around as I can see, no company/individual is promoting PM CARES anymore. Everyone is donating to GiveIndia and directly to Ketto/Milaap fundraisers, even frickin ISKON, but not PM CARES.
That says a lot doesn't it ? Even the hardcode bhakt celebrities are not donating to PM CARES anymore.
Guess this has completed the demonetisation cycle now I guess, when finally even the bhakts know associating with it is a net negative impact on image.
In the industry, people are moving en-masse to Kotlin, Swift, TypeScript and Go. Like if you look around at product companies, 75~80% new things are written in these.
Yet we are still teaching Python/JS/C/Java to beginners. This is creating a bit of a problem here. Read on.
When I use `?:` or `?.let { } ` type of syntaxes in Kotlin it comes so naturally to me, because of my years spent in Java, understanding the null-safety problems, and the long chunks of code to work around them, that these 'feel' idiomatic.
For beginners, it is very different.
As someone who as been teaching programming and onboarding developers at bigger teams I see -
Those who have made websites in JS being put into large TS projects
Those who are still grasping Java being put into Kotlin projects (android or backend)
Php/Django folks starting Go
Gatekeeping happens in weird ways, and most of us just fall for it.
For example - lot of people have forced themselves to "like" alcohol, when initially they didn't like the taste, just to as to "blend in" with the cool crowd.
The "acquired taste" thing is scam.
And especially in the tech community and developers/programmers there are a bunch of similar fads.
- real devs use dark mode IDE
- real devs use vim to edit
- real devs use mechanical keyboards
- real devs do not use mouse.
All that is crap ok
I do not know if the following are enough to make me a real dev
- worked on custom kernels back in 10th grade
- made libraries downloaded > 50k/day
- mentored 5k+ android and nodejs devs personally
All of this using GUI editors, light themed IDEs, chiclet keyboards and mouse.
I never thought too highly of teaching as an activity or profession before I started doing it myself. There are teachers whom I deeply loved and respected though, and it always was for being "guiding" figures rather than for being great teachers of their subjects.
Thread ๐งต๐
The formal education system in India isn't the most conducive to produce great teachers for a bunch of reasons
1. No real performance evaluation in govt education instt 2. Too low pay and little care taken of in private ones 3. Investment into their learning is nil 4. Infra
As a result, we all growing up, have more stories of THAT "incompetent" teacher in school, whose own grammar was bad, or THAT teacher in college who never came to class.
Also as students, teachers are our favourite punching bags. Which is, ok fine, as long as it isn't toxic.
Since college days, I have launched 4 products (2 fail + 2 sold), started up thrice (1 failed, 1 sold, 1 running), lead a team at a $1B+ startup and worked as lead engineer at a Fortune 100 giant
Here are some learnings (tech/management/product)๐
Everything is a people problem. Always. 100% of the time. It isn't the code, the market, the product fit, the idea, the money. None of that.
BUT BUT BUT, do not blame 'a person' for it. That's a cop out. Fix it structurally, in the process, so it isn't repeated.
The single short term fix for 99.99% problems is money.
From cofounder problems to team bandwidth, to bad code. More money can stop a leaving cofounder from leaving, let you hire more people, or scale your server 10x.
It is a bandaid. Fix it properly eventually though.
I have worked at Micromax before, personally with @rahulsharma too, when we launched @YUplaygod
It was exciting because we wanted to launch a product based on the merits of the product (price, features, style) and not just "nationalism" as a feature.
And I have no grudge against @Micromax__India or @rahulsharma for the new brand "inMobile", because I have seen this man being able to impeccably pick out gaps in market for features and at unimaginable price points, and I would love to see "truly" made in India hardware more.
But it is sad that we are ready to skimp over pricing and quality of products and simply use "nationalism" as a feature to ship products.
This is exactly the opposite of what globalisation and liberalisation was all about. Heck even @Micromax__India wouldn't exist without that