10 ms·

If all you need is a couple of basic forms and some basic interaction, you can do it all with vanilla JS but let's not kid ourselves. This will not allow you to

by _pdp_ 4y ago

If all you need is a couple of basic forms and some basic interaction, you can do it all with vanilla JS but let's not kid ourselves. This will not allow you to build very rich apps without implementing a significant chunk of the frameworks you dislike so much. In fact, I would even say that if this is not a core part of your product, you are simply wasting time and resources. There is a huge amount of man-hours poured into making these frameworks work correctly under any condition.

youngtaff 4y ago
Jack builds Chrome DevTools, that's a really rich app and seems to work pretty well
otikik 4y ago
> of the frameworks you dislike so much This is totally uncalled for. He's not attacking you. He's explaining a tradeoff, very reasonably. > I would even say that if this is not a core part of your product, you are simply wasting time and resources. I find especially interesting that this phrase can be used to defend both sides of the argument. If you are building a highly rich application, chances are that using a framework for that is the right choice, agreed. But. Not all the apps being build out there need to be Very Rich Apps. There's indeed a lot of space for only-slightly-rich-but-mostly-static apps, despite the recent HN article. And for those, introducing a framework is ... precisely, a waste of time and resources.
- klodolph 4y ago
  > This is totally uncalled for. He's not attacking you. He's explaining a tradeoff, very reasonably. What? I don’t see how “dislike” would describe anything other than some kind of preference. I don’t see how it’s an attack.
- samhw 4y ago
  Their comment is perfectly reasonable and measured. I don't think anything in it is 'uncalled for'. Your own comment is a confusingly ironically ill-tempered response.
  - otikik 4y ago
    The phrase “The frameworks that you dislike so much” is not an argument. It’s a characterisation. It implies that the OP is blinded by his own personal preferences, and that his arguments have no weight because of that. Imagine if I had started my answer with “Since you love frameworks so much, then…”. That would have been a similar mischaracterisation on my part (equally uncalled for, since I don’t know the other person enough to make such judgement)
LAC-Tech 4y ago
I think react sits really well with some people, and with others it doesn't. For me I find I have to fight against the platform to separate presentation from behaviour. And let's not kid ourselves, a lot of react code bases do the classic winforms mistake of having an essentially code behind architecture.
- datavirtue 4y ago
  And why was that a mistake?
  - Sophistifunk 4y ago
    Because it was implemented via inheritance. Which is why the argument is BS, nobody does react like this. They specifically tell you not to do it, and I think there's a bunch of stuff in there to stop it from working.
  - LAC-Tech 4y ago
    IME marrying business logic so closely to presentation makes it very hard to change one without the other. Especially relevant for web apps, where you may want to re-use business logic for mobile apps, which becomes very difficult when they're tied to a react component. Also makes it harder to test. There's a great paper called "Naked Objects" which I'd recommend for anyone doing GUIs, but powerful idea I got from it is make your presentation code so immediately obvious from your business objects that you can practically generate it automatically.
    - mst 4y ago
      Pawson's Naked Objects thesis is absolutely brilliant. It proposes a complete approach of which not all of the parts will be useful for any given project, but it is -very- much worth reading even so.
      - LAC-Tech 4y ago
        Hey, someone else on the internet who knows about it! And yeah agreed, but I think we could all use some scantily clad objects at the very least.
deleted 4y ago
[deleted]
ricardobeat 4y ago
> If all you need is a couple of basic forms and some basic interaction, you can do it all with vanilla JS but let's not kid ourselves This is a classic red-herring argument from developers who have not built anything complex with vanilla js. You can build rich interactions with or without a framework, you’re just making different trade-offs (conventions, learning curve, flexibility, tooling). There is a much larger amount of man-hours put into browser APIs, and web components is one of them. I don’t see anything wrong or that warrants a “you’re wasting your time” warning in his argument. And note, he’s talking about the chrome dev tools everyone including the react team use daily, not “basic forms”.
- vlunkr 4y ago
  You call the argument a red herring, then name all the reasons people use a framework over vanilla js: conventions, learning curve, flexibility, tooling. Sure, the browser apis are great and always getting better, but I don't see how that's a reason not to use the framework.
  - bigpeopleareold 4y ago
    Conventions, learning curve, flexibility, tooling or just because that's what is there already and you have no decision either way :D
