HackerTrans
TopNewTrendsCommentsPastAskShowJobs

dinko7

no profile record

Submissions

[untitled]

1 points·by dinko7·il y a 2 mois·0 comments

Dart Back End in 2026

dinkomarinac.dev
3 points·by dinko7·il y a 4 mois·1 comments

Mobile Is Not a Smaller Web App

dinkomarinac.dev
2 points·by dinko7·il y a 4 mois·0 comments

What I Learned After Building 3 TV Apps Coming from Mobile

dinkomarinac.dev
53 points·by dinko7·il y a 5 mois·47 comments

Tech stack is a business decision

dinkomarinac.dev
3 points·by dinko7·il y a 5 mois·1 comments

comments

dinko7
·il y a 2 mois·discuss
[dead]
dinko7
·il y a 4 mois·discuss
Dart on the backend has had a resurgence lately.

Relic. Dart Cloud Functions.

If you’re building with Flutter and you’re wondering whether the Dart backend actually makes sense now, and what your real options are, I broke it down in a practical guide.
dinko7
·il y a 5 mois·discuss
I write all my articles by hand for the first draft and the final polish. I do use LLMs in between to try to get a clearer message (to what I find appropriate).

I understand if you don't want to read it, but there is nothing dishonest about this article. I've lived through what I wrote with those 3 apps. Take it as you wish and have a good day.
dinko7
·il y a 5 mois·discuss
My 2 cents: if you are big enough and the competition isn't as strong, users will give you a pass on some performance issues as long as they get the content they want.
dinko7
·il y a 5 mois·discuss
I remember one time there was a random Philips TV that just kept crashing when the user tried to do "right" on the last item in a horizontal menu. The client kept testing on this TV, and we spent 3 weeks because my team lead at the time wouldn't trust me that I needed the TV to solve it.

They finally agreed to send us the TV. Solved the issue in 10mins.
dinko7
·il y a 5 mois·discuss
I've noticed this as well. My best guess is either low hardware or just a bad solution.

If they planned to use a unified codebase for Prime app, they likely went with something HTML/CSS-based, which would explain the performance issues. I could be wrong, but it's just a hunch I have.
dinko7
·il y a 5 mois·discuss
Absolutely. I do the same. IMO it's either Apple TV or Nvidia Shield. Everything else is hit or miss (likely miss).

From a developer's perspective, it's a nightmare to deal with such hardware.
dinko7
·il y a 5 mois·discuss
I was thinking about this for the last 2 years.

People are constantly arguing about tech stacks.

Now I finally have words to express it and wrote an article.

Wondering what everybody here thinks. Does this align with your experience as well?
dinko7
·l’année dernière·discuss
That's the beauty of diversity. You can use whatever resonates with you best and still make it work on the app side.
dinko7
·l’année dernière·discuss
Yes it does, and I specifically outlined that in my other article: https://dinkomarinac.dev/riverpod-simplified-lessons-learned...

His question was directed towards the state management, hence the answer only covered that.
dinko7
·l’année dernière·discuss
Hi, author of the article here.

Any state management approach requires you to adapt your way of thinking, whether that be BLoC, Riverpod, Redux or anything you want to use.

Rivepod gained popularity because it's really simple to pick up: create a Notifier, create a Provider for it, and observe, while some other approaches require additional boilerplate, setup, and understanding.

Your approach would work if you are only observing that state from a single widget, which might not always be the case. Additionally, assuming useState is using setState under the hood means it will rebuild the whole widget on change, while with Riverpod, you have the flexibility to wrap any part of a complex widget into a Consumer or listen to only part of the exposed state on the Notifier with .select().

To put it simply: - Notifiers are used for app state - Hooks are used for ephemeral state (local widget state)

Hope this clears it bit for you.