4 ms·

I have a website I use to host all my personal software. This includes a front end portfolio with various somewhat complicated data applications, I have a perso

by 65 2y ago

I have a website I use to host all my personal software. This includes a front end portfolio with various somewhat complicated data applications, I have a personal notes app, RSS reader, content feed algorithm, games, e-book reader, and S3 file manager. You are definitely right that complexity isn't as big in terms of number of users (for me, it's one), though I'm still making functionally complex applications. Facebook is obviously going to have a ton of shit going on all at once, though for the vast majority of sites it's mostly just some form or another of CRUD with perhaps some somewhat complex front end UX. You can build many web apps without React. To me the secret is with JSX, which makes everything way easier to manage. Realistically the only issues with using a more minimalist framework instead of React is global state management and persistent components on page navigation. Global state management in Alpine can be done with Alpine.store and persistent components can be implemented with either Hotwired Turbo, Alpine AJAX, or HTMX. Are these things better than React Context/Redux and React Router/Next Router/Some other router? Probably not. But it does work. I wouldn't recommend this approach for actual businesses, mostly because devs will already know React and thus be more productive. But I think it's genuinely a viable approach for building web apps.

lelanthran 2y ago
> I wouldn't recommend this approach for actual businesses, mostly because devs will already know React and thus be more productive. But I think it's genuinely a viable approach for building web apps. That's just the thing. Businesses chose a specific stack because the campaigning for that stack won out amongst any competing stack, not because that stack most closely aligned with their requirements and needs. Boring Anecdote Time: I do contract work. All current frameworks have a velocity for new API/endpoint creation (with DB schema modification) of between 4hrs - 8hrs (spread out over 3 - 4 PRs)[1], assuming all the PRs come back with LGTM. My home-grown b/end framework cuts this down to between 5min - 20min (one PR only) for the same API/endpoint addition. However, I only use my home-grown b/end stack for full webapp development, when a client wants a new system, and only when that client is not a technology company, or doesn't have an in-house development team. That's because most businesses are using what their tech teams mandate, which IME is either Java, C# or (not as common around here) a Python or Node b/end. Once(!) I had a dev manager agree that velocity for MVP and velocity for maintenance is a higher priority than conforming to any of the current b/end languages, which included but was not limited to C++, Java, Kotlin, Python, Node, React, Ruby, MSSQL, MySQL ... etc. A few months later, on a call with him he expressed how fast his dev team was iterating on my stack when extending the system. Currently they are stuck on a lot of legacy that has to be extended, but they are definitely thinking about b/end in a new way now. [1] Assuming the usual workflow of PR for ORM changes, then PR for data object layer + unit tests, then PR for domain object layer + unit tests, then PR for business logic + unit tests.

by 65 2y ago

lelanthran 2y ago

> I wouldn't recommend this approach for actual businesses, mostly because devs will already know React and thus be more productive. But I think it's genuinely a viable approach for building web apps. That's just the thing. Businesses chose a specific stack because the campaigning for that stack won out amongst any competing stack, not because that stack most closely aligned with their requirements and needs. Boring Anecdote Time: I do contract work. All current frameworks have a velocity for new API/endpoint creation (with DB schema modification) of between 4hrs - 8hrs (spread out over 3 - 4 PRs)[1], assuming all the PRs come back with LGTM. My home-grown b/end framework cuts this down to between 5min - 20min (one PR only) for the same API/endpoint addition. However, I only use my home-grown b/end stack for full webapp development, when a client wants a new system, and only when that client is not a technology company, or doesn't have an in-house development team. That's because most businesses are using what their tech teams mandate, which IME is either Java, C# or (not as common around here) a Python or Node b/end. Once(!) I had a dev manager agree that velocity for MVP and velocity for maintenance is a higher priority than conforming to any of the current b/end languages, which included but was not limited to C++, Java, Kotlin, Python, Node, React, Ruby, MSSQL, MySQL ... etc. A few months later, on a call with him he expressed how fast his dev team was iterating on my stack when extending the system. Currently they are stuck on a lot of legacy that has to be extended, but they are definitely thinking about b/end in a new way now. [1] Assuming the usual workflow of PR for ORM changes, then PR for data object layer + unit tests, then PR for domain object layer + unit tests, then PR for business logic + unit tests.