5 ms·

I think that this comment is a great example of the total disconnect these conversations always have. On the one hand we have lots of people on here who are bu

I think that this comment is a great example of the total disconnect these conversations always have. On the one hand we have lots of people on here who are building full-featured web apps, not websites, on teams of 30+. These people look at frameworkless options and immediately have a dozen different questions about how your frameworkless design handles a dozen different features that their use case absolutely requires, and the answer is that it doesn't handle those features because it doesn't require them because it's a blog. Meanwhile there are also a lot of people on here who have never worked on a large-scale web app and wonder why frameworks even exist when it's so obviously easy to build a blog without them. It would be nice if we could just agree that the web hosts an enormous spectrum of different kinds of software and make it clear what kind of software we're talking about when we were opining about frameworks—whether for or against. In this case: this is a WordPress blog.

dorfsmay 1y ago
On the third hand, some people use React and some framework to write static web page...
- lolinder 1y ago
  And if you can point me to an example of that I will happily lampoon them. If we're talking about Medium, then yes, Medium is a complete disaster zone that should not be emulated anywhere. Their reader-facing use case does not require JavaScript at all except as a light optional seasoning on top. All I'm saying is that we need to actually talk about use cases whenever we're talking about frameworks, which we almost never do. Failing to specify the use cases turns the conversation incoherent because we end up having two different conversations without even realizing it.
  - austin-cheney 1y ago
    The primary use case for these large frameworks is hiring.
- emseetech 1y ago
  Not just some people. There are a wildly unnecessary amount of marketing pages and pages with basic forms that are built using React. Every time I've been at a company and suggested moving to vanilla css+html or a static generator, the reaction is like I brought up rewriting in assembly. There needs to be a significant push for simplification of the default toolchain. I understand using React, but reaching for it by default at the beginning should be seen as unnecessary complication. Especially because it's 100x easier to move from html+css to a framework than it is to move from a framework to literally anything else.
  - sanderjd 1y ago
    There is significant path dependency in either direction. A sibling comment to yours described it very well. There really isn't a good substitute for understanding early on whether you're going to be making a website or an application.
    - emseetech 1y ago
      Until you have a definitive answer, err on the side of simplicity.
      - tomnipotent 1y ago
        You err on the side of what's best for your business given known constraints. Usually frameworks make teams more productive, and that's worth more than "simplicity", whatever that means to you.
      - sanderjd 1y ago
        You never have a definitive answer. It's always probabilistic. You make the decision that you think has the highest odds of success at every point in time.
        emseetech 1y ago
        Success for the current requirements? Or success for an imagined future?
- dismalaf 1y ago
  There's a shocking amount of people who don't know that vanilla JS is a thing... They only know React...
  - llbbdd 1y ago
    haven't observed this at all
    - evbogue 1y ago
      It's mostly younger people
atoav 1y ago
Maybe there is this disconnect, but half of the react developers I personally met used react: "because it is good on resumes and I don't understand how to work without a framework". So I am not entirely sure we have the whole picture here. I also write more complex webapps using vanilla webtech (with a strong server-side solution like flask, django or similar). I checked out react it just hasn't clicked yet for me in combination with my serverside style.
Swizec 1y ago
I work on a site that was built without frameworks with just a sprinkle of jQuery on top of a traditional MVC framework. It worked great but then the business grew and the software became bigger than what fits in 1 engineer’s head. We now have lots of issues that need fixing. A good example are pages that take 5 seconds to load because they have to do so much, then you submit a form, and the page reload takes 5 seconds to go through but there is no UI feedback so you press the button a few more times because maybe it didn’t work? Then you get an error because the first action worked but the subsequent actions failed due to uniqueness constraints. Now as a user you’re confused: did you place the order or not? You got an error but the order also showed up in your history. Hmmm As engineers we have issues understanding what is and isn’t in scope. Will this javascript file you touched affect only the feature you wanted, or another 50 pages you didn’t even know about? When you add a new thing in a template, how many N+1 issues across how many pages did you just cause? Where does the data even get loaded?? The query lives so far away from where you use the data that it’s really hard to track down. Etc We started putting new things in React, especially the more interactive areas of the site. It’s pretty nice in comparison. Not perfect, but the framework pushing you to think in components helps a lot. I’m slowly introducing this mentality to other parts but the framework really wants to fight you on it so it’s gonna take a while.
- sanderjd 1y ago
  Nailed it. And a lot of people who say "this sounds like an application, let's pick an application framework to use" from the start are people who have experienced what you're currently experiencing. But it's very hard to describe in a compelling way to someone who has never had the same experience.
  - Swizec 1y ago
    Oh I was hired because I’ve been here before and know what to do. It’s fast becoming a career specialty lol
  - arkh 1y ago
    But the "looks like not an app, maybe we should not use an application framework" tends to be silenced by "React bootcamp people are a dime a dozen so let's use what they know".