- nawgz 4y ago
  You’re arguing chrome dev tools were built with vanilla JS and didn’t require their own bespoke framework? That doesn’t track for me
- 5Qn8mNbc2FNCiVV 4y ago
  Using web components makes your forms instantly inaccessible without JS. Browser APIs evolved over time and albeit most are pretty good nowadays, a lot of stuff is still bad in HTML world and frameworks like these solve that painpoint. The framework still allows usage of FormData and whatnot, there's even a new framework ontop of React now that aims for form handling without any JS at all in the browser so there are good reasons to adapt them. And the fun part is that when you are going with the browser APIs like a responsible developers, do aim for backwards compatibility and browser support and all that jazz you will at some point also be annoyed to write a lot of imperative code to add a modal, add this field dynamically, handle class toggles and make another button somewhere change something else in the UI that it's inevitable that you write a poor-mans version of React that now no one knows how to maintain and onboard people. React didn't come from PHDs in some university, it came from the real needs and desires of developers to just think in "I want my UI to look like this, get it done" and not in "Aight, I add a class here now, but update the value here, this button also needs to be disabled now and then make the request and if it fails then add this element for the error in this spot and enable the button again but if it works yeah just throw all of these away and replace it with a success message"
louthy 4y ago
> There is a huge amount of man-hours poured into making these frameworks work correctly under any condition. The path is littered with the ghosts of frameworks past. Don't let the current efforts or trends convince you that we're done with this process. React will be a ghost one day.
- enlyth 4y ago
  That's like saying I should use a steam engine today because the electric motor will be superseded someday.
  - furyofantares 4y ago
    The way it played out with jQuery is that there was a transition period; gradually more and more classes of app didn't need to be built with jQuery and it was easier to build them without it. The implication was that we're in a transition like that presently.
  - wwweston 4y ago
    Or maybe it’s more like saying ICEs will be a ghost one day? EVs were once the path not taken…
  - louthy 4y ago
    I said no such thing.
    - xwdv 4y ago
      You implied it. What you should have alluded to is that it is necessary to use technologies today that won’t necessarily be in use in the future, merely as a stepping stone to get us to the next destination, where we will use a new but still temporary technology.
      - NegativeLatency 4y ago
        I think op was suggesting someday we’d be on hoverboard or something
akira2501 4y ago
> without implementing a significant chunk of the frameworks In my experience, it hasn't seemed all that significant. These frameworks are absurdly general and cover a range of use cases and deployment methods that most people don't use. I just need the kitchen sink, not everything else. So far, just using custom elements and a small wrapper around the <template> element, I've not been struggling to create the features I need or would otherwise miss.
- fiddlerwoaroof 4y ago
  Yeah, my experience is that people frequently overestimate the cost of building something for your needs and underestimate the integration cost of buying something. Also, the trend of hiring <framework> developers is a plague: if you know JavaScript and the DOM well, learning the basics of react is a couple afternoons of work and you can figure out the pitfalls via code review and learning on the job.
  - dgb23 4y ago
    That’s right, except I think it would take most people longer than an afternoon. There’s stuff that’s quite unique (and powerful) like useEffect and JSX takes a bit to get used to. But generally I wouldn’t be worried about onboarding a web dev who doesn’t know the lib, it’s not rocket science. One of the appealing things is how very straight forward and clear it is.
