8 ms·

The "full-stack framework" fallacy

11 points by waynesutton 2y ago

cetra3 2y ago
This looks like a (not even) thinly veiled advertisement for their Convex product: https://www.convex.dev/ https://www.convex.dev/. I am interested in knowing who would make a decision to pay for something like this when there are a gamut of open source options available. Like what is the compelling reason to use something like this.
- rizky05 2y ago
  [dead]
- saliagato 2y ago
  Speed of development, developer experience, ready to go templates. You should check it out, it’s really cool
  - AlchemistCamp 2y ago
    How does the speed of development of the entire app, not just the backend, compare to Rails + Hotwire or Laravel Livewire?
    - ianhmacartney 2y ago
      Author here- and yes as a disclaimer I work at Convex. As a caveat to that disclaimer, I pivoted my career to work here b/c I genuinely believe it moves the industry forward b/c of the default correctness guarantees, along with other things. To this question here, some of the things that accelerate full stack development: 1. Automatically updates your UI when DB data changes, not just on a per-document one-off subscription, but based on a whole server function's execution which is deterministic and cached. And regardless if the changes were made in the current browser tab or by a different user elsewhere. Not having to remember all the places to force refresh when a user updates their profile name, e.g., makes it way faster. And not only do the Convex client react hooks fire on data changes, the data they return for a page render is all from the same logical timestamp. You don't have to worry about one part of the UI saying that payment is pending when another says it's been paid. 2. End-to-end types without codegen. When you define a server function, you define the argument validators, which immediately show up on the types for calling it from the frontend. You can iterate on your backend function and frontend types side-by-side without redefining types or codegen in the loop. 3. Automatic retries for database conflicts, as well as retries for mutations fired from the client. B/c mutations are deterministic and side-effect-free (other than transactional changes to the DB and scheduler), the client can keep retrying them and guarantee exactly-once execution. And if your mutation had DB conflicts, it's automatically retried (up to a limit with backoff). So the client can submit operations without worrying about how to recover on conflict. There's obv. a bunch more in the article about features like text search and other things out of the box, but those maybe are more conveniences on the backend, since maybe a frontend person wouldn't have been setting up Algolia, etc.
  - cetra3 2y ago
    "Really cool" is not compelling enough for me to decide to build a product against something like this. Here is, at a minimum, I would require to even consider: - Comparisons against other types of stacks, like laravel livewire or phoenix liveview - Performance metrics/stats/benchmarks whatever. You need to be faster and more robust than the other things out there, or provide some other benefit - First Class self-hosted on premise install version without dependency on any cloud provider. Kubernetes helm charts or docker compose stacks or whatever - I do actually like that you have a time-windowed source available license. That is something that alleviates the concern if you go under - Jepsen or similar analysis, need to make sure whatever consistency guarantees you are advertising hold up
    - ianhmacartney 2y ago
      One public comparison on latency is https://db-latency.vercel.app/ https://db-latency.vercel.app/ For comparisons, you can check out: https://stack.convex.dev/convex-vs-firebase https://stack.convex.dev/convex-vs-firebase https://stack.convex.dev/convex-vs-relational-databases https://stack.convex.dev/convex-vs-relational-databases https://www.convex.dev/compare/supabase https://www.convex.dev/compare/supabase https://www.convex.dev/compare/mongodb https://www.convex.dev/compare/mongodb I'll save you more of a marketing pitch, since you seem to have enough of my pitching Convex in the article:) The bullet points at the bottom of the article should be a pretty concise list - I'd call out the reactivity / subscriptions / caching. To learn how all that magic works, check out https://stack.convex.dev/how-convex-works https://stack.convex.dev/how-convex-works
  - yard2010 2y ago
    Remix is really cool too! On the paper
- sujayakar 2y ago
  note that convex is open source! https://github.com/get-convex/convex-backend https://github.com/get-convex/convex-backend if you don't want to manage your own infrastructure, you can use our hosted product, but otherwise it's totally fine to self-host the open source binary. (convex cofounder here)
