4 ms·

Can you provide more details about the project you are talking about? I somehow doubt that a website like facebook would be easier to write and manage in a mini

Can you provide more details about the project you are talking about? I somehow doubt that a website like facebook would be easier to write and manage in a minimalist framework. I'm not sure the only project I have written React for would compare to something like facebook but it was a pretty complex SPA that I seriously doubt would've been better written in something like alpine. Sure React may be overkill for a personal blog and no one is saying it isn't but I wish people that have ported from React also assess honestly the complexity of the app we're talking about

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.
graemep 2y ago
Very few websites are like Facebook. Facebook is in many ways terrible. it can be hard to work out what to do, it can be glitchy (for example updates can be slow - stuff is presumably cached and takes time to update) and its VERY hard to manage reasonably active FB groups.
- jack_pp 2y ago
  Yeah sure the facebook frontend has a lot of issues and is frustrating at times but I'm not sure the random slow updates or even failures to load the page / partial info is React's fault

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.

graemep 2y ago

Very few websites are like Facebook. Facebook is in many ways terrible. it can be hard to work out what to do, it can be glitchy (for example updates can be slow - stuff is presumably cached and takes time to update) and its VERY hard to manage reasonably active FB groups.

jack_pp 2y ago
Yeah sure the facebook frontend has a lot of issues and is frustrating at times but I'm not sure the random slow updates or even failures to load the page / partial info is React's fault