4 ms·

Strong disagree. Web Components are react in different clothing. You don’t need this component-based framework style architecture to write applications for the

Strong disagree. Web Components are react in different clothing. You don’t need this component-based framework style architecture to write applications for the browser. I promise writing applications for the browsers is not challenging. You don’t need big frameworks or component madness that’s more of the same.

daveidol 1y ago
Sure you can make a blog without a framework. But for complex applications it’s far better/easier than raw DOM manipulation or rolling your own thing.
- netbioserror 1y ago
  We should probably be making widget toolkits for the Canvas and using WebSockets for communication. DOM manipulation is a total hack-job. It's somewhat flexible, but the performance and dark-pattern cost is just too great. If you're making an interactive application, then treat it like an application and draw widgets to a canvas.
  - christophilus 1y ago
    Accessibility suffers with that approach.
    - extra88 1y ago
      It doesn't just suffer it's impossible unless you recreate the whole thing with actual HTML behind the <canvas> rendered version.
  - ioseph 1y ago
    This is an insane take, show me a responsive button with hover state and a tooltip implemented in the canvas that outperforms a button rendered with React.
    - rc1 1y ago
      Figma?
  - zelphirkalt 1y ago
    Don't forget about the privacy cost associated with the canvas. If this ever becomes widespread, we will have many many sites extract browser fingerprinting information from the canvas. It would then move the game one more step towards dystopia, where we have to analyze and block certain ways of code interacting with the canvas and it might even prove impossible. And then incapable web devs will offer you no solution but canvas buttons for the login to your bank account. No, I don't think this is the way forward.
- austin-cheney 1y ago
  I disagree. It’s actually the same effort either way, but one of those costs substantially more to maintain and performs far slower.
  - adastra22 1y ago
    It is not obvious to me which one you are talking about.
    - austin-cheney 1y ago
      The framework solution will end up costing more over the life of your application due to artificial restrictions, leaky abstractions, extra dependencies, performance decreases, and more code to maintain. In most cases all of those are acceptable if the developers are less comfortable making original architectural decisions. For me that comfort is achieved through reuse and audits around data structure types through use of TypeScript. Now that ThpeScript is natively supported in Node it’s even faster still because there is no need for a build or compile step. The code just runs as is. This is also even true for code that executes only in the browser so long as it’s imported into a node module, which I do anyway to reduce the number of file requests into the browser.
- zelphirkalt 1y ago
  Compare how many "complex applications" on the browser there are, with how many cargo culting blogs that employ react to render client side what could be static pages with text.