hirvi74 4y ago
> This will not allow you to build very rich apps without implementing a significant chunk of the frameworks you dislike so much I am currently working on an app at work that wants SPA functionality, but they won't let me use any of the frameworks. Tons of vanilla JS and Jquery. I am sure what I have written is probably considered a crime against humanity in some place. Does it work? Yes. Is it an elegant and maintainable codebase? Not by my definition.
- ng12 4y ago
  I feel you. I remember the old days of trying to build SPAs in jQuery and they were dark ones.
  - bshimmin 4y ago
    I actually have quite happy memories of working with Backbone and jQuery - there were obviously all manner of problems, but everything was quite easy to understand and a lot less magical. Apparently this was in 2012 - how time flies! - so I imagine rose-tinted spectacles must be in full effect here!
- bambataa 4y ago
  That raises an interesting question: what would be the declarative framework easiest to minimally reimplement? I’m thinking you could have a single file, jQuery-based, hand rolled version of some framework and get many of the benefits while still technically complying with the “no frameworks” rule. In the same way that you could reimplement Redux easily if you for some reason weren’t allowed to use it. I suspect diffing performance would be the bottleneck but I wonder if you could come up with some weird half solution that worked for your particular use case.
  - xigoi 4y ago
    https://zserge.com/posts/worst-react-ever/ https://zserge.com/posts/worst-react-ever/ https://zserge.com/posts/worst-vuejs-ever/ https://zserge.com/posts/worst-vuejs-ever/
  - 4y ago
BatteryMountain 4y ago
I've been down this path. I've built my own framework once out of frustration, thinking typescript will make it easy... after a while I realized that I was just rebuilding chunks of existing frameworks and most likely not in the best way. Webtech is really messy to begin with, typescript didn't really save me. So I stopped. Sure it was nice to know how to build your own viewstack, navigation and state management and how to some newer html5 features, but it really was not the way to go. Vue js seems to be closest match to the way my mind works and built a very crippled version of it minus all the good tooling and plugins. I was also influenced by Knockout and Wpf/C#, so it had some similarities of what I used to do in those. I honestly do not like the way react works or the way it wants me to work, it feels extremely messy too (syntax and project structure)! I get the same feeling from react that I got from own crappy framework! So anyone reading this, I encourage you to build your own frameworks, but think very carefully if you need it in production and can support it in the long term. Try to keep emotion/ego out of the decision.
- efdee 4y ago
  Maybe I'm misunderstanding your point, but React really doesn't dictate project structure at all.

by _pdp_ 4y ago

youngtaff 4y ago

Jack builds Chrome DevTools, that's a really rich app and seems to work pretty well

otikik 4y ago

> of the frameworks you dislike so much This is totally uncalled for. He's not attacking you. He's explaining a tradeoff, very reasonably. > I would even say that if this is not a core part of your product, you are simply wasting time and resources. I find especially interesting that this phrase can be used to defend both sides of the argument. If you are building a highly rich application, chances are that using a framework for that is the right choice, agreed. But. Not all the apps being build out there need to be Very Rich Apps. There's indeed a lot of space for only-slightly-rich-but-mostly-static apps, despite the recent HN article. And for those, introducing a framework is ... precisely, a waste of time and resources.

klodolph 4y ago
> This is totally uncalled for. He's not attacking you. He's explaining a tradeoff, very reasonably. What? I don’t see how “dislike” would describe anything other than some kind of preference. I don’t see how it’s an attack.
samhw 4y ago
Their comment is perfectly reasonable and measured. I don't think anything in it is 'uncalled for'. Your own comment is a confusingly ironically ill-tempered response.
- otikik 4y ago
  The phrase “The frameworks that you dislike so much” is not an argument. It’s a characterisation. It implies that the OP is blinded by his own personal preferences, and that his arguments have no weight because of that. Imagine if I had started my answer with “Since you love frameworks so much, then…”. That would have been a similar mischaracterisation on my part (equally uncalled for, since I don’t know the other person enough to make such judgement)

LAC-Tech 4y ago

I think react sits really well with some people, and with others it doesn't. For me I find I have to fight against the platform to separate presentation from behaviour. And let's not kid ourselves, a lot of react code bases do the classic winforms mistake of having an essentially code behind architecture.

