4 ms·

I'm rather convinced at this point that all of these people chanting "Can we just go back to traditional approaches!" have never built a web app of reasonable c

I'm rather convinced at this point that all of these people chanting "Can we just go back to traditional approaches!" have never built a web app of reasonable complexity, never used something like React, or have some sort of combination of FOMO and/or comfort in their long-held approach. I don't have experience with all of these technologies but have been using React since its inception, and let me tell you, there is no amount of (reasonable) money that would make me want to go back to the times when jQuery the big new thing. It was awful! Procedurally manipulating the DOM! I mean, c'mon guys. Talk about a mess... Where are all of the FP evangelists when you need them? And I know someone out there is bound to downvote me and respond with something like, "B b b but that one site where it downloaded 300kB of JS for a landing page! It's such a bad user experience!". Sure. That's precisely what I'm talking about /s. The reality is that libraries like React are so popular because they make front-end web development not suck. You can actually reason about the behavior of your UI without first committing to memory a whole of bunch of procedural, ad-hoc `let el = document.getElementById('i-hate-myself')` nonsense. I get it. It makes web pages a bit slower, and sometimes (maybe more often than that) get abused. That isn't fun for anyone. But level the critique at the idiots downloading a MB of JS to power a single dropdown, not the tool managing that dropdown's state.

duxup 6y ago
I mentioned in another comment that I think HN's comments on front end type topics tends towards 'back end focused folks talking about front end'. That doesn't make them wrong when they say "hey this super simple site doesn't need to be in react" but at the same time it also misses the use case(s) for react and other frameworks when they rant on the topic more generally.
bern4444 6y ago
I totally agree. Using react is a breadth of fresh air for building web applications. If all you need is a static site landing page that changes once a year, sure use something else, plain ol html, css, and JS will do wonders. But when you want to build an entire application and experienece for consumers, React is exceptional. Web applications always have state and side effects, there's no escaping it. If you squint and tilt your head, ReactJS is like a pure function given the environment. React lets you model your view around your state and takes statefulness as a given and doesn't try to obfuscate it away. As you say, its far easier to leverage FP ideas in a react application. Most react components can be pure. State can be modeled with all the fun FP tools and ideas. At the end of the day, React clearly delineates the stateful from the stateless and lets you easily model both relative to each other in a ergonomic manner.
- bestinterest 6y ago
  The mental model of UI = f(state) is really beautiful. And I got it explained to me that its best to use an SPA when you have 'interrelated, dynamically updated state' from Tom MacWright and I very much agree. The issue I had with React is that it forced a lot of mental models and API's on you to achieve UI = f(state) but after finding Svelte and spending 20 mins on the tutorial [0] I feel like I can say I 'get it' when it comes to building web apps. Though the things you throw away when you decide to go all in on the SPA approach for your site is crazy, I hate not having access to my freaking database while building a page and having to create a ton of unnecessary code just to express a page that pulls in bits of data from my database. I do not want to complex myself with GraphQL. I much prefer the approach of dhh were we should only be paying that interactivity cost on the pages we need high fidelity on (which is probably going to be one or two pages you have for 80% of apps). I think Hotwire looks promising where you mostly have logical split up sections of html that you want to be independently rendered across the page or on a click. When it comes to communicating and weaving state between those I'd be thinking about Svelte if it starts getting too complex. Some examples of Hotwire I've seen so far https://twitter.com/tonysmdev/status/1355996616361205760 https://twitter.com/tonysmdev/status/1355996616361205760 https://twitter.com/tonysmdev/status/1356460628819533824 https://twitter.com/tonysmdev/status/1356460628819533824 [0] https://svelte.dev/tutorial/basics https://svelte.dev/tutorial/basics
