32 ms·
Agree, too many believe in the silver-bullet that solves all their problems. Different problems require different solutions, it's kind of simple but hard to rea
by diggan 3y ago
Agree, too many believe in the silver-bullet that solves all their problems. Different problems require different solutions, it's kind of simple but hard to realize when you're deep into the woods.
If you want to build a vector editor in the browser then yes, probably you want to leverage webassembly, canvas, webgl or whatever you fancy.
But if you're building a more basic application (like most CRUD SaaS actually are) then probably you don't want to over-complicate it, as you instead want to be able to change and iterate quickly, so simplest tools and solutions gives you the most velocity for changes, until you've figured out the best way forward.
Trouble is to recognize where on the scale of "Figma <> news.ycombinator.com" you should be, and it's hard to identify exactly where the line gets drawn where you can justify upfront technical innovation in favor of true-and-tested approaches.
- The_Colonel 3y agoI think there's a similar dynamic as behind "nobody got fired for choosing Oracle" - it's safer to choose a more complex, but also more flexible technology. If you're a tech lead, your worst nightmare is when you have to say - "this is very difficult to do with the current stack. When we were choosing this stack, we assumed you'll never want these things". You're not going to extract a binding promise from product/business that they will never want a certain class of things - you can only guess, and then hope, that the product will remain a dumb CRUD.
- rezonant 3y agoThis exactly. And with modern approaches (not that it's not without a fair amount of effort), you can achieve both an MPA style with SPA features via "isomorphic" JS (SSR).
- ryanbrunner 3y agoThe converse is also true, you can add a lot more interactivity than you used to in a server rendered HTML world with stuff like LiveView in Phoenix or Hotwire in the Rails world. I think a good heuristic is looking at whether the UX of your app feels more multi-page or single page, that should be a pretty big factor in your decision.
- ryanbrunner 3y agoParticularly with the web though, you're very rarely completely locked into one front end technology. It's 100% reasonable to say "this particular complex interaction should use React" without needing to port the entire application. I'm sure even Photoshop and Figma could build their account management or settings pages with MPA if they wanted to - I don't use them and have no idea if they do, but "some parts of my application require complex tools" doesn't mean "all of my app requires complex tools"
- rezonant 3y agoAbsolutely, but it's a matter of tradeoffs and where you place them. It's still plenty common to use an MPA framework like Rails or Django for the management or CMS portion of your solution, while using an SPA framework for your front presentation. It's much more acceptable to say "doing that for this staff workflow is hard to do with our stack" than "doing this for our customers is hard to do with our stack".
- ryanbrunner 3y agoSure! I think it's just a question of scale and knowing your problem. If it's "the entire customer-facing area needs a large amount of interactivity" then going with a SPA makes sense. If it's "this particular UI element on the customer app needs a large amount of interactivity", that's easy to build as an isolated component regardless of the technology of the rest of the app. One thing that I'll always view as a smell though is "we don't need X now, but we might need X in the future, so we should adopt this more complex technology just in case". We've learned that lesson MANY times as developers, it's not any less true for front-end technologies.