
Responsible JavaScript: Part I - wheresvic1
https://alistapart.com/article/responsible-javascript-part-1/
======
userbinator
_We need to know the purpose we’re trying to serve, and only then can we build
something that admirably serves that purpose—even if it isn’t exciting to
build._

I wonder if there is a common mindset that the majority of web developers have
which causes them to love overcomplexity so much; certainly it's there in
other areas of programming, but it is not quite as prevalent. There seems to
be a very strong "if it's not new it's bad" sentiment[1], and as a result, the
amount of churn is also extremely high. What's so "exciting" about doing more
with less?

As an aside, it is good to see that this article is completely readable
without JS.

[1] I've received comments from "real web developers" that some of the JS I've
written is "not modern enough" \--- despite it working in more browsers and
being over an order of magnitude less code than their proposed "proper web
development" solutions. They are correct, I am not a "real web developer", but
when I write JS it's usually because I have a problem to solve and don't have
any other choice.

~~~
olavgg
I am also a classic web developer, still using vanilla javascript and trying
to do as much as possible with just html and css. I feel I can solve any
problem fast, quick and with minimal amount of code and bugs. For the recent
years I have hired a few javascript developers and a common pattern I see is
that the reason why they want to use overcomplicated toolset, is because this
helps improving their CV so they are easier to sell. CV building is a thing,
and developers also want to stay relevant in the future.

For example I went through software developer job listings in my area. Of 100
listings, 40 of them are React specific, 2-3 Angular while maybe 5 mention any
kind of frontend development like html/css/jquery. The rest is classical back
end positions. There is a HUGE demand for frontend expertise these days.

If you as a consultant want to sell yourself as a kickass rockstar frontend
developer, you want as much React experience as possible on your CV. Some will
even turn you down because of the fear of damaging their CV by just doing
vanilla javascript work.

~~~
bernawil
Myself and most full stack devs in my circle using React used to do
html/css/jquery before. Nobody misses the jquery days. As soon as you start
fetching data from api and refreshing your UI you get into a mess. Let's not
forget that most MVC frameworks from the era imply mixing server side
rendering with some partial client-side rendering on UI updates. Re-rendering
your html from templates client-side, re-binding your elements to its
events... it's objectively worse both in runtime performance and development
wise.

~~~
mosdl
React just does the rerendering and re-binding for you - and does it way less
efficient than if you hand coded it.

What you should be doing is just changing the parts that you know have
changed. Letting react do the hard work will always lead to worse performance

~~~
bernawil
Not really, at least in my experience. The re-binding really isn't the same as
the jquery way. React reuses the same event handlers, how it's implemented is
another story and not really important anyway. The other issue is the fact
that in the old way it's implicit that there's a mix of server and client side
rendering. Say you have a grid of data that was rendered server-side. Then you
update a row, which posts to an api endpoint and you get a reponse that
represents your new row. At this point there's only a couple of ways this
could be done:

1\. you get a json object which you pass to a javascript function which re-
renders the row's html and re-binds all interactive elements. 2\. You get
server rendered html from the server, which then leaves you to call a js
function to re-bind all interactive elements.

some classic problems with this approach: 1\. some rows data may depend on the
data of other rows... now you have to sync client and server side state! (huge
problem). 2\. Remember that initial server-side view? guess what, all
interactive elements had to be bound to the javascript handlers initially. Now
you need code to initialize the view which is different to the one you use to
do the partial updates. 3\. Yes, I dind't even mention that we could send
server rendered html full of inlined handlers as in
"onClick=myClickHandler()". Because this leads to problem #2 right away.

I'm not saying React and friends are perfect, but it does solve all of this,
at least IMHO.

------
gorpomon
Complexity in JavaScript is not a code issue, it's a UI issue. Complicated
UI's necessitate frameworks, not developers. When a website hits a certain
level of UI interactions, I arbitrarily say around 10 per page, then
HTML/CSS/"A sprinkle of JS" becomes unsustainable. Shipping 400kb of React
isn't ideal, but to manage your complexity it is responsible.

Let's say your page has the following: \- Custom form validations \- Custom
styled <Select> tags \- Forms that should show full lifecycle on submit
without page refresh (form accepted, form error, sometimes API's return a 200
that is actually a failure :-/ ) \- Inline editing of some user data. \-
Badges based on your users activity. \- Notifications of new items. \-
Navigation styling that is JS powered in some way, or un-achievable or kind of
a schlep with CSS (maybe the links are API powered :-/ ). \- A table with
sorting/filtering \- Drag and drop reordering \- Some type of chat window