andrei_says_ 6y ago
> The reality is that libraries like React are so popular because they make front-end web development not suck. You can actually reason about the behavior of your UI without first committing to memory a whole of bunch of procedural, ad-hoc `let el = document.getElementById('i-hate-myself')` nonsense. I think it’s a bit different - they are so popular mostly because of the massive crowds of front end devs cargo culting static websites into SPAs. And then maybe because of the many cases where they’re applied to replace jquery or a few js sprinkles with unnecessarily complicated SPAs. This is where stimulusjs + turbo or similar could solve the problem with 10% of the effort and complexity. Then, maybe in third place or further, because there are more cases for SPAs than 10 or so years ago.
- kingdomcome50 6y ago
  I agree that the cargo cult is real and abuse of the "SPA" paradigm has never been higher! But that is orthogonal to the tool. React does make front-end web dev not suck. It may not always be the right tool for end-users, but as a developer? C'mon. It's never been so ergonomic (and plain simple) to build a complex UI. I googled stimulusjs[0] and you know what? From a development perspective it looks like it sucks compared to React. I'd rather just write vanilla JS than that hot garbage. Is the bundle smaller? Didn't bother to look, probably. Is it faster? Didn't bother to look, hopefully. I get it! "Our job is to deliver value to the customer blah blah...". Engineering has costs as well. From training to velocity to, yeah I'll say it, developer happiness, you can't just ignore these costs. Working in a shitty, homegrown codebase using these niche libraries is a recipe for turnover. On the other hand, if you are just whipping a some simple pages here and there that probably don't need to be looked at ever again... go for it! Your future self will cringe a little bit when you open up the source to change something simple years down the line (I know I have!), but at least those interactions are fleeting. [0] I apologize for my crassness if you are somehow involved in the project.
  - andrei_says_ 6y ago
    > On the other hand, if you are just whipping a some simple pages here and there that probably don't need to be looked at ever again... go for it! Most interactions on the web are simple. Tools like Gatsby use react to generate static websites. I’m sorry but that’s just insane. The problem I’m speaking of is having a great slick well balanced hammer (react) which is a pleasure to work with and using it to put nails into (SPA-ize) everything in sight. I’m not involved with stimulusjs or Hotwire apart from using them to create SPA-like experiences without much time, effort, or agony. Basecamp use Hotwire for their cross platform hey email client - maybe take a look, it’s a pretty nice app.
bwindels 6y ago
> I'm rather convinced at this point that all of these people chanting "Can we just go back to traditional approaches!" have never built a web app of reasonable complexity, never used something like React, or have some sort of combination of FOMO and/or comfort in their long-held approach. I've got plenty of React & front-end experience and vastly prefer a thin library on top of the DOM than something like React, also for large applications. React is ok if all goes well, but when you have to debug or profile something, all the complexity behind the scenes occludes what you are looking for. Most of the time, people want JSX so you need a transpiler. Also keeping up with changes in new React releases seems like a lot of lost time. I've been building [1] without a transpiler and just a 600 lines template library (see [2]), and it has been such a breath of fresh air. The fact that there is so little code between you and the browser makes it very easy to see what is going on. Call stacks of max around 15 frames. It sounds like you are comparing React to jquery code without components, and I justed wanted to highlight that DOM APIs have evolved since those days, and that you don't need a library like React to structure your code. React has popularized good ideas in front-end development, like components, but I think the complexity cost of a virtual DOM is often underestimated. 1: https://github.com/vector-im/hydrogen-web/ https://github.com/vector-im/hydrogen-web/ 2: https://github.com/vector-im/hydrogen-web/blob/master/src/platform/web/ui/login/LoginView.js https://github.com/vector-im/hydrogen-web/blob/master/src/pl...
- kingdomcome50 6y ago
  I see this sentiment often, that React is too complex, and I just don't understand that criticism. Is there some bloat? I'm sure. But the problems that React solves aren't trivial either. The signature of a React application (and each component thereof) is simply `f(state) => HTML`. That isn't hard to understand, and the complexity behind the scenes is the complexity necessary to distill and optimize an application to the above. And to your point about JSX, yes, I do want that. I find it silly to write HTML using some other DSL. I have yet to find one that is anywhere near as transparent or ergonomic. How could there be? I suppose I can agree profiling for the cause of undesired cycles could be easier, but, frankly, I rarely need to do so because I can simply reason about why a function/component is being invoked. The "flow" of a React application is well-defined (and rather simple). To your last point about structuring your code, you are probably right. Things have come quite far since jQuery in many respects, and I am sure that, if I were to try my had at it again, I would find it to be much more sane than 5-6 years ago. I just don't see why anyone would subject themselves to that though... Kudos on your project! It looks great, and I'm sure provides the faculties important to you and your platform. I would be careful though. Given enough time and energy you may find, in the end, you have simply reinvented React!