a4isms 1y ago
Many years ago—2002!—Joel Spolsky wrote this: https://www.joelonsoftware.com/2002/05/06/five-worlds/ https://www.joelonsoftware.com/2002/05/06/five-worlds/ His thesis was that before arguing about software development tools, practices, anything really, it's vital to establish what kind of development you're doing, because each "world" has its own requirements that in turn motivate different practices and tools. The worlds he quoted were Shrink-wrap; Internal; Embedded; Games; and Throwaway. Shrink-wrap is no longer a thing for most developers, and we can probably name some others today that didn't exist then. But the basic advice he gave then matches what you're saying today: We need to anchor arguments about tooling in a statement about the type of development we're trying to address, and we need to appreciate that the needs of each world are different.
- sisve 1y ago
  100% this. The biggest problem I see is understanding the context of what you are building. Even inside a SaaS company. Are you building a feature that is a core part of the service or just a test shot to see if its possible to sell,or maybe you already sold something to a customer that is not your target customer. Yhey still need it and should get it. But maybe its more important to be quick and dirty. if its a core part, Then you need to make sure the architecture is good and maybe even add more test then normal. Context matter so much
- kalaksi 1y ago
  This is also why it's often frustrating to try to understand people's opinions regarding programming and code. There's almost always too little context, even without handwavy or subjective stuff like "it's too complex" or general bandwagoning. Actually, I feel like many times the conversations about code are pretty shallow anyway with not much info. Maybe it's just difficult without properly established context but OTOH that can quickly get complicated and require a lot more effort.
- 90s_dev 1y ago
  That was one of the most interesting reads I've read in a while, thanks.
wim 1y ago
We're building a collaborative IDE for tasks and notes [1] from scratch without frameworks/dependencies. Not saying frameworks are never the right answer of course, but it's as much a trade-off for complex apps as it is for blogs. Things like performance, bundle size, tooling complexity, easy of debugging and call stack depth, API stability, risk of hitting hard-to-work-around constraints all matter at scale too. [1] https://thymer.com/ https://thymer.com/
- lolinder 1y ago
  Agreed that it's a trade-off. In your case I probably would have made the same call. Again, though: that's why use cases matter. Web app/blog is only one dichotomy—the most common two types of web dev but far from the only.
- ismi 1y ago
  I love it! All ES6, no deps.. probably makes your lives harder than they should be but in the name of pureness and badassery and complete control over performance, awesome! You choose to suffer for the right reasons. Wishing you the best of luck and that I can try it soon. Forgot to say.. I very much admire and appreciate the aspect of "ejectability". More software should strive for this ideal. https://thymer.com/ejectable-apps https://thymer.com/ejectable-apps I read that and nod all the way through. Hope you succeed!