Now let's increase complexity and say all those things respond in some way to
changes in the other things.

I've built that page. That page is no longer a website. That page is an app
and apps need structure.

The developer alone didn't decide the page needed all that. Chances are the
business thought doing everything on one page made a strong business case. The
UX team backed it up. The developer maybe agreed because they want a
challenge.

There's no way this trend abates until complicated UI's fall out of fashion.

~~~
Touche
This is the common excuse given for bloated JavaScript usage but it ignores
the realities of what is happening on the web. People are building simple
blogs with JavaScript frameworks. People are building their 2 form field login
page with JavaScript frameworks.

It's just inaccurate to take the most complex thing you can create and act as
though that's the norm; it's not. Websites still exist, and people are using
the most complex tech to create those too.

~~~
gorpomon
I ask in the spirit of friendliness, is this really an issue, or is this
something that feels like one?

I'm hard pressed to imagine WordPress having login forms done in a JS
Framework, and that's a big chunk of the web. If they are doing that, then
you're right, it's totally unnecessary. But I'm guessing the folks at
Automattic are optimizing this stuff for their clients (but I concede that I
could be wrong here).

As far as blogs in these tech stacks, if they're developer blogs then that
makes total sense. A dev blogging about React would probably choose React for
their blog since that's a live production laboratory for any React code. I had
a website in Ruby on Rails for years because I was a Rails dev and it was easy
to try stuff out.

Are there any concrete stats on actual mismatch? Do we know how many recipe
blogs are using Angular or React? My guess is their bloat is from tons of
scripts and not from a developer using a tool that is wrong for the job. That
bloat is at its heart a UI/business problem. Analytics, pop-ups, sharing
links, referrals and that entire class of web objects IMO opinion are
UI/business concerns, and they'll continue as long as folks find those things
valuable.