duxup 6y ago

I mentioned in another comment that I think HN's comments on front end type topics tends towards 'back end focused folks talking about front end'. That doesn't make them wrong when they say "hey this super simple site doesn't need to be in react" but at the same time it also misses the use case(s) for react and other frameworks when they rant on the topic more generally.

bern4444 6y ago

I totally agree. Using react is a breadth of fresh air for building web applications. If all you need is a static site landing page that changes once a year, sure use something else, plain ol html, css, and JS will do wonders. But when you want to build an entire application and experienece for consumers, React is exceptional. Web applications always have state and side effects, there's no escaping it. If you squint and tilt your head, ReactJS is like a pure function given the environment. React lets you model your view around your state and takes statefulness as a given and doesn't try to obfuscate it away. As you say, its far easier to leverage FP ideas in a react application. Most react components can be pure. State can be modeled with all the fun FP tools and ideas. At the end of the day, React clearly delineates the stateful from the stateless and lets you easily model both relative to each other in a ergonomic manner.

bestinterest 6y ago
The mental model of UI = f(state) is really beautiful. And I got it explained to me that its best to use an SPA when you have 'interrelated, dynamically updated state' from Tom MacWright and I very much agree. The issue I had with React is that it forced a lot of mental models and API's on you to achieve UI = f(state) but after finding Svelte and spending 20 mins on the tutorial [0] I feel like I can say I 'get it' when it comes to building web apps. Though the things you throw away when you decide to go all in on the SPA approach for your site is crazy, I hate not having access to my freaking database while building a page and having to create a ton of unnecessary code just to express a page that pulls in bits of data from my database. I do not want to complex myself with GraphQL. I much prefer the approach of dhh were we should only be paying that interactivity cost on the pages we need high fidelity on (which is probably going to be one or two pages you have for 80% of apps). I think Hotwire looks promising where you mostly have logical split up sections of html that you want to be independently rendered across the page or on a click. When it comes to communicating and weaving state between those I'd be thinking about Svelte if it starts getting too complex. Some examples of Hotwire I've seen so far https://twitter.com/tonysmdev/status/1355996616361205760 https://twitter.com/tonysmdev/status/1355996616361205760 https://twitter.com/tonysmdev/status/1356460628819533824 https://twitter.com/tonysmdev/status/1356460628819533824 [0] https://svelte.dev/tutorial/basics https://svelte.dev/tutorial/basics

andrei_says_ 6y ago

> The reality is that libraries like React are so popular because they make front-end web development not suck. You can actually reason about the behavior of your UI without first committing to memory a whole of bunch of procedural, ad-hoc `let el = document.getElementById('i-hate-myself')` nonsense. I think it’s a bit different - they are so popular mostly because of the massive crowds of front end devs cargo culting static websites into SPAs. And then maybe because of the many cases where they’re applied to replace jquery or a few js sprinkles with unnecessarily complicated SPAs. This is where stimulusjs + turbo or similar could solve the problem with 10% of the effort and complexity. Then, maybe in third place or further, because there are more cases for SPAs than 10 or so years ago.

