
Robust Client-Side JavaScript (2017) - tosh
https://molily.de/robust-javascript/
======
pnevares
This is a great reminder of a lot of tools, and the closing thoughts are
excellent:

"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.

~~~
tomlagier
I think the fundamental problem I find when architecting a new website is that
not enough thought has been put into making HTML and CSS sites scale with
complexity.

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.

~~~
timw4mail
How do forms require Javascript in your view?

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.

~~~
kaishiro
JavaScript is a requirement on most forms due to either designer or client
expectation. They want styled, custom client side validation. They want a
visual loading state while the form is being fetch'd to the server/service.
They want a nice success message to display inline once the submission is
complete. Rarely is it custom controls or weird editing flows in my experience
- it's much simpler than that.

And we do it because they're paying the bills - there are more important hills
to die on.

------
seanwilson
For error logging ([https://molily.de/robust-javascript/#error-
logging](https://molily.de/robust-javascript/#error-logging) in the article),
can anyone recommend a logging service that has a small JavaScript footprint?

I use Sentry on one site but it has a 56K library you have to load before any
of your JavaScript loads, so bad for page size + bad for page blocking. I
would have thought they'd at least let you use a shim to capture errors
quickly while you defer loading the full library (like how Google Analytics
does it) but I can't see an obvious way to do that.

Sentry has really nice features but 56K (17K compressed) is a big chunk when
I'm trying to keep a page to about 100K transferred.

~~~
jbob2000
There are many ways the browser can fail. I'm sure their SDK is large because
of all the random hacks they need to use to capture everything from every
browser. Couple this with the need to create first-class API, which adds some
code bloat, and I can see how this ends up at 17K compressed.

~~~
seanwilson
Why can't they do the shim approach while the library loads though?

Google Analytics for example lets you push everything you want to record into
a plain global array called "ga", and when the library loads, everything in
the array in processed by the library. This lets you start capturing events
without waiting for the library to load.

~~~
the_gipsy
it's a bit different though, you can't "push" errors somewhere, I guess so
many error handlers and interceptors are set that it's not worth to split.

~~~
seanwilson
> you can't "push" errors somewhere

Why? Can't you push the Error object or stack trace into an array to await
processing?

~~~
jbob2000
What if the thing that is pushing the error object has an error?

------
afarrell
> Do not take anything for granted. Do not count on anything. Question your
> beliefs.

One thing that makes it much harder to question your mental model: Not having
one.

Confusion is bad.

I think some developers shy away from learning to build robust or accessible
sites because getting something to work at all makes them feel like they are
fighting against Venetian blinds[1]. By "some developers", I mean me. One key
to overcoming this is the self-confidence that when someone says you are
"overthinking things", "trying to understand the universe", or "just
experiencing impostor syndrome" you can (silently, in a message you never
send) tell them to pound sand.

If sitting down with a book[2] or other guide to frontend development helps
you see a picture of how things work, be willing to give yourself that.

If writing automated tests helps you to see how things work, be willing to
give yourself that.

[1] There are people who interpret it as an insult when frontend devs post
[https://www.youtube.com/watch?v=-pzckbNyqfc](https://www.youtube.com/watch?v=-pzckbNyqfc),
but it is a real expression of individual experience.

[2] [http://book.mixu.net/css/](http://book.mixu.net/css/)

------
threatofrain
Too bad, I was hoping for a discussion of state reconciliation strategies
between front and back end. Anyone know where to find the conversation on the
state of the art?

~~~
oweqruiowe
I think the best we have is still using GraphQL on the Server, with a client
side library like Apollo or Artemis (Clojurescript)

~~~
tuesdayrain
React + Apollo + TypeScript syntax took me a bit of time to get accustomed to
after primarily working with JavaScript and REST APIs, but once I fully
grokked it I decided I will never go back.

------
tempodox
An excellent book that will be understood by beginners and teaches all the
important things, written in a clear and simple language without any
shenanigans. Great work!

