Book Review: Scion of Ikshvaku by Amish

Posted on Leave a comment
Book cover for Scion of Ikshavaku

Cross-posted from Goodreads: https://www.goodreads.com/review/show/3081641646

Scion of Ikshvaku was my first Amish book. Amish has been called India’s literary rockstar, and has been compared with Dan Brown. So, naturally, I was much excited about reading him. Although I liked the storytelling, I was put off a bit by his writing style.

Being born and bred in a Hindu family, I knew the story in and out. So I carried a certain amount of bias into reading Amish’s version of Ramayan. Despite this I loved the big and small twists in this story, especially the parts where Amish has given logical explanations for what we’ve been taught since centuries to be the results of supernatural phenomena. I really liked that; Amish is super creative there.

I also loved how Amish has portrayed feminism throughout the book. Sita is shown as a strong-willed and independent better half of Ram, which is a far cry from her character’s TV adaptations. In most Hindu hymns and religious songs, Sita is worshipped along with Ram. After reading Amish’s version, I can now better appreciate why this is so. Also, Ram’s steadfast belief in monogamy and his reasons for that are very well put together by Amish. I enjoyed the bits where feminine and masculine societies were contrasted through Ram’s own thoughts.

Perhaps the best thing I liked in the book was Ram’s character development. Amish couldn’t have done a better job on that. During second half of the book I fell in love with the character, especially his stoicism, clear beliefs and respect for the law. His godlike mastery over archery was well represented.

What I didn’t like, however, were the clichés that Amish used generously throughout the book. His writing style in this book reflected a childlike excitement around telling a cleverly written story. I also felt a general lack of thrill in the story. Again, that could be because of my pre-contained biases. I knew the whole story already. But I tried my best to keep my existing knowledge at bay while reading Amish’s version. Still, I feel some major turns and twists may have been make more thrilling. The supposed cliffhanger (Hanuman’s entry) in the end also felt a bit lackluster.

Overall, Amish’s Scion of Ikshavaku is a good read, especially for people who want to go deeper into historical aspects of Ramayan’s world and want logical explanations for its events. But unless someone assures me that the next book in series (Sita) has a better writing and storytelling, I may not pick it up.

A joke only Flutter developers would understand

Posted on Leave a comment

Developer: “YESSS! My world-class widget test is ready to run.”

(runs the test)

Debug Console: “Expected to see 1 widget, found none.”

Developer: What! Why, why, why!!!

(figures out all async calls in the widget; spends 4 hours re-reading about widget testing, exploring the source code of WidgetTester.pump() and setting up mock classes using Mockito.)

Developer: “Muwaha haha! I am the greatest mocker ever lived.”

(runs the test again)

Debug Console: “A RenderFlex overflowed by 20 pixels on the right.”

A compelling case for Next.js

Posted on Leave a comment
Nextjs logo

If GitHub stats are anything to go by, Next.js has received incredible attention of late.

Freelancers and enterprises alike are creating their next applications in or migrating their existing ones to Next.js. When I was recently on-boarded to my first account at Sapient, the departing senior XT architect highly recommended that we migrate to it.

But what is Next.js? Let’s first start with that.

The uninitiated probably know that Next.js has something to do with React. What exactly? Is it the next generation of React? Or something lighter and more performant (like Preact)?

I’ll attempt the simplest explanation possible. Next.js is a way to create server-side web pages all the while allowing you to compose your app using React components. It internally uses React’s server-side rendering principles (and perhaps ReactDOMServer?) to create SSR pages.

It’s okay if you don’t get it the first time. So I’ll quote from its official docs.

In the words of Zeit (people behind Next.js) themselves:

You may want to server-side render certain pages and statically prerender others (balancing SEO and speed).

Think about how webapps are created with PHP. You create some files, write PHP code, then simply deploy it. We don’t have to worry about routing much, and the app is rendered on the server by default.

That’s exactly what we do with Next.js. Instead of PHP, we build the app with JavaScript and React.

Wait. What?!

Are we going back to the server-side days? Weren’t we meant to move away from server-side on to client-side for performance reasons? Is creating single page client applications not the latest ritual? Besides, PHP, JSP, Ruby or Rails, ASP.NET… all can apparently do what Next.js promises.

To fully understand this, we must recap the pros and cons of server- and client-heavy apps.

Server-sideClient-side
Time to first byte (TTFB)Bad
(html is served after full processing on the server, taking its size up)
Good
(a bare-bones, ultra-lightweight html is served immediately)
Time to first meaningful paint (TTFMP)Good
(user can see the “primary” contents sooner)
Bad
(user has to wait for browser’s JS engine to execute all scripts to perceive a page’s “primary” contents)
SecurityLess surface area for vulnerabilities
(what happens on the server stays on the server)
More surface area for vulnerabilities
(increased scope for bad implementations of security due to exposed auth data)
SEO PerformanceGood
(crawlers can easily parse the entire html rendered then and there)
Bad
(crawlers that cannot execute JS code are just left out)
General PerformanceGoodDepends
(see the second article in links below)

I highly recommended reading the following articles once:

An Introduction to React Server-Side Rendering
Next.js vs. Create React App: Whose apps are more performant?
The Benefits of Server Side Rendering Over Client Side Rendering

The second article is especially unmissable, and makes a great point in favor of server-side rendering (SSR) in general. It explains with the help of key practical metrics why SSR wins over CSR in all important areas.

Personally, I have always been a BIG advocate of taking server-side along with client-side development. I don’t believe there’s any such thing as a front-end developer or a back-end developer. A front-end person who doesn’t not know their way around back-end code should not be called a developer in the first place! SSR or not, any app can be performant and secure only if its developers understand the full stack well.

Leaving Accenture (after 9 years)

Posted on Leave a comment

Today is my last day at Accenture. I am finally leaving it (for the second and last time) after more than 9 years of giving myself to it. In today’s rapidly moving world, that’s a very long time. Long enough to see so many colleagues come and go until you were the only one left. It’s the rightest time to move out for me. I had a mix of fond and not-so-fond memories during my two stays. I’ll ever be so thankful for all the good ones. Mostly there was a lot to learn, but the learning had dried up since a year or so. I dragged it too far. The learning should never stop! Goodbye, Accenture.