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.
Plugging back to top of the thread



If I think of anything else, will add.

โ€ข โ€ข โ€ข

Missing some Tweet in this thread? You can try to force a refresh
ใ€€

Keep Current with Arnav Gupta๐Ÿ˜ท ๐Ÿ’‰โ—พ๐Ÿ’‰โ–ก

Arnav Gupta๐Ÿ˜ท ๐Ÿ’‰โ—พ๐Ÿ’‰โ–ก Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @championswimmer

11 May
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.
Read 4 tweets
12 Dec 20
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
Read 6 tweets
11 Dec 20
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.
Read 5 tweets
26 Oct 20
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.
Read 55 tweets
17 Oct 20
Ok weekend thread ๐Ÿงต time ๐Ÿ‘‰

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.
Read 17 tweets
16 Oct 20
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
Read 4 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!

:(