donohoe 1y ago
I think that this comment is a great example of the total disconnect these conversations always have. I just pointed out that frameworks are not always necessary. >> In this case: this is a WordPress blog. No. It is not a "blog". It's a news site. It uses WP as a CMS. That does not make it a blog, and comes across as nothing more than an attempt to belittle it. The New Yorker, with its 90 year archive (at the time) was run on WP too for a time. Its used by many major publishers. If you look at other news sites, be it NYTimes, Polygon, Verge, Wired, etc, most of them use frameworks to some degree. React, preact, svelte, whatever. It works for them. Underscore, and Backbone are two frameworks that were developed at the NYTimes. Its not alway necessary, and you can still do a lot without them.
- lolinder 1y ago
  It's not an attempt to belittle it at all, but as far as I know a news site and a blog have the same feature requirements—the main difference that I'm aware of is that a news site has more traffic and more articles and so may need better caching. If you're aware of requirements that a news site has that a blog doesn't (and I assume you would be, as the OP and creator of the above site), I'd love to hear it.
  - a4isms 1y ago
    Blogs and news sites are both in the "content publishing" space, so yes their requirements will overlap. There's likely a complexity continuum from: 1. Something like a one-person blog published by committing Markdown to a GitHub repository and having that published automatically, all the way to; 2. A journalistic news site that has a full CMS back-end tracking multiple authors/bylines, some kind of editor/approval/review workflow, features for deciding what gets shown "above the fold," linters that enforce style guidelines, specialized search features, &c. While some blogs can have complex requirements and some news sites might be simple, I hope we can appreciate that there will be some blogs that are much, much simpler than the NYT and this have fewer and simpler requirements. They're both "publishing words," but the back-end complexity reflects the complexity of the business -processes and model more than the complexity of displaying articles on web pages.
coldtea 1y ago
>that their use case absolutely requires This is where those people and teams are wrong.
- lolinder 1y ago
  Ah, you're right, I forgot a category: The people who will shamelessly dismiss other people's work and assert that they could do it better no matter how much context you share. This group is particularly fond of leaving dismissive comments without any substance. Dogma is a hell of a drug.
  - slater 1y ago
    > Ah, you're right, I forgot a category: The people who will shamelessly dismiss other people's work > In this case: this is a WordPress blog.
    - lolinder 1y ago
      If you assign a value judgement to that statement that's on you, not me. I was just providing the missing context: why OP didn't need a frontend framework to meet their requirements.
      - slater 1y ago
        Well, at least you found your category.
tayo42 1y ago
I feel this about just about every k8s discussion that comes up. I kind think that if your discussing tech about the web you need to include the scale and your experience.
sanderjd 1y ago
Sites vs. applications. It's important to know which you're building.
aucisson_masque 1y ago
> how your frameworkless design handles a dozen different features that their use case absolutely requires Would you mind sharing one or two kind of feature that are required by these development team ?
- lolinder 1y ago
  I could, but it would be a distraction because my entire point is that there are an enormous variety of apps with a large variety of requirements being deployed on the web. If I give examples that's going to turn into an argument over whether these specific examples actually need a framework, which will turn into a whole bunch of other hypotheticals of situations that would justify it or situations that won't. Rather than opening up that can of worms I'm going to leave it where I left it.
  - aucisson_masque 1y ago
    Holy moly, that's pretentious. I was genuinely curious because i never faced the kind of issue a web development team would have, it wasn't about counter argumenting. You could have just said "x and y".
    - lolinder 1y ago
      I'm not trying to be pretentious, but wrangling an HN thread is hard and I don't have time to get into an argument about a bunch of different implementation details. Rather than just ignore your post I decided to respond explaining why I couldn't answer. The only valid short answer is what I said: that it really depends on the details and how they all work together. I truly can't give you features in isolation that won't be questionable, because the decision hinges on the whole combination of factors. Had I said "x and y" someone would have come along and argued that X and Y didn't call for a framework because Z. Me identifying the two points would have accomplished nothing and would actually have undermined my primary point of "it depends". Edit: btw, I just corrected the downvote on your original post with an upvote. Whoever did that probably assumed you were being belligerent, but that's not fair.
kybernetikos 1y ago
> On the one hand we have lots of people on here who are building full-featured web apps, not websites, on teams of 30+. Photopea is a full-featured web app, not website, written without frameworks by a single individual. It is absolutely possible to build feature rich applications without the framework du jour.
- lolinder 1y ago
  You missed the "teams of 30+" part. I believe that a single individual who's dedicated to it can absolutely build a lot of cool stuff without frameworks, but there's a reason why large teams working on complex software tend to settle on them. The only real viable alternative with a large team is a hand rolled framework, which isn't always worth the trade-off.