ahdanggit 1y ago
HARD AGREE! It just takes the minimal amount of discipline, and some conventions. I know it can be done because I did it, lots of people did it just a few years ago (some of those apps are STILL running today.)
onion2k 1y ago
You don’t need big frameworks or component madness that’s more of the same. You don't, but in any sufficiently complex app you'll end up writing a sort of 'mini framework' of your own as you abstract all the things that crop up more than a few times. That framework might be really nice at the start but it'll get more and more hacky as the project continues, especially if you're constrained by resources. Eventually you'll regret not using something standard. If there are more than a couple of developers on the project it'll be something no one really likes after a year or two. If there are more junior developers it'll be a reason for them to want to get off the team because they won't want to be a part of the 'old legacy code'. Then it'll be hard to find people who want to join. Eventually, as it gets harder to recruit people to the team because it's on a weird, legacy framework that no one knows, there'll be a big project to refactor it on to something more standard. That'll probably be React. At the same time most of the senior developers will be calling to scrap the codebase entirely and rebuild it (wrongly in almost every case, but they don't care and want a greenfield project to play with new things on.) This is a story that has played out at every large org that builds apps internally, and probably a lot of startups as they mature and need to hire more devs. You might as well skip all of it and use a standard framework from the start.
- austin-cheney 1y ago
  This has never been true for me. I never end up writing any kind of internal framework. Instead I write libraries that solve specific problems and achieve code reuse, which are really either functions or data storage objects restricted to their own files. At least, that’s how I think about code universally, libraries, but specifically in the browser this comes up less because the problem space is much smaller. Really in the browser it’s all about organizing code around event handling and putting text on screen. Let’s not over think this. Anyways this idea of internal frameworks has always been weird to me. Nobody says this of code outside the browser, so why would they say this inside the browser? When I think about in those terms this clearly becomes a simple organizational problem and I don’t need a framework telling me how to organize things like a parent telling me to do chores.
  - WA 1y ago
afavour 1y ago
> I promise writing applications for the browsers is not challenging. Yeah it is. I don’t like React but I’ve been doing this since the days of MooTools all the way through Backbone to the libraries we have today. Once your app reaches a certain size and/or reaches a critical mass of contributors it does get challenging and modern frameworks reduce that challenge. That can be taken way too far. Almost every time I’ve worked with Redux I’ve found it infuriatingly unnecessary. And React is far from the best framework out there. But it is a huge benefit all the same.
- austin-cheney 1y ago
  Modern frameworks, really components and an API, solve only two business problems: division of labor and training. Knowing that you can address these problems with continuous integration around a common set of rules and requirements. With regard to application size we fortunately now have TypeScript. All you really need to scale any application is types, functions, and code reuse.
WA 1y ago
React made reactivity popular. Web components don’t give you reactivity. You still tell the UI how to update based on state changes imperatively and that is annoying as hell. If you want reactivity in web components, you need a wrapper or another framework/small library.
- spankalee 1y ago
  There are plenty of web component helper libraries that give you reactivity. Reactivity is an implementation detail.

daveidol 1y ago

Sure you can make a blog without a framework. But for complex applications it’s far better/easier than raw DOM manipulation or rolling your own thing.

netbioserror 1y ago
We should probably be making widget toolkits for the Canvas and using WebSockets for communication. DOM manipulation is a total hack-job. It's somewhat flexible, but the performance and dark-pattern cost is just too great. If you're making an interactive application, then treat it like an application and draw widgets to a canvas.
- christophilus 1y ago
  Accessibility suffers with that approach.
  - extra88 1y ago
    It doesn't just suffer it's impossible unless you recreate the whole thing with actual HTML behind the <canvas> rendered version.
- ioseph 1y ago
  This is an insane take, show me a responsive button with hover state and a tooltip implemented in the canvas that outperforms a button rendered with React.
  - rc1 1y ago
    Figma?
- zelphirkalt 1y ago
  Don't forget about the privacy cost associated with the canvas. If this ever becomes widespread, we will have many many sites extract browser fingerprinting information from the canvas. It would then move the game one more step towards dystopia, where we have to analyze and block certain ways of code interacting with the canvas and it might even prove impossible. And then incapable web devs will offer you no solution but canvas buttons for the login to your bank account. No, I don't think this is the way forward.
austin-cheney 1y ago
I disagree. It’s actually the same effort either way, but one of those costs substantially more to maintain and performs far slower.
- adastra22 1y ago
  It is not obvious to me which one you are talking about.
  - austin-cheney 1y ago
    The framework solution will end up costing more over the life of your application due to artificial restrictions, leaky abstractions, extra dependencies, performance decreases, and more code to maintain. In most cases all of those are acceptable if the developers are less comfortable making original architectural decisions. For me that comfort is achieved through reuse and audits around data structure types through use of TypeScript. Now that ThpeScript is natively supported in Node it’s even faster still because there is no need for a build or compile step. The code just runs as is. This is also even true for code that executes only in the browser so long as it’s imported into a node module, which I do anyway to reduce the number of file requests into the browser.
zelphirkalt 1y ago
Compare how many "complex applications" on the browser there are, with how many cargo culting blogs that employ react to render client side what could be static pages with text.

ahdanggit 1y ago

HARD AGREE! It just takes the minimal amount of discipline, and some conventions. I know it can be done because I did it, lots of people did it just a few years ago (some of those apps are STILL running today.)

onion2k 1y ago

You don’t need big frameworks or component madness that’s more of the same. You don't, but in any sufficiently complex app you'll end up writing a sort of 'mini framework' of your own as you abstract all the things that crop up more than a few times. That framework might be really nice at the start but it'll get more and more hacky as the project continues, especially if you're constrained by resources. Eventually you'll regret not using something standard. If there are more than a couple of developers on the project it'll be something no one really likes after a year or two. If there are more junior developers it'll be a reason for them to want to get off the team because they won't want to be a part of the 'old legacy code'. Then it'll be hard to find people who want to join. Eventually, as it gets harder to recruit people to the team because it's on a weird, legacy framework that no one knows, there'll be a big project to refactor it on to something more standard. That'll probably be React. At the same time most of the senior developers will be calling to scrap the codebase entirely and rebuild it (wrongly in almost every case, but they don't care and want a greenfield project to play with new things on.) This is a story that has played out at every large org that builds apps internally, and probably a lot of startups as they mature and need to hire more devs. You might as well skip all of it and use a standard framework from the start.

austin-cheney 1y ago
This has never been true for me. I never end up writing any kind of internal framework. Instead I write libraries that solve specific problems and achieve code reuse, which are really either functions or data storage objects restricted to their own files. At least, that’s how I think about code universally, libraries, but specifically in the browser this comes up less because the problem space is much smaller. Really in the browser it’s all about organizing code around event handling and putting text on screen. Let’s not over think this. Anyways this idea of internal frameworks has always been weird to me. Nobody says this of code outside the browser, so why would they say this inside the browser? When I think about in those terms this clearly becomes a simple organizational problem and I don’t need a framework telling me how to organize things like a parent telling me to do chores.
- WA 1y ago

afavour 1y ago

> I promise writing applications for the browsers is not challenging. Yeah it is. I don’t like React but I’ve been doing this since the days of MooTools all the way through Backbone to the libraries we have today. Once your app reaches a certain size and/or reaches a critical mass of contributors it does get challenging and modern frameworks reduce that challenge. That can be taken way too far. Almost every time I’ve worked with Redux I’ve found it infuriatingly unnecessary. And React is far from the best framework out there. But it is a huge benefit all the same.

austin-cheney 1y ago
Modern frameworks, really components and an API, solve only two business problems: division of labor and training. Knowing that you can address these problems with continuous integration around a common set of rules and requirements. With regard to application size we fortunately now have TypeScript. All you really need to scale any application is types, functions, and code reuse.

WA 1y ago

React made reactivity popular. Web components don’t give you reactivity. You still tell the UI how to update based on state changes imperatively and that is annoying as hell. If you want reactivity in web components, you need a wrapper or another framework/small library.

spankalee 1y ago
There are plenty of web component helper libraries that give you reactivity. Reactivity is an implementation detail.