Swizec 2y ago
We can't solve this problem until we at least agree what "full-stack" even means. Right now you have many frontend-focused engineers who justifyably argue that something like React Server Components is a backend concern because it runs on the server. I think they're wrong but they have a point. You also have many backend-focused engineers who justifyably argue that something like Rails is a frontend concern because it's designed to run webpages. You probably wouldn't want to use Rails to build an ETL pipeline or an airline scheduling system, for example. I think they're kinda right but also a little bit wrong. And ultimately the whole debate is so deep in the It Depends territory that I honestly think 90% of the people arguing come from such vastly different backgrounds and situations that they're just talking past each other. They're never going to agree because the problems they're solving are too different to ever have the same solution. edit: I say this as someone with professional experience in almost all the usual suspects (Django, Rails, Flask, various JavaScript frankenstacks, even PHP).
- ianhmacartney 2y ago
  Very much agree. The tools for various jobs differ widely. However, my current take is that full-stack is more about enablement of engineers vs. a specific product or technology. Things at the protocol level (ProtoBuf, OpenAPI specs, etc.), things at the framework level (fancy types with tRPC or Convex), things at the application level (dropping in full stack features by someone without deep expertise in both domains) all qualify in my book. And rather than a discrete "you are now a full-stack dev, my child" moment, it's about blurring the line, the same way that k8s lets some backend folks play SRE here & there. Background. My career has spanned these in different ways: Front-end: I started in iOS in 2010 (back then it wasn't called iOS yet - just iPhone), where I was a more pure frontend dev. The server was using python and Haskell and that team was the "cool kids" in my view. The backend/frontend contract was using ProtBuf over a socket (not WebSocket, which hadn't been standardized yet), so we really didn't work closely together, and no one was "full-stack". Backend: Wanting to be a "cool kid" I joined Dropbox and eventually was the technical lead for Dropbox Previews, generating video, pdfs, images for user content using hundreds of machines, using a combo of Go and Python. I didn't work very closely with the myriad of teams using the previews for various products (their interface was the HTTP endpoints we exposed). One fun statistic: if you removed the cache and processed the full file for every user’s request, it would amount to processing over one exabyte of data per day. "Full-stack" tbh my experience crossing the gap is only somewhat recent (last 5 years or so) where I did freelance / contracting for various startups and established companies. I brushed up on React, learned TypeScript, but still mostly focused on backends - which usually ended up overly robust for the level of operational expertise of the companies I was handing the projects off to: like handing off a full kubernetes setup for running some GPU machines and orchestrating some fan-in / fan-out pipelines for ML image processing, when I'm sure there were mostly-fine ML workflow companies I could have used. Anyways this was much longer than anticipated but hope it adds some color
austin-cheney 2y ago
The full stack web is a fallacy because it exposes how much the developers involved cannot program, at least in this context. As a former JavaScript developer most of the people doing that work cannot program. That is why frameworks are so essential. What percentage of these people could realistically do any fraction of their jobs without third party abstractions line React or jQuery? It’s striking. Look, what’s the primary mission here: 1. Put text on screen 2. Handle user events Why is that so hard? Because nobody knows what they are doing, the blind leading the blind. The compile target on the front end is the DOM and that absolutely scares the shit out of people. Secondly, communicating outside the browser requires network traffic handling which also scared the shit out of people. Finally any kind of event handling requires an understanding of the event loop and listeners and that also scares the shit out of people. Finally, most people cannot write in JavaScript. Instead they write Java (or whatever) and modify the syntax just enough to avoid critical run time failures. The blessings of a lexical first functional environment are often absent because the language is a mystery. Fucking horrible mess. None of this is challenging. It’s stupid easy to learn, but there is almost nobody willing to teach it. The insecurity in that line of work is so universal I refuse to go back to that line of work for less than $500,000 salary.
- megadal 2y ago
  This sounds a lot like gatekeeping to me. It's not that you can't build a website without a framework, its that at the end of the day, no one cares what tools you use (in front end), it's how fast you get the job done, does it look like the mock up, and does it function. No one cares if the site is written in vanilla JS vs. a framework except a certain segment of HN web purists.
  - austin-cheney 2y ago
    80% agree. That is immediately true when only talking about code, but then absolutely everyone bitches about how shitty the result is (big, slow, brittle, and so on). People do care enough to complain, even non technical people. Worse than that people who do that work also bitch about how shitty the results are too, but then continue writing garbage because that’s the best they can do.

11 points by waynesutton 2y ago

This looks like a (not even) thinly veiled advertisement for their Convex product: https://www.convex.dev/ https://www.convex.dev/. I am interested in knowing who would make a decision to pay for something like this when there are a gamut of open source options available. Like what is the compelling reason to use something like this.

rizky05 2y ago
[dead]
saliagato 2y ago
Speed of development, developer experience, ready to go templates. You should check it out, it’s really cool
- AlchemistCamp 2y ago
  How does the speed of development of the entire app, not just the backend, compare to Rails + Hotwire or Laravel Livewire?
  - ianhmacartney 2y ago
    Author here- and yes as a disclaimer I work at Convex. As a caveat to that disclaimer, I pivoted my career to work here b/c I genuinely believe it moves the industry forward b/c of the default correctness guarantees, along with other things. To this question here, some of the things that accelerate full stack development: 1. Automatically updates your UI when DB data changes, not just on a per-document one-off subscription, but based on a whole server function's execution which is deterministic and cached. And regardless if the changes were made in the current browser tab or by a different user elsewhere. Not having to remember all the places to force refresh when a user updates their profile name, e.g., makes it way faster. And not only do the Convex client react hooks fire on data changes, the data they return for a page render is all from the same logical timestamp. You don't have to worry about one part of the UI saying that payment is pending when another says it's been paid. 2. End-to-end types without codegen. When you define a server function, you define the argument validators, which immediately show up on the types for calling it from the frontend. You can iterate on your backend function and frontend types side-by-side without redefining types or codegen in the loop. 3. Automatic retries for database conflicts, as well as retries for mutations fired from the client. B/c mutations are deterministic and side-effect-free (other than transactional changes to the DB and scheduler), the client can keep retrying them and guarantee exactly-once execution. And if your mutation had DB conflicts, it's automatically retried (up to a limit with backoff). So the client can submit operations without worrying about how to recover on conflict. There's obv. a bunch more in the article about features like text search and other things out of the box, but those maybe are more conveniences on the backend, since maybe a frontend person wouldn't have been setting up Algolia, etc.
- cetra3 2y ago
  "Really cool" is not compelling enough for me to decide to build a product against something like this. Here is, at a minimum, I would require to even consider: - Comparisons against other types of stacks, like laravel livewire or phoenix liveview - Performance metrics/stats/benchmarks whatever. You need to be faster and more robust than the other things out there, or provide some other benefit - First Class self-hosted on premise install version without dependency on any cloud provider. Kubernetes helm charts or docker compose stacks or whatever - I do actually like that you have a time-windowed source available license. That is something that alleviates the concern if you go under - Jepsen or similar analysis, need to make sure whatever consistency guarantees you are advertising hold up
  - ianhmacartney 2y ago
    One public comparison on latency is https://db-latency.vercel.app/ https://db-latency.vercel.app/ For comparisons, you can check out: https://stack.convex.dev/convex-vs-firebase https://stack.convex.dev/convex-vs-firebase https://stack.convex.dev/convex-vs-relational-databases https://stack.convex.dev/convex-vs-relational-databases https://www.convex.dev/compare/supabase https://www.convex.dev/compare/supabase https://www.convex.dev/compare/mongodb https://www.convex.dev/compare/mongodb I'll save you more of a marketing pitch, since you seem to have enough of my pitching Convex in the article:) The bullet points at the bottom of the article should be a pretty concise list - I'd call out the reactivity / subscriptions / caching. To learn how all that magic works, check out https://stack.convex.dev/how-convex-works https://stack.convex.dev/how-convex-works
- yard2010 2y ago
  Remix is really cool too! On the paper
sujayakar 2y ago
note that convex is open source! https://github.com/get-convex/convex-backend https://github.com/get-convex/convex-backend if you don't want to manage your own infrastructure, you can use our hosted product, but otherwise it's totally fine to self-host the open source binary. (convex cofounder here)

Swizec 2y ago

We can't solve this problem until we at least agree what "full-stack" even means. Right now you have many frontend-focused engineers who justifyably argue that something like React Server Components is a backend concern because it runs on the server. I think they're wrong but they have a point. You also have many backend-focused engineers who justifyably argue that something like Rails is a frontend concern because it's designed to run webpages. You probably wouldn't want to use Rails to build an ETL pipeline or an airline scheduling system, for example. I think they're kinda right but also a little bit wrong. And ultimately the whole debate is so deep in the It Depends territory that I honestly think 90% of the people arguing come from such vastly different backgrounds and situations that they're just talking past each other. They're never going to agree because the problems they're solving are too different to ever have the same solution. edit: I say this as someone with professional experience in almost all the usual suspects (Django, Rails, Flask, various JavaScript frankenstacks, even PHP).

ianhmacartney 2y ago
Very much agree. The tools for various jobs differ widely. However, my current take is that full-stack is more about enablement of engineers vs. a specific product or technology. Things at the protocol level (ProtoBuf, OpenAPI specs, etc.), things at the framework level (fancy types with tRPC or Convex), things at the application level (dropping in full stack features by someone without deep expertise in both domains) all qualify in my book. And rather than a discrete "you are now a full-stack dev, my child" moment, it's about blurring the line, the same way that k8s lets some backend folks play SRE here & there. Background. My career has spanned these in different ways: Front-end: I started in iOS in 2010 (back then it wasn't called iOS yet - just iPhone), where I was a more pure frontend dev. The server was using python and Haskell and that team was the "cool kids" in my view. The backend/frontend contract was using ProtBuf over a socket (not WebSocket, which hadn't been standardized yet), so we really didn't work closely together, and no one was "full-stack". Backend: Wanting to be a "cool kid" I joined Dropbox and eventually was the technical lead for Dropbox Previews, generating video, pdfs, images for user content using hundreds of machines, using a combo of Go and Python. I didn't work very closely with the myriad of teams using the previews for various products (their interface was the HTTP endpoints we exposed). One fun statistic: if you removed the cache and processed the full file for every user’s request, it would amount to processing over one exabyte of data per day. "Full-stack" tbh my experience crossing the gap is only somewhat recent (last 5 years or so) where I did freelance / contracting for various startups and established companies. I brushed up on React, learned TypeScript, but still mostly focused on backends - which usually ended up overly robust for the level of operational expertise of the companies I was handing the projects off to: like handing off a full kubernetes setup for running some GPU machines and orchestrating some fan-in / fan-out pipelines for ML image processing, when I'm sure there were mostly-fine ML workflow companies I could have used. Anyways this was much longer than anticipated but hope it adds some color

austin-cheney 2y ago

The full stack web is a fallacy because it exposes how much the developers involved cannot program, at least in this context. As a former JavaScript developer most of the people doing that work cannot program. That is why frameworks are so essential. What percentage of these people could realistically do any fraction of their jobs without third party abstractions line React or jQuery? It’s striking. Look, what’s the primary mission here: 1. Put text on screen 2. Handle user events Why is that so hard? Because nobody knows what they are doing, the blind leading the blind. The compile target on the front end is the DOM and that absolutely scares the shit out of people. Secondly, communicating outside the browser requires network traffic handling which also scared the shit out of people. Finally any kind of event handling requires an understanding of the event loop and listeners and that also scares the shit out of people. Finally, most people cannot write in JavaScript. Instead they write Java (or whatever) and modify the syntax just enough to avoid critical run time failures. The blessings of a lexical first functional environment are often absent because the language is a mystery. Fucking horrible mess. None of this is challenging. It’s stupid easy to learn, but there is almost nobody willing to teach it. The insecurity in that line of work is so universal I refuse to go back to that line of work for less than $500,000 salary.

megadal 2y ago
This sounds a lot like gatekeeping to me. It's not that you can't build a website without a framework, its that at the end of the day, no one cares what tools you use (in front end), it's how fast you get the job done, does it look like the mock up, and does it function. No one cares if the site is written in vanilla JS vs. a framework except a certain segment of HN web purists.
- austin-cheney 2y ago
  80% agree. That is immediately true when only talking about code, but then absolutely everyone bitches about how shitty the result is (big, slow, brittle, and so on). People do care enough to complain, even non technical people. Worse than that people who do that work also bitch about how shitty the results are too, but then continue writing garbage because that’s the best they can do.