~~~
Touche
Yes, it's a real issue. There's even a VC funded startup that specializes in a
React based blogging tool:
[https://www.gatsbyjs.org/](https://www.gatsbyjs.org/). If you work as a web
developer there's just no denying it; using a SPA framework has become the
default for all new projects, full stop, regardless of the type of project.

For data, look up often reported stats on JS size.

~~~
jakelazaroff
When did progressive enhancement become a bad thing? Gatsby generates static
files with functional markup, then layers React _on top of that_ for an even
better experience. Try loading e.g.
[https://overreacted.io](https://overreacted.io) with JavaScript disabled. It
works perfectly.

~~~
Touche
Pick any article on that page. Scroll to the bottom and refresh. In a
tradition site the browser would remember your scroll position. Here it
doesn't, likely due to using client-side routing in JavaScript. So instead
you're taken to the start of the article each time.

It's this type of detail that's really difficult to get right when you choose
to opt-out of decades of iteration and do everything yourself.

~~~
jakelazaroff
Sure, but "not retaining scroll position on refresh" is hardly a case of
throwing the baby out with the bathwater.

~~~
Touche
You can't dismiss this bug like that. Having multiple tabs open and having
those tabs get taken out of memory and needing to refresh is a very common
thing to happen. This is a bad bug for this particular website.

Now, you said that by layering a SPA on top that an "even better experience"
is provided. What exactly is the better experience? Just navigating around the
site a bit I don't see anything particularly dynamic about it at all.

~~~
jakelazaroff
Actually, I just disabled JavaScript and tried reloading on a page, and that
bug happens anyway. Not sure why that's happening, but it's not JavaScript.
And considering it doesn't inhibit access to the content _at all_ , "bad bug"
is a gross overstatement.

As for the better experience: faster loading and dark theme?

------
azangru
> Most layout issues JavaScript packages attempt to solve, like box placement,
> alignment, and sizing, managing text overflow, and even entire layout
> systems, are solvable with CSS today.

This paragraph has surprising links. "Managing text overflow" links to Shave,
a library for truncating multiline text[0]. Last time I checked, CSS was
capable of truncating single-line text, but could not truncate multiline text
(the line-clamp rule is still not universally supported). The first link in
that paragraph is to a flexbox polyfill, and obviously, there's a reason why
people use polyfills.

[0] -
[https://www.npmjs.com/package/shave](https://www.npmjs.com/package/shave)

~~~
comis
Yea there's plenty of benefits using a truncation library (we're currently
using react-lines-ellipsis) over just css truncation. More control over how
the truncation happens, callback so you can do more stuff on the condition
that truncation has occurred, multi-line truncation as you mentioned, etc etc.

I get the feeling that most of the time when people are complaining about
unnecessary libraries they simply haven't personally run into the problem that
the library solves yet.

------
ascotan
This all started with angular imho. There was a time when structure, layout
and logic were more cleanly separated. Angular blew this up with <ng-xxx> tags
(which was a step backwards towards PHP imho) and this has been driven forward
by other frameworks since. It surprising to me how so many people can talk
about shadow dom but can't name any of the HTML5 apis or even more than a few
tags and what they do (much less anything about CSS3).

~~~
pault
One of my interview questions is "how do you organize logic and state in a
react app?" and about 19/20 candidates put their business logic in their view
components. I believe the root of the problem is the ecosystem of terrible
react tutorials that are targeted at beginners so can't introduce complex
architecture. If you spend some time reading react blogs you'll see that
almost all of them put their API requests and business logic inside component
lifecycle methods. The flood of bootcamp grads has made hiring competent front
end devs nearly impossible (not to slander bootcamp grads; I've met a few that
are brilliant).

~~~
ep103
>you'll see that almost all of them put their API requests and business logic
inside component lifecycle methods

Edit: (I rephrased this post) I understand that logic often makes sense to
break out between presentational and container components, and I understand
that sometimes api / service calls should be broken out into their own files,
but everything I've read states that api logic should be called from
ComponentDidMount.... you are saying that you shouldn't make api calls, from
component lifecycle methods whatsoever?

I'm not sure what the alternative is?

~~~
c0wboyc0ding
I would also love to see resources that detail how to separate business logic
from view components. As a junior dev, I know it's the right thing to do but
I'm not sure how. Is it as simple as passing props into a utils file?

Any links would be greatly appreciated.

~~~
parthdesai
[https://medium.com/@dan_abramov/smart-and-dumb-
components-7c...](https://medium.com/@dan_abramov/smart-and-dumb-
components-7ca2f9a7c7d0)

~~~
ep103
So I'm aware of the difference between presentation and compositional
components, but the original poster was claiming service calls shouldn't be in
lifecycle methods? Abramov puts his api calls into ComponentDidMount in his
egghead.io videos...

------
Tade0
These are valid concerns and fortunately there are already examples of
potential solutions being developed:

[https://svelte.technology](https://svelte.technology)

Not saying this specific framework is going to be a success, but so far it
both:

\- Is mostly "batteries included".

\- Indeed does create pretty small bundles.

~~~
moosingin3space
The really nice thing about Svelte is that it treeshakes really well. I wrote
a Firefox extension with Svelte (v1), and when Svelte v3 becomes stable I will
be very excited to upgrade.

------
phponpcp
Benchmarking on low-end devices to prove your point is situational at best in
my opinion. For example if you work at a luxury ecommerce brand, you can
assume that most users who actually are going to buy something are going to be
using a flagship model device.

~~~
Sohcahtoa82
> if you work at a luxury ecommerce brand

That's a big IF right there.

You're dismissing the author's point simply based on one hypothetical. In
general, the author is right. JavaScript frameworks are being abused and
developers don't care about the download size of their web pages, and it's
terrible.

If you're on a desktop with a wired internet connection, then yeah, it's not
really going to matter. But if you're on a 3 year old low-end mobile device on
a spotty 3G connection, it's significant.

------
mmis1000
At first glance, I thought it was yet another 'do not use JavaScript at all
because it is too bloated while ignoring all real world use and claiming
everything can be done by css' click bait article. But this article actually
considering real world use, making the point valid instead some silly useless
statement. And it also does provide some useful suggests and making its points
strong. Probably the best article of this kind I saw recently

------
briantakita
Here is a "Real World" comparison of Front End Frameworks, which includes
payload size.

[https://medium.freecodecamp.org/a-realworld-comparison-of-
fr...](https://medium.freecodecamp.org/a-realworld-comparison-of-front-end-
frameworks-with-benchmarks-2019-update-4be0d3c78075)

------
revskill
As i realized, the difference between a website and a web app is that, a web
app is also a state machine. A website is stateless.

So, if your state machine is complicated, the web app is also complicated. As
it's so hard to modify even a small portion of a mess.

------
rmrfrmrf
Such are the contradictions of the web that we shun constant code churn while
at the same time giving full-throated endorsements of Service Workers.

------
perttir
Anybody else has issue with the side banners being on top of the text in the
Firefox?

------
ChicagoBoy11
TL;DR: Use the platform

