<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>berkes</author><text>Even worse: Client-side validation and server-side validation (and database integrity validation) are all their own domains! I call all of these &amp;quot;domain logic&amp;quot; or domain validation just to be sure.&lt;p&gt;Yes, they overlap. Sure, you&amp;#x27;ll need some repetition and maybe, indeed, some DSL or tooling to share some of the overlapping ones across the boundaries.&lt;p&gt;But no! They are not the same. A &amp;quot;this email is already in use&amp;quot; is serverside, (it depends on the case). A &amp;quot;this doesn&amp;#x27;t look like an email-address, did you mean gmail.com instead of gamil.com&amp;quot; is client side and a &amp;quot;unique-key-constraint: contactemail already used&amp;quot; is even more down.&lt;p&gt;My point is, that the more you sit down (with customers! domain experts!) and talk or think all this through, the less it&amp;#x27;s a technical problem that has to be solved with DSLs, SPAs, MPAs or &amp;quot;same language for backend and UI&amp;quot;. And the more you (I) realize it really often hardly matters.&lt;p&gt;You quite probably don&amp;#x27;t even need that email-uniqueness validation at all. In any layer. If you just care to speak to the business.</text><parent_chain><item><author>PaulHoule</author><text>I remember that all the web shops in my town that did Ruby on Rails sites efficiently felt they had to switch to Angular about the same time and they never regained their footing in the Angular age although it seems they can finally get things sorta kinda done with React.&lt;p&gt;Client-side validation is used as an excuse for React but we were doing client-side validation in 1999 with plain ordinary Javascript.  If the real problem was “not write the validation code twice” surely the answer would have been some kind of DSL that code-generated or interpreted the validation rules for the back end and front end,  not the fantastically complex Rube Goldberg machine of the modern Javascript wait wait wait wait and wait some more to build machine and then users wait wait wait wait wait for React and 60,000 files worth of library code to load and then wait wait wait wait even more for completely inscrutable reasons later on.  (e.g. amazing how long you have to wait for Windows to delete the files in your node_modules directory)</text></item><item><author>obpe</author><text>It&amp;#x27;s kinda funny to me that many of the &amp;quot;pros&amp;quot; of this approach are the exact reasons so many abandoned MPAs in the first place.&lt;p&gt;For instance, a major selling point of Node was running JS on both the client and server so you can write the code once. It&amp;#x27;s a pretty shitty client experience if you have to do a network request for each and every validation of user input.&lt;p&gt;Also, there was a push to move the shitty code from the server to the client to free up server resources and prevent your servers from ruining the experience for everyone.&lt;p&gt;We moved away for MPAs because they were bloated, slow and difficult to work with. SPAs have definitely become what they sought to replace.&lt;p&gt;But that isn&amp;#x27;t because of the technology, it&amp;#x27;s because all the devs writing shitty MPAs are now writing shitty SPAs. If this becomes popular, they will start writing shitty MPAs again. Nothing about this technology will stop that.</text></item></parent_chain></comment><story><title>Htmx Is the Future</title><url>https://quii.dev/HTMX_is_the_Future</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>ratorx</author><text>Or even skip the DSL and use JS for both client and server, just independently. Validation functions can&amp;#x2F;should be simple, pure JS that can be imported from both.</text><parent_chain><item><author>PaulHoule</author><text>I remember that all the web shops in my town that did Ruby on Rails sites efficiently felt they had to switch to Angular about the same time and they never regained their footing in the Angular age although it seems they can finally get things sorta kinda done with React.&lt;p&gt;Client-side validation is used as an excuse for React but we were doing client-side validation in 1999 with plain ordinary Javascript.  If the real problem was “not write the validation code twice” surely the answer would have been some kind of DSL that code-generated or interpreted the validation rules for the back end and front end,  not the fantastically complex Rube Goldberg machine of the modern Javascript wait wait wait wait and wait some more to build machine and then users wait wait wait wait wait for React and 60,000 files worth of library code to load and then wait wait wait wait even more for completely inscrutable reasons later on.  (e.g. amazing how long you have to wait for Windows to delete the files in your node_modules directory)</text></item><item><author>obpe</author><text>It&amp;#x27;s kinda funny to me that many of the &amp;quot;pros&amp;quot; of this approach are the exact reasons so many abandoned MPAs in the first place.&lt;p&gt;For instance, a major selling point of Node was running JS on both the client and server so you can write the code once. It&amp;#x27;s a pretty shitty client experience if you have to do a network request for each and every validation of user input.&lt;p&gt;Also, there was a push to move the shitty code from the server to the client to free up server resources and prevent your servers from ruining the experience for everyone.&lt;p&gt;We moved away for MPAs because they were bloated, slow and difficult to work with. SPAs have definitely become what they sought to replace.&lt;p&gt;But that isn&amp;#x27;t because of the technology, it&amp;#x27;s because all the devs writing shitty MPAs are now writing shitty SPAs. If this becomes popular, they will start writing shitty MPAs again. Nothing about this technology will stop that.</text></item></parent_chain></comment><story><title>Htmx Is the Future</title><url>https://quii.dev/HTMX_is_the_Future</url></story>