- ozim 1y ago
  Again failing to understand what parent wrote. Team of 30 people is not needed to write fully featured application. Team of 30 people is needed to build, run and maintain enterprise applications. Where you might need 24/7 support and such support requires at least 5 FTE, you might need features changed when 3 people go on 2 or 3 weeks vacations. Maybe that single person will come up with something better to do with their life so you need to have some people to take over. What parent comment was about, people make broad statements not understanding that world is much bigger place. Yea it is absolutely possible to build an app the way you describe but it doesn’t work for every app everywhere. The same of course using React/Angular doesn’t work for everything, everywhere.
- filchermcurr 1y ago
  I don't really have anything to add to the conversation at hand, but Photopea looks pretty cool. Thanks for sharing!
ozim 1y ago
Fully support the comment. Those kind of posts are the same as ORm vs plain SQL or Scrum vs whatever. Time wasting at best, misdirection of inexperienced at worst.
mickael-kerjean 1y ago
> it doesn't require them because it's a blog. A counter example is Filestash [1], a full fledge file manager that can open > 100 file (from parquet, arrow, geojson, shp, raw images, etc...). Since it got moved out of React, the app perform better by every single metric than the original one. While I agree there's no team of 30 behind it, so is tons of software with people blindly defaulting to React for the same reason than people choose IBM: nobody get fired for choosing IBM / React. [1] https://github.com/mickael-kerjean/filestash https://github.com/mickael-kerjean/filestash
- lolinder 1y ago
  You and a few others are missing the point, which means I probably failed to communicate super effectively. Counterexamples aren't really a thing here because my point isn't that you do or don't need a framework for any specific kind of project, my point is that requirements vary and you can't talk framework vs frameworkless without talking requirements. A blog is just one example of a place where frameworks don't help, chosen because the site OP shared is functionally the same as a blog. Other applications have different requirements and those requirements may also not benefit from a framework. Alternatively, the requirements themselves may actually have benefited from a framework and the authors chose to avoid them because the team preferred not to or because they felt strongly about avoiding frameworks because of personal preference. In this case, this project has really one active contributor [0], so it's missing one of the key ingredients that in my experience really call for a framework: coordination between a large number of people. (And lest I be mistaken: just because a project has a large number of people does not mean a framework would for sure be the best choice. I'm sure there are counterexamples to that too! It's just a hint in that direction, not an ironclad law.) [0] https://github.com/mickael-kerjean/filestash/graphs/contributors https://github.com/mickael-kerjean/filestash/graphs/contribu...
  - BostonFern 1y ago
    > one of the key ingredients that in my experience really call for a framework: coordination between a large number of people Keep going, you might just end the whole debate in this thread.
andrewrn 1y ago
I like this framing the most. My personal website is vanilla, and my SPA-like apps are with React. I originally chose vanilla for my personal website bc I thought it'd keep refreshing my fundamentals... but actually its simple enough that vanilla is actually just the correct choice.
- deleted 1y ago
  [deleted]
chaboud 1y ago
Absolutely, and this sort of thing happens in large companies as well. Software engineers are great at providing “well, why don’t you just..” answers to problems they don’t actually have their brains wrapped around. This often leads to attempts to scale poorly scaling approaches (e.g., we’ll just bake every variant, since there are only four today - which becomes combinatorially intractable after a few years of development). On the flip side, software engineers are also great at choosing how they’re going to solve a problem before they really have a handle on what they’re going to solve. I use this maybe 5-10 times per year (and several engineers I work with have taken to repeating it): “tell me what you’re doing but, more importantly, tell me what you’re not doing.” Forcing people to be explicit about what is not in scope helps to bring clarity to otherwise murky tangles of ambiguity.
eduction 1y ago
> It would be nice if we could just … make it clear what kind of software we're talking about when we were opining Irony here is that OP did precisely this with a link to the precise thing he built. Meanwhile you haven’t offered even a rough description of what you built, much less a link.
evantbyrne 1y ago
> I think that this comment is a great example of the total disconnect these conversations always have. If we're being fair, the same could be said of this comment, which goes on to make some assumptions. One guy giving an anecdote that is not a web app does not prove much. I've built award winning web apps with progressive enhancement. It takes less code, less time, the performance is better, and they can be just as interactive. We need to stop looking for the weaknesses in each other's arguments and look for their strengths. I'm guilty of this as well.
- lolinder 1y ago
  I think you're reading into my comment implications that I didn't intend to put there. The point is that situations differ and we need to be explicit about what kinds of situations we're talking about when we're sharing our opinions on the suitability of frameworks. I'm not advocating for or against frameworks in any particular situation.
  - evantbyrne 1y ago
    That seems like a good take to me