datavirtue 4y ago
And why was that a mistake?
- Sophistifunk 4y ago
  Because it was implemented via inheritance. Which is why the argument is BS, nobody does react like this. They specifically tell you not to do it, and I think there's a bunch of stuff in there to stop it from working.
- LAC-Tech 4y ago
  IME marrying business logic so closely to presentation makes it very hard to change one without the other. Especially relevant for web apps, where you may want to re-use business logic for mobile apps, which becomes very difficult when they're tied to a react component. Also makes it harder to test. There's a great paper called "Naked Objects" which I'd recommend for anyone doing GUIs, but powerful idea I got from it is make your presentation code so immediately obvious from your business objects that you can practically generate it automatically.
  - mst 4y ago
    Pawson's Naked Objects thesis is absolutely brilliant. It proposes a complete approach of which not all of the parts will be useful for any given project, but it is -very- much worth reading even so.
    - LAC-Tech 4y ago
      Hey, someone else on the internet who knows about it! And yeah agreed, but I think we could all use some scantily clad objects at the very least.

deleted 4y ago

[deleted]

ricardobeat 4y ago

> If all you need is a couple of basic forms and some basic interaction, you can do it all with vanilla JS but let's not kid ourselves This is a classic red-herring argument from developers who have not built anything complex with vanilla js. You can build rich interactions with or without a framework, you’re just making different trade-offs (conventions, learning curve, flexibility, tooling). There is a much larger amount of man-hours put into browser APIs, and web components is one of them. I don’t see anything wrong or that warrants a “you’re wasting your time” warning in his argument. And note, he’s talking about the chrome dev tools everyone including the react team use daily, not “basic forms”.

vlunkr 4y ago
You call the argument a red herring, then name all the reasons people use a framework over vanilla js: conventions, learning curve, flexibility, tooling. Sure, the browser apis are great and always getting better, but I don't see how that's a reason not to use the framework.
- bigpeopleareold 4y ago
  Conventions, learning curve, flexibility, tooling or just because that's what is there already and you have no decision either way :D
nawgz 4y ago
You’re arguing chrome dev tools were built with vanilla JS and didn’t require their own bespoke framework? That doesn’t track for me
5Qn8mNbc2FNCiVV 4y ago
Using web components makes your forms instantly inaccessible without JS. Browser APIs evolved over time and albeit most are pretty good nowadays, a lot of stuff is still bad in HTML world and frameworks like these solve that painpoint. The framework still allows usage of FormData and whatnot, there's even a new framework ontop of React now that aims for form handling without any JS at all in the browser so there are good reasons to adapt them. And the fun part is that when you are going with the browser APIs like a responsible developers, do aim for backwards compatibility and browser support and all that jazz you will at some point also be annoyed to write a lot of imperative code to add a modal, add this field dynamically, handle class toggles and make another button somewhere change something else in the UI that it's inevitable that you write a poor-mans version of React that now no one knows how to maintain and onboard people. React didn't come from PHDs in some university, it came from the real needs and desires of developers to just think in "I want my UI to look like this, get it done" and not in "Aight, I add a class here now, but update the value here, this button also needs to be disabled now and then make the request and if it fails then add this element for the error in this spot and enable the button again but if it works yeah just throw all of these away and replace it with a success message"

louthy 4y ago

> There is a huge amount of man-hours poured into making these frameworks work correctly under any condition. The path is littered with the ghosts of frameworks past. Don't let the current efforts or trends convince you that we're done with this process. React will be a ghost one day.

enlyth 4y ago
That's like saying I should use a steam engine today because the electric motor will be superseded someday.
- furyofantares 4y ago
  The way it played out with jQuery is that there was a transition period; gradually more and more classes of app didn't need to be built with jQuery and it was easier to build them without it. The implication was that we're in a transition like that presently.
