(no title)
pnevares | 5 years ago
"Still, JavaScript is the most brittle of all front-end web technologies. An important skill of a front-end developer is to know when not to solve a problem with client-side JavaScript. It is always more robust to solve a problem further down in the stack."
Also, maybe the title here should include (2017)?
> Published on December 21, 2017.
game_the0ry|5 years ago
Underrated comment.
After doing full stack development for a couple of years now, my anecdotal experience has taught me that front end JS is (usually) the more labor intensive and nuanced of the two stacks (client and server), and that the majority of defects are UI (that is, JS) related.
That's not to say JS sucks or is a sub optimal solution for its use potentials use case. For the use case of the browser, its the only sensible choice.
When in doubt, move logic to the back end - less JS is always better.
hombre_fatal|5 years ago
I think it's an overrated comment.
Sometimes you just want a simple API that all of your clients talk to: your iOS client, your Android client, your Windows client, your TV client, and your browser client (Javascript) is just another client that consumes the same API, not a special-cased frankenclient that's half-rendered on the server.
Or maybe all you have is a browser client and you still don't want it to be this frankenclient thing. And instead you want the separation of concerns instead of doing some UI things on the server and some UI things in the browser.
A rule of thumb like "do as much as you can on the server" just sounds like cargo cult mysticism in place of putting on an engineer / product-designer hat and weighing the pros and cons.
tomlagier|5 years ago
It feels like we put all of our eggs in the JS basket - we know how to factor out well-scoped components, encapsulate styles at the component level, and build reactive, state-driven interfaces, all from JS.
There are certainly patterns that allow for componentization, encapsulation, and state management in pure HTML and CSS. None of them that I have used (pure WebComponents, SSR templating a la Pug or Rails/Laravel/etc, the "good ol' days" of "simple" single-file HTML/CSS) have felt like they scale beyond a basic document with link-based navigation.
As soon as you introduce forms, real-time updating, or layered interface state (modals, drop-downs, etc) you start spiraling into progressively more and more kludgy orchestration scripts until you end up wishing you'd just built the damn thing in React to start with.
If there was a well-defined set of HTML and CSS patterns that you could start your website with and _always_ feel like you could add additional functionality without compromising the existing structure, I'd migrate to that in a second.
As it is, the best way I can see for accomplishing a web project where I don't feel boxed in as soon as the requirements change is to just eat the few days of setup complexity up front and use a well-supported JS-based component framework.
There are all sorts of terrible downsides to that approach, as have been extolled ad nauseum here and elsewhere, but I legitimately don't see another way to do it. It's easy to say "for a simple static site, just use plain HTML/CSS!", which is fine if there's a clear scope that won't expand.
The second you introduce uncertainty and possible future complexity, I don't see a better alternative to a current JS-favored stack.
That's hugely compounded by all of the zillion QOL things that you need to worry about as you account for complexity - time to first paint, responsiveness across screen sizes, proper eventing, cross browser support, memory leaks, jank-free animation, page weight, internationalization, etc etc etc. One layer of the stack has an answer to most of these concerns, but it's very difficult to orchestrate all of them without ending up with a lot of JS that needs to be managed.
oweqruiowe|5 years ago
I find myself annoyed by how trendy it is to crap on all of the progress that has been made on the client-side stack... basically it seems like a lot of the lessons we have learned over the years are being forgotten. "Embrace the C in CSS!" Like, no! That C is what lead to the most painful CSS refactor and cost 6 months of my life. "Seperation of concerns!" It sounds good to say HTML and CSS should be separate, but we found how powerful it is to co-locate a component's styling with the component. People underestimate how much styling is just inline styles. "Wait, what do I name this class that is just applying margin-top?" If you have a global bin of css utilities and theme variables, everything else is just inline on the component.
timw4mail|5 years ago
My experience is that most of the Javascript used for forms is for fancy custom controls (where a standard one would be fine), weird editing flows (like click to edit), or other functionality which isn't actually needed.
That's not to say that JS with forms is evil. HTML validation is better than nothing, but complex data requirements may require custom validation logic in JS as a convenience to the user.
Izkata|5 years ago
I don't think "brittle" is the right word. I get what it's going for, but thinking back to the jquery days where the javascript was driven by events fired from the DOM instead of a framework, it was actually really robust - when something went wrong, instead of the whole page crashing, you'd end up with just one feature not working while everything else was fine.
mr_toad|5 years ago