dorfsmay 1y ago

On the third hand, some people use React and some framework to write static web page...

lolinder 1y ago
And if you can point me to an example of that I will happily lampoon them. If we're talking about Medium, then yes, Medium is a complete disaster zone that should not be emulated anywhere. Their reader-facing use case does not require JavaScript at all except as a light optional seasoning on top. All I'm saying is that we need to actually talk about use cases whenever we're talking about frameworks, which we almost never do. Failing to specify the use cases turns the conversation incoherent because we end up having two different conversations without even realizing it.
- austin-cheney 1y ago
  The primary use case for these large frameworks is hiring.
emseetech 1y ago
Not just some people. There are a wildly unnecessary amount of marketing pages and pages with basic forms that are built using React. Every time I've been at a company and suggested moving to vanilla css+html or a static generator, the reaction is like I brought up rewriting in assembly. There needs to be a significant push for simplification of the default toolchain. I understand using React, but reaching for it by default at the beginning should be seen as unnecessary complication. Especially because it's 100x easier to move from html+css to a framework than it is to move from a framework to literally anything else.
- sanderjd 1y ago
  There is significant path dependency in either direction. A sibling comment to yours described it very well. There really isn't a good substitute for understanding early on whether you're going to be making a website or an application.
  - emseetech 1y ago
    Until you have a definitive answer, err on the side of simplicity.
    - tomnipotent 1y ago
      You err on the side of what's best for your business given known constraints. Usually frameworks make teams more productive, and that's worth more than "simplicity", whatever that means to you.
    - sanderjd 1y ago
      You never have a definitive answer. It's always probabilistic. You make the decision that you think has the highest odds of success at every point in time.
      - emseetech 1y ago
        Success for the current requirements? Or success for an imagined future?
dismalaf 1y ago
There's a shocking amount of people who don't know that vanilla JS is a thing... They only know React...
- llbbdd 1y ago
  haven't observed this at all
  - evbogue 1y ago
    It's mostly younger people

atoav 1y ago

Maybe there is this disconnect, but half of the react developers I personally met used react: "because it is good on resumes and I don't understand how to work without a framework". So I am not entirely sure we have the whole picture here. I also write more complex webapps using vanilla webtech (with a strong server-side solution like flask, django or similar). I checked out react it just hasn't clicked yet for me in combination with my serverside style.

Swizec 1y ago

I work on a site that was built without frameworks with just a sprinkle of jQuery on top of a traditional MVC framework. It worked great but then the business grew and the software became bigger than what fits in 1 engineer’s head. We now have lots of issues that need fixing. A good example are pages that take 5 seconds to load because they have to do so much, then you submit a form, and the page reload takes 5 seconds to go through but there is no UI feedback so you press the button a few more times because maybe it didn’t work? Then you get an error because the first action worked but the subsequent actions failed due to uniqueness constraints. Now as a user you’re confused: did you place the order or not? You got an error but the order also showed up in your history. Hmmm As engineers we have issues understanding what is and isn’t in scope. Will this javascript file you touched affect only the feature you wanted, or another 50 pages you didn’t even know about? When you add a new thing in a template, how many N+1 issues across how many pages did you just cause? Where does the data even get loaded?? The query lives so far away from where you use the data that it’s really hard to track down. Etc We started putting new things in React, especially the more interactive areas of the site. It’s pretty nice in comparison. Not perfect, but the framework pushing you to think in components helps a lot. I’m slowly introducing this mentality to other parts but the framework really wants to fight you on it so it’s gonna take a while.