kingdomcome50 6y ago
I agree that the cargo cult is real and abuse of the "SPA" paradigm has never been higher! But that is orthogonal to the tool. React does make front-end web dev not suck. It may not always be the right tool for end-users, but as a developer? C'mon. It's never been so ergonomic (and plain simple) to build a complex UI. I googled stimulusjs[0] and you know what? From a development perspective it looks like it sucks compared to React. I'd rather just write vanilla JS than that hot garbage. Is the bundle smaller? Didn't bother to look, probably. Is it faster? Didn't bother to look, hopefully. I get it! "Our job is to deliver value to the customer blah blah...". Engineering has costs as well. From training to velocity to, yeah I'll say it, developer happiness, you can't just ignore these costs. Working in a shitty, homegrown codebase using these niche libraries is a recipe for turnover. On the other hand, if you are just whipping a some simple pages here and there that probably don't need to be looked at ever again... go for it! Your future self will cringe a little bit when you open up the source to change something simple years down the line (I know I have!), but at least those interactions are fleeting. [0] I apologize for my crassness if you are somehow involved in the project.
- andrei_says_ 6y ago
  > On the other hand, if you are just whipping a some simple pages here and there that probably don't need to be looked at ever again... go for it! Most interactions on the web are simple. Tools like Gatsby use react to generate static websites. I’m sorry but that’s just insane. The problem I’m speaking of is having a great slick well balanced hammer (react) which is a pleasure to work with and using it to put nails into (SPA-ize) everything in sight. I’m not involved with stimulusjs or Hotwire apart from using them to create SPA-like experiences without much time, effort, or agony. Basecamp use Hotwire for their cross platform hey email client - maybe take a look, it’s a pretty nice app.

bwindels 6y ago

> I'm rather convinced at this point that all of these people chanting "Can we just go back to traditional approaches!" have never built a web app of reasonable complexity, never used something like React, or have some sort of combination of FOMO and/or comfort in their long-held approach. I've got plenty of React & front-end experience and vastly prefer a thin library on top of the DOM than something like React, also for large applications. React is ok if all goes well, but when you have to debug or profile something, all the complexity behind the scenes occludes what you are looking for. Most of the time, people want JSX so you need a transpiler. Also keeping up with changes in new React releases seems like a lot of lost time. I've been building [1] without a transpiler and just a 600 lines template library (see [2]), and it has been such a breath of fresh air. The fact that there is so little code between you and the browser makes it very easy to see what is going on. Call stacks of max around 15 frames. It sounds like you are comparing React to jquery code without components, and I justed wanted to highlight that DOM APIs have evolved since those days, and that you don't need a library like React to structure your code. React has popularized good ideas in front-end development, like components, but I think the complexity cost of a virtual DOM is often underestimated. 1: https://github.com/vector-im/hydrogen-web/ https://github.com/vector-im/hydrogen-web/ 2: https://github.com/vector-im/hydrogen-web/blob/master/src/platform/web/ui/login/LoginView.js https://github.com/vector-im/hydrogen-web/blob/master/src/pl...

kingdomcome50 6y ago
I see this sentiment often, that React is too complex, and I just don't understand that criticism. Is there some bloat? I'm sure. But the problems that React solves aren't trivial either. The signature of a React application (and each component thereof) is simply `f(state) => HTML`. That isn't hard to understand, and the complexity behind the scenes is the complexity necessary to distill and optimize an application to the above. And to your point about JSX, yes, I do want that. I find it silly to write HTML using some other DSL. I have yet to find one that is anywhere near as transparent or ergonomic. How could there be? I suppose I can agree profiling for the cause of undesired cycles could be easier, but, frankly, I rarely need to do so because I can simply reason about why a function/component is being invoked. The "flow" of a React application is well-defined (and rather simple). To your last point about structuring your code, you are probably right. Things have come quite far since jQuery in many respects, and I am sure that, if I were to try my had at it again, I would find it to be much more sane than 5-6 years ago. I just don't see why anyone would subject themselves to that though... Kudos on your project! It looks great, and I'm sure provides the faculties important to you and your platform. I would be careful though. Given enough time and energy you may find, in the end, you have simply reinvented React!