> a bit of javascript when it's needed for a form.
Until you get told to implement more reactive features, then it's over. Using Pure JS/JQuery for reactiveness is outright horrible.
Until you get told to implement more reactive features, then it's over. Using Pure JS/JQuery for reactiveness is outright horrible.
Turbolinks/hotwire? Not as easy with Go as with Ruby but can be done
You have to do validation on the server anyway. Why do it again on the front end?
(:
Sorry, those turn up as 'must have' features in like, meeting #2 with the product owner, because the UI feels old and rubbish without them.
Technically? You're 100% right.
...but, I guarantee that even a LOB app, this will turn up, again and again and again as a feature request, until it becomes a tier 1 priority.
Did the user forget to fill a mandatory field? Is this phone number actually even possible? Does this zip/postal code exist? Is the age entered too low to create an account? Is the password long enough? Does it meet all the requirements. Can we dynamically show which requirements it doesn’t meet.
Even email, which you will want to verify by actually sending an email, can have some basic front end checks (is there an @ in the email entered by the user).
In fact, I bet the vast majority of validations can in fact be done in the front end in real time.
For simple projects, the validation built in to HTML form elements may be sufficient.
Yes you do.
Honestly, 99% of webapps today are 2 very interactive pages (which could often be developed in jQuery anyway) + bunch of generic datagrids & forms we have seen many times since the introduction of <form> and <table> tags decades ago.
Honestly, my problems as a developer generally aren't with the frameworks (I'm mostly defending Vue here, as I find it predictable and easy) but with the build tools, which have gotten a bit out of hand and always feel brittle.
The thing is maintaining simple state given the current abilities of css and JavaScript is a little bit more verbose in React than otherwise.
The UI component model’s data flow might vary between libraries, but they’re all generally opinionated and fairly consistent internally. The equivalent in “vanilla JS” can easily become unwieldy even with a lot of discipline, because the underlying APIs are designed with the view as the source of truth. That’s almost always the opposite of how you’d want to design a system with more than a very small amount of complexity. But that’s where inertia will guide you because there isn’t even a notion of state that doesn’t reference the DOM etc.
Once you’ve succumbed to this even partially, composition becomes incredibly difficult because the underlying model leaks implementation details. Tangling them is not just easy, it’s the default. Avoiding tangling them means basically developing a UI library with its own opinions and idioms. Which maybe you want that, but most people are building something else.
Untangling them is an enormous task. I’m maintaining an application that began in the era when this was common, and picked up some notion of components along the way. Even just understanding how things get invoked can take hours or days tracing app code and its interaction with implicit state in the view, and that’s with two years of familiarity with the code.
I don’t even like React or several of its idioms. But stuff that takes me hours or days would take minutes to understand with just the basic assumptions React or any other component library would afford. I can’t speak for any specific commenter, but I think this is the kind of “scale” most UI devs mean when they discuss it in those terms.
And granted, the critique that many things don’t need the scale they take on—that they add incidental complexity to fit a library/framework’s model. That can certainly be true, but I think the “vanilla JS” camp really underestimates how steep that cliff is and how quickly many projects can run off it.