sanderjd 1y ago
Nailed it. And a lot of people who say "this sounds like an application, let's pick an application framework to use" from the start are people who have experienced what you're currently experiencing. But it's very hard to describe in a compelling way to someone who has never had the same experience.
- Swizec 1y ago
  Oh I was hired because I’ve been here before and know what to do. It’s fast becoming a career specialty lol
- arkh 1y ago
  But the "looks like not an app, maybe we should not use an application framework" tends to be silenced by "React bootcamp people are a dime a dozen so let's use what they know".

a4isms 1y ago

Many years ago—2002!—Joel Spolsky wrote this: https://www.joelonsoftware.com/2002/05/06/five-worlds/ https://www.joelonsoftware.com/2002/05/06/five-worlds/ His thesis was that before arguing about software development tools, practices, anything really, it's vital to establish what kind of development you're doing, because each "world" has its own requirements that in turn motivate different practices and tools. The worlds he quoted were Shrink-wrap; Internal; Embedded; Games; and Throwaway. Shrink-wrap is no longer a thing for most developers, and we can probably name some others today that didn't exist then. But the basic advice he gave then matches what you're saying today: We need to anchor arguments about tooling in a statement about the type of development we're trying to address, and we need to appreciate that the needs of each world are different.

sisve 1y ago
100% this. The biggest problem I see is understanding the context of what you are building. Even inside a SaaS company. Are you building a feature that is a core part of the service or just a test shot to see if its possible to sell,or maybe you already sold something to a customer that is not your target customer. Yhey still need it and should get it. But maybe its more important to be quick and dirty. if its a core part, Then you need to make sure the architecture is good and maybe even add more test then normal. Context matter so much
kalaksi 1y ago
This is also why it's often frustrating to try to understand people's opinions regarding programming and code. There's almost always too little context, even without handwavy or subjective stuff like "it's too complex" or general bandwagoning. Actually, I feel like many times the conversations about code are pretty shallow anyway with not much info. Maybe it's just difficult without properly established context but OTOH that can quickly get complicated and require a lot more effort.
90s_dev 1y ago
That was one of the most interesting reads I've read in a while, thanks.

wim 1y ago

We're building a collaborative IDE for tasks and notes [1] from scratch without frameworks/dependencies. Not saying frameworks are never the right answer of course, but it's as much a trade-off for complex apps as it is for blogs. Things like performance, bundle size, tooling complexity, easy of debugging and call stack depth, API stability, risk of hitting hard-to-work-around constraints all matter at scale too. [1] https://thymer.com/ https://thymer.com/

lolinder 1y ago
Agreed that it's a trade-off. In your case I probably would have made the same call. Again, though: that's why use cases matter. Web app/blog is only one dichotomy—the most common two types of web dev but far from the only.
ismi 1y ago
I love it! All ES6, no deps.. probably makes your lives harder than they should be but in the name of pureness and badassery and complete control over performance, awesome! You choose to suffer for the right reasons. Wishing you the best of luck and that I can try it soon. Forgot to say.. I very much admire and appreciate the aspect of "ejectability". More software should strive for this ideal. https://thymer.com/ejectable-apps https://thymer.com/ejectable-apps I read that and nod all the way through. Hope you succeed!

donohoe 1y ago

I think that this comment is a great example of the total disconnect these conversations always have. I just pointed out that frameworks are not always necessary. >> In this case: this is a WordPress blog. No. It is not a "blog". It's a news site. It uses WP as a CMS. That does not make it a blog, and comes across as nothing more than an attempt to belittle it. The New Yorker, with its 90 year archive (at the time) was run on WP too for a time. Its used by many major publishers. If you look at other news sites, be it NYTimes, Polygon, Verge, Wired, etc, most of them use frameworks to some degree. React, preact, svelte, whatever. It works for them. Underscore, and Backbone are two frameworks that were developed at the NYTimes. Its not alway necessary, and you can still do a lot without them.

