767 karma · joined August 31, 2011
vaughanhackernews at gmail
Imagine how simple apps would be if your data model and query interface was exactly the same on the server and client. With automatic caching and fetching logic.
There is such an incredibly complex chain of code to do the simplest of things.
What we lack is a good client-side relational+graph database that has an identical server-side implementation.
For a snappy data-centric app, you pretty much need your entire app logic to run client-side.
Everyone always ends up with this terrible denormalized client-side cache with duplicated Server side logic.
What you really want is the exact same db running server-side and client-side.
I thought for a while this would be an sql db but now I think sql and the relational model is the wrong approach for web app data as they are inefficient for watching queries and syncing.
Software development has become far too complex without the right sensible abstractions keeping things under control.
Every developer would probably want an Airtable control to drop into their app, that they can use to build up their schema and then add custom functionality. But there isn’t one. I think mostly because there were too many technologies coming along at such a rapid pace that integrating became difficult because everyone is using a different tech stack and changing tech stacks all the time. And there are new libraries to do everything. E.g. No one uses Redux anymore. Graphql came along. Everyone is back on SQL. And what’s next?
The pace of tech needs to settle down and then we can build some solid reusable libraries that do the same thing as no code tools.
I use it everyday and feel I underinvested greatly. I would like a 4 slice but a good brand like Breville. I want speed, toasting accuracy, easy to remove slices, easy to clean crumbs.
It takes a few weeks to upload everything, and by that time the trial has expired.
I have never got it to backup my files ever.
Their settings dialog integrates with macOS preferences and freezes while it scans for files to backup without giving me any status update. It uploads so damn slowly it’s pretty useless. If I was to move/rename things around it would take weeks more to reupload. Every time I try to ignore some files so it’s actually useful, it blocks my system prefs again and takes forever to rescan.
I honestly don’t know how anyone uses it.
Carbon Copy Cloner on the other hand is excellent software. Entire backups of 4TB drive in less than <20mins. And excellent support.
My experience is that a lot of these features are more easily implemented than the time taken to handle the edge cases of using existing libraries, getting them to work with your UI framework (React/Angular), and getting them to work with your data service layer.
We don't need big libraries, we need to mix smaller libraries together that each do one thing well.
Like starting with a tutorial of how to build a data grid from scratch with suggestions of utilities to add along the way. Most people would avoid this because they see a library that does most of what they want and get a FOMO...but if they could only see the hours they will lose trying to customize it, they would have preferred to start from scratch. This has been such a constant experience for me with almost every framework/library in tech.
Destructuring where two funcs in the same scope return the same named object key will make your code harder to read for example.
Function options split across multiple lines also make things harder to read and make it less able to fit logic on a single screen.
I prefer less verbose code if I can have my function calls as single lines <80 char wide with self-documenting names that read like recipe instructions as to what is going on step by step.
Prettier’s line splitting makes things less readable a lot of the time. I use prettier-ignore quite a bit.
E.g. Think about Airtable vs Google Sheets.
Also consider data sources and data binding. Do you bind a cell, a row, the entire table? How do you handle real-time updates or infinite scrolling. How is styling done?
It always feels like we should just standardize the current thing because we cannot see what will come next.
That said, there still does not feel like a good data grid for React, and trying to build one makes it feel like React is just getting in the way.
Examples:
- https://github.com/devhubapp/devhub
- https://github.com/mmazzarolo/react-native-universal-monorep...
RN desktop support is weak. But your mobile apps will work quite differently to your desktop apps anyway. And you probably want something that can run on the web too. So for desktop you just put your web app in Electron.
The difference between mobile and web will mean having to implement different routing and components, but you can share a lot of code.
Flutter is the new kid on the block.
Having done this helps you to see things in new frameworks that will inevitably lead to pain.
As often as people deride it, the Node.js many-small-package philosophy (inspired by Unix) is what I keep coming back to. If one package doesn't provide the right abstraction to do something, if it's built on top of two smaller packages, I can assemble a new package with these smaller packages to achieve what I want. The smaller the package the better.
From the day the first line of code in a project is written, a desire to rewrite from scratch starts to grow - to return to the productivity of having an empty slate. If you compose your app from small single-purpose packages, rewriting becomes trivial.
I can see it being useful at large organizations with many services written in different languages with many distinct teams. But then there is of course performance concerns from giving users so much flexibility, versus offering more limited REST/RPC APIs with more predictable performance.
But for your own APIs where your frontend and backend are tightly coupled, it just gets in the way and is too verbose. You often don't want a big nested response, but rather a flat, normalized response for caching. The JSON:API standard is much more ideal in this regard. Mutations and optimistic UI updates are incredibly painful. Look at this craziness: https://www.apollographql.com/docs/react/performance/optimis.... Most client implementations do not maintain any concept of the underlying relations between the data they return either which makes caching difficult. Code generation of types is annoying to have to run as a separate process, and doesn't result in the best experience. Writing out all the fields you need for every query in full is too verbose and most people don't need to limit the number of fields they need returned, and then hacks like using Fragments feel messy. Writing schemas is painful too. You have to jump through hoops if you want to just return a JSON object.
Also, Apollo was a terrible client with really bad error messages for so long and never seemed to fix things. The caching and optimistic UI updates are terrible as mentioned too. Urql seemed to do the caching a lot better, but it feels like huge amounts of code to patch over a leaky abstraction, just like most ORMs.
In the short-term I would suggest trying out something like trpc.io. It's like the feeling of going from Java to Python again.
My general attitude is that your API should stay as close as possible to your backend data model, otherwise caching and optimistic UI updates become really tricky as you end up with all this mapping code. GQL is forcing a graph structure over a relational data model which doesn't fit.
Keep it simple. Request/response. Then see what you need on top of that.