4 ms·
There is nothing you can do in the front end that a .NET Forms application from a few years ago could not also easily handle. And the .Net forms application wo
by addicted 3y ago
There is nothing you can do in the front end that a .NET Forms application from a few years ago could not also easily handle.
And the .Net forms application would be immeasurably simpler in terms of complexity and as a bonus, would have the backend thrown in almost for free as well.
I deliberately picked .Net forms because despite being much simpler than today’s front end stacks, it was still, much like any MS product, an overengineered corporate driven MS tech.
Something like Ruby on Rails, Laravel etc shows that front end is not inherently complex.
- gemstones 3y agoSo why did the frontend engineers move on from Ruby on Rails? When I was an ROR developer, RailsCasts would tell you to do basically the same thing as HTMX, return partial HTML and use a tiny bit of JS to update the appropriate part of the DOM. It’s a good fit for simple experiences, but breaks down when you need the result to update more than one place (say, a counter by the cart icon, or a set of options in a select in the sidebar.) Then, you hypermedia approach has forced you to try and explore your HTML snippet to pull relevant information, rather than get it in a nice structured format.
- graftak 3y agoRendering 3d VR environments with interactive points of interest, live video players with real time highlight markings and sport standings with graphs comparing parallel games in the same league, having online conferences with 20K visitors that can interact with each other through (video) (group) chat. Sweet.
- majewsky 3y agoOk, agreed that 1% of all apps need a complicated tech stack. Meanwhile the bulk of all web development is simple CRUD forms and reports.
- text0404 3y agothis is a common sentiment in these anti-modern-FE threads. it's a problem of imagination; i build internal tools for a large company you've definitely heard of. my org is several thousand people. we absolutely need to use react for the complex internal 2d/3d combo applications we build for debugging our next-gen products. given all the different platforms we need to support and the realtime nature of these incredibly complex tools, we _must_ build them for the web; we tried native applications and it does not scale. many applications are much more complex than some simple forms.