571–580 of 962 posts
It seems like Shopify has fallen into a trap thinking that more complexity costs nothing because of AI. In the age of AI we have to embrace the same principle as before that complexity needs to be tamed, not multiplied. Even as humans struggled with complexity, from what I see now AI struggles very much the same. Hence I don't think this will age well.
Earlier quoted context omitted.
Of course it would. Supply and demand. Some companies would decide not to bother. Others would decide it was worthwhile. The limited pool of supply (app developers) would be distributed across demand.
>> Some companies would decide not to bother. Others would decide it was worthwhile. The parent's point is that AI lowers the cost/benefit ratio drastically, by reducing the cost. So companies that would have shied away from projects like this pre-AI are now pulling the trigger without much hesitation.
Earlier quoted context omitted.
On theweb, not surprised that Rails switched from kind of encouraging people to use as many browser-automated tests (under whatever name) as possible , to trying to discourage people from using any. Rails way really likes being absolutist. I work in Rails too, I try to keep them to a minimum, but I definitely try to do at least one happy-path test of any major page (which includes automated accessibility audit), goin…
Forgot the source but DHH mentioned it's not all, just most. Still makes sense to have on some scenario, just not all, or the default anymore
As an iOS Engineer that has been fighting the battle against every C-level type who brings up the subject of a shared codebase my whole career, I feel very validated.
They specifically say in the post how React Native was the correct decision and that it worked well for them. Now it's a different situation as implementation has become incredibly cheap.
yeah because they don't care about a top notch user experience.
Hopefully they will write more about that in the future.
Earlier quoted context omitted.
And people say AI isn't taking SWE jobs...
While I mostly agree with you, this is the kind of thing that might not have been done if the AI couldn't do the heavy lifting. They had previously chosen React Native because it was easier for programmers to keep it updated, since it was really just 1 codebase. With AI, those same programmers can do the more difficult version, keeping the native apps updated separately. So did it kill a job, or did it make it possib…
I'm sitting here at my desk overlooking Cordova Street. The street that Apache Cordova is named after. I've seen this debate for almost two decades now. Teams jump on the latest cross-platform framework assuming that it will reduce headcount cost at the expense of having a lowest-common denominator app on each platform. The latter is true but the former is false. What ends up happening is that teams start as 20 iOS e…
Companies (or their consulting agencies) had tons of webdevs - working on their company public and internal websites, but not many native smartphone devs. Those were the days when people who completed the Stanford iPhone programming course were snapped up lickety-split.
But everyone was clamouring to have their own smartphone app for all the smartphone platforms (well, iPhone, Android, maybe Blackberry)
Hiring enough smartphone devs to fill multiple smartphone-specific dev teams would be like trying to build multiple AI development workstation on the cheap these days.
In the late 2000s, people realized they could write an HTML/JS/CSS website and compile to an app for each J2ME/Blackberry/iPhone/Android platform that would "serve" the website. So their webdevs could be converted to smartphone app developers.
Hey, if you planned your website well, you could use the same business logic for your website AND your smartphone apps.
That was the elevator pitch.
You'd need an actual (maybe two) native smartphone devs for each platform to handle any areas where the marketing didn't meet reality 100%.
But that was doable versus hiring multiple native smartphone devs for each platform.
And in the late 2000s, there seemed to be a lot of potentially viable smartphone platforms - iPhone, Android, Blackberry, J2ME, Windows Phone, Palm's webOS. But we know now that in a few years, all but two would wither away.
Even with native APIs exposed via JavaScript, there were obvious problems with these webview apps. The apps were passable if the app didn't require much user interaction or computation.
Projects like React Native and others tried to reduce the amount of webview usage and increase the amount of native UI controls used.
The mobile platforms themselves aren't going to improve their platform-specific webview to make it easier for webdevs to mimic the "native" experience. Why would they?
Earlier quoted context omitted.
They specifically say in the post how React Native was the correct decision and that it worked well for them. Now it's a different situation as implementation has become incredibly cheap.
Not sure why someone would say it was a wrong decision. Why would they even need to do this if LLMs make coding easier. They are likely chasing the things I advocate for: direct access to latest APIs from each platform, platform specific UI, UI that behaves correctly on each platform without chasing down edge case solutions (also said as ui that looks and feels "right"), and a bonus of separate developer pool to hire…