lolinder 1y ago
It's not an attempt to belittle it at all, but as far as I know a news site and a blog have the same feature requirements—the main difference that I'm aware of is that a news site has more traffic and more articles and so may need better caching. If you're aware of requirements that a news site has that a blog doesn't (and I assume you would be, as the OP and creator of the above site), I'd love to hear it.
- a4isms 1y ago
  Blogs and news sites are both in the "content publishing" space, so yes their requirements will overlap. There's likely a complexity continuum from: 1. Something like a one-person blog published by committing Markdown to a GitHub repository and having that published automatically, all the way to; 2. A journalistic news site that has a full CMS back-end tracking multiple authors/bylines, some kind of editor/approval/review workflow, features for deciding what gets shown "above the fold," linters that enforce style guidelines, specialized search features, &c. While some blogs can have complex requirements and some news sites might be simple, I hope we can appreciate that there will be some blogs that are much, much simpler than the NYT and this have fewer and simpler requirements. They're both "publishing words," but the back-end complexity reflects the complexity of the business -processes and model more than the complexity of displaying articles on web pages.

coldtea 1y ago

>that their use case absolutely requires This is where those people and teams are wrong.

lolinder 1y ago
Ah, you're right, I forgot a category: The people who will shamelessly dismiss other people's work and assert that they could do it better no matter how much context you share. This group is particularly fond of leaving dismissive comments without any substance. Dogma is a hell of a drug.
- slater 1y ago
  > Ah, you're right, I forgot a category: The people who will shamelessly dismiss other people's work > In this case: this is a WordPress blog.
  - lolinder 1y ago
    If you assign a value judgement to that statement that's on you, not me. I was just providing the missing context: why OP didn't need a frontend framework to meet their requirements.
    - slater 1y ago
      Well, at least you found your category.

tayo42 1y ago

I feel this about just about every k8s discussion that comes up. I kind think that if your discussing tech about the web you need to include the scale and your experience.

sanderjd 1y ago

Sites vs. applications. It's important to know which you're building.

aucisson_masque 1y ago

> how your frameworkless design handles a dozen different features that their use case absolutely requires Would you mind sharing one or two kind of feature that are required by these development team ?

lolinder 1y ago
I could, but it would be a distraction because my entire point is that there are an enormous variety of apps with a large variety of requirements being deployed on the web. If I give examples that's going to turn into an argument over whether these specific examples actually need a framework, which will turn into a whole bunch of other hypotheticals of situations that would justify it or situations that won't. Rather than opening up that can of worms I'm going to leave it where I left it.
- aucisson_masque 1y ago
  Holy moly, that's pretentious. I was genuinely curious because i never faced the kind of issue a web development team would have, it wasn't about counter argumenting. You could have just said "x and y".
  - lolinder 1y ago
    I'm not trying to be pretentious, but wrangling an HN thread is hard and I don't have time to get into an argument about a bunch of different implementation details. Rather than just ignore your post I decided to respond explaining why I couldn't answer. The only valid short answer is what I said: that it really depends on the details and how they all work together. I truly can't give you features in isolation that won't be questionable, because the decision hinges on the whole combination of factors. Had I said "x and y" someone would have come along and argued that X and Y didn't call for a framework because Z. Me identifying the two points would have accomplished nothing and would actually have undermined my primary point of "it depends". Edit: btw, I just corrected the downvote on your original post with an upvote. Whoever did that probably assumed you were being belligerent, but that's not fair.

kybernetikos 1y ago

> On the one hand we have lots of people on here who are building full-featured web apps, not websites, on teams of 30+. Photopea is a full-featured web app, not website, written without frameworks by a single individual. It is absolutely possible to build feature rich applications without the framework du jour.

lolinder 1y ago
You missed the "teams of 30+" part. I believe that a single individual who's dedicated to it can absolutely build a lot of cool stuff without frameworks, but there's a reason why large teams working on complex software tend to settle on them. The only real viable alternative with a large team is a hand rolled framework, which isn't always worth the trade-off.
ozim 1y ago
Again failing to understand what parent wrote. Team of 30 people is not needed to write fully featured application. Team of 30 people is needed to build, run and maintain enterprise applications. Where you might need 24/7 support and such support requires at least 5 FTE, you might need features changed when 3 people go on 2 or 3 weeks vacations. Maybe that single person will come up with something better to do with their life so you need to have some people to take over. What parent comment was about, people make broad statements not understanding that world is much bigger place. Yea it is absolutely possible to build an app the way you describe but it doesn’t work for every app everywhere. The same of course using React/Angular doesn’t work for everything, everywhere.
filchermcurr 1y ago
I don't really have anything to add to the conversation at hand, but Photopea looks pretty cool. Thanks for sharing!

ozim 1y ago

Fully support the comment. Those kind of posts are the same as ORm vs plain SQL or Scrum vs whatever. Time wasting at best, misdirection of inexperienced at worst.

mickael-kerjean 1y ago

> it doesn't require them because it's a blog. A counter example is Filestash [1], a full fledge file manager that can open > 100 file (from parquet, arrow, geojson, shp, raw images, etc...). Since it got moved out of React, the app perform better by every single metric than the original one. While I agree there's no team of 30 behind it, so is tons of software with people blindly defaulting to React for the same reason than people choose IBM: nobody get fired for choosing IBM / React. [1] https://github.com/mickael-kerjean/filestash https://github.com/mickael-kerjean/filestash

lolinder 1y ago
You and a few others are missing the point, which means I probably failed to communicate super effectively. Counterexamples aren't really a thing here because my point isn't that you do or don't need a framework for any specific kind of project, my point is that requirements vary and you can't talk framework vs frameworkless without talking requirements. A blog is just one example of a place where frameworks don't help, chosen because the site OP shared is functionally the same as a blog. Other applications have different requirements and those requirements may also not benefit from a framework. Alternatively, the requirements themselves may actually have benefited from a framework and the authors chose to avoid them because the team preferred not to or because they felt strongly about avoiding frameworks because of personal preference. In this case, this project has really one active contributor [0], so it's missing one of the key ingredients that in my experience really call for a framework: coordination between a large number of people. (And lest I be mistaken: just because a project has a large number of people does not mean a framework would for sure be the best choice. I'm sure there are counterexamples to that too! It's just a hint in that direction, not an ironclad law.) [0] https://github.com/mickael-kerjean/filestash/graphs/contributors https://github.com/mickael-kerjean/filestash/graphs/contribu...
- BostonFern 1y ago
  > one of the key ingredients that in my experience really call for a framework: coordination between a large number of people Keep going, you might just end the whole debate in this thread.

andrewrn 1y ago

I like this framing the most. My personal website is vanilla, and my SPA-like apps are with React. I originally chose vanilla for my personal website bc I thought it'd keep refreshing my fundamentals... but actually its simple enough that vanilla is actually just the correct choice.

deleted 1y ago
[deleted]

chaboud 1y ago

Absolutely, and this sort of thing happens in large companies as well. Software engineers are great at providing “well, why don’t you just..” answers to problems they don’t actually have their brains wrapped around. This often leads to attempts to scale poorly scaling approaches (e.g., we’ll just bake every variant, since there are only four today - which becomes combinatorially intractable after a few years of development). On the flip side, software engineers are also great at choosing how they’re going to solve a problem before they really have a handle on what they’re going to solve. I use this maybe 5-10 times per year (and several engineers I work with have taken to repeating it): “tell me what you’re doing but, more importantly, tell me what you’re not doing.” Forcing people to be explicit about what is not in scope helps to bring clarity to otherwise murky tangles of ambiguity.

eduction 1y ago

> It would be nice if we could just … make it clear what kind of software we're talking about when we were opining Irony here is that OP did precisely this with a link to the precise thing he built. Meanwhile you haven’t offered even a rough description of what you built, much less a link.

evantbyrne 1y ago

> I think that this comment is a great example of the total disconnect these conversations always have. If we're being fair, the same could be said of this comment, which goes on to make some assumptions. One guy giving an anecdote that is not a web app does not prove much. I've built award winning web apps with progressive enhancement. It takes less code, less time, the performance is better, and they can be just as interactive. We need to stop looking for the weaknesses in each other's arguments and look for their strengths. I'm guilty of this as well.

lolinder 1y ago
I think you're reading into my comment implications that I didn't intend to put there. The point is that situations differ and we need to be explicit about what kinds of situations we're talking about when we're sharing our opinions on the suitability of frameworks. I'm not advocating for or against frameworks in any particular situation.
- evantbyrne 1y ago
  That seems like a good take to me