- wwweston 4y ago
  Or maybe it’s more like saying ICEs will be a ghost one day? EVs were once the path not taken…
- louthy 4y ago
  I said no such thing.
  - xwdv 4y ago
    You implied it. What you should have alluded to is that it is necessary to use technologies today that won’t necessarily be in use in the future, merely as a stepping stone to get us to the next destination, where we will use a new but still temporary technology.
    - NegativeLatency 4y ago
      I think op was suggesting someday we’d be on hoverboard or something

akira2501 4y ago

> without implementing a significant chunk of the frameworks In my experience, it hasn't seemed all that significant. These frameworks are absurdly general and cover a range of use cases and deployment methods that most people don't use. I just need the kitchen sink, not everything else. So far, just using custom elements and a small wrapper around the <template> element, I've not been struggling to create the features I need or would otherwise miss.

fiddlerwoaroof 4y ago
Yeah, my experience is that people frequently overestimate the cost of building something for your needs and underestimate the integration cost of buying something. Also, the trend of hiring <framework> developers is a plague: if you know JavaScript and the DOM well, learning the basics of react is a couple afternoons of work and you can figure out the pitfalls via code review and learning on the job.
- dgb23 4y ago
  That’s right, except I think it would take most people longer than an afternoon. There’s stuff that’s quite unique (and powerful) like useEffect and JSX takes a bit to get used to. But generally I wouldn’t be worried about onboarding a web dev who doesn’t know the lib, it’s not rocket science. One of the appealing things is how very straight forward and clear it is.

hirvi74 4y ago

> This will not allow you to build very rich apps without implementing a significant chunk of the frameworks you dislike so much I am currently working on an app at work that wants SPA functionality, but they won't let me use any of the frameworks. Tons of vanilla JS and Jquery. I am sure what I have written is probably considered a crime against humanity in some place. Does it work? Yes. Is it an elegant and maintainable codebase? Not by my definition.

ng12 4y ago
I feel you. I remember the old days of trying to build SPAs in jQuery and they were dark ones.
- bshimmin 4y ago
  I actually have quite happy memories of working with Backbone and jQuery - there were obviously all manner of problems, but everything was quite easy to understand and a lot less magical. Apparently this was in 2012 - how time flies! - so I imagine rose-tinted spectacles must be in full effect here!
bambataa 4y ago
That raises an interesting question: what would be the declarative framework easiest to minimally reimplement? I’m thinking you could have a single file, jQuery-based, hand rolled version of some framework and get many of the benefits while still technically complying with the “no frameworks” rule. In the same way that you could reimplement Redux easily if you for some reason weren’t allowed to use it. I suspect diffing performance would be the bottleneck but I wonder if you could come up with some weird half solution that worked for your particular use case.
- xigoi 4y ago
  https://zserge.com/posts/worst-react-ever/ https://zserge.com/posts/worst-react-ever/ https://zserge.com/posts/worst-vuejs-ever/ https://zserge.com/posts/worst-vuejs-ever/
- 4y ago

BatteryMountain 4y ago

I've been down this path. I've built my own framework once out of frustration, thinking typescript will make it easy... after a while I realized that I was just rebuilding chunks of existing frameworks and most likely not in the best way. Webtech is really messy to begin with, typescript didn't really save me. So I stopped. Sure it was nice to know how to build your own viewstack, navigation and state management and how to some newer html5 features, but it really was not the way to go. Vue js seems to be closest match to the way my mind works and built a very crippled version of it minus all the good tooling and plugins. I was also influenced by Knockout and Wpf/C#, so it had some similarities of what I used to do in those. I honestly do not like the way react works or the way it wants me to work, it feels extremely messy too (syntax and project structure)! I get the same feeling from react that I got from own crappy framework! So anyone reading this, I encourage you to build your own frameworks, but think very carefully if you need it in production and can support it in the long term. Try to keep emotion/ego out of the decision.

efdee 4y ago
Maybe I'm misunderstanding your point, but React really doesn't dictate project structure at all.