
The boring front-end developer (2014) - rayraegah
https://adamsilver.io/articles/the-boring-front-end-developer/
======
OkGoDoIt
Yes, 100% this. I've been trying to articulate the annoyance I have with
modern front-end development and this hits the nail on the head.

Does anyone know SF companies that take this attitude? I've been interviewing
all over at startups and large companies but I always feel misaligned when
discussing front-end tradeoffs. I'm in the process of realigning my career
away from full-stack dev nowadays because the state of frontend dev is so
horrendous in my opinion. But I'd rather just work somewhere that isn't trying
to turn every little thing into an SPA.

~~~
ng12
Why not find a project somewhere that truly calls for an SPA? Those are the
fun ones.

~~~
flukus
Because those are almost non-existent. There are many web-apps that need a
fair bit of interactivity but a full SPA is overkill. I'm thinking things like
JIRA where the interactivity of the kanban board is good but most of the time
I'll just middle click to open a task in a new tab anyway, being a full SPA is
a net negative. Most of the rest deserve to be a real desktop and/or mobile
app.

SPA's aside web dev hasn't changed much in a decade, it's just been framework
churn.

~~~
ng12
I've spent most of the last decade working on data-intensive web applications
which definitely deserve to be SPAs. There's lots of opportunity, especially
if you're willing to move away from the "retail" public-facing web.

~~~
flukus
What do you mean by data intensive? I'm thinking something that looks like a
bloomberg terminal, complex tabular data or complex visualizations. Those are
cases that should never be a web app at all, even with recent improvements
HTML is a document format and horribly suited to those use cases.

------
ivanhoe
In 2014, when this was originally written, I'd totally agree - but it was 4.5
years ago and a lot of things have changed in the meantime. At the moment I'm
dealing with one jQuery old-school project and while on one hand it's really a
nice feeling to debug code without constantly waiting for webpack to finish
compiling the code, most of the time I'm really in pain. After years of
working in Vue and React it just feels ugly and messy and it's much more
complicated to understand and refactor. To quote on one of my fav Stephen
King's books "the world has moved on" since then...

~~~
mixmastamyk
There’s not much meat here to the assertion that it is easier to develop and
use.

~~~
jinfiesto
It's been probably 2 years since I've seen a front-end dev listing that
doesn't list experience with a SPA framework as mandatory. I'm not going to
question that hybrid and traditional apps exist in the wild. I maintain some
myself. That being said, I think it's pretty clear that at the very least the
world is moving on. We are asking for more out of the web than what it was
designed for, and it's difficult to meet the expectations of modern users
without modern tooling.

By way of example, I do a lot of freelancing and have quite a lot of clients
that I think would be better served by a traditional web app (much faster to
develop, though not nearly as rich interactions dollar for dollar. Also a
lower infra bill generally.) Many of them refuse though because they've been
conditioned to expect the kinds of features that SPA's provide.

I write a lot of business automation sorts of apps for SMBs. Something I see
requested a lot is wizard style workflows (on a web app.) This is trivial in a
SPA and a major annoyance at best in the context of a traditional app
framework. I totally agree that the world might not have moved on yet, but I
think it's pretty clear which way the wind is blowing. Users are expecting
rich SPA interactions as the new normal.

~~~
mixmastamyk
Sorry I miswrote. I recognize the mindshare shift, but not entirely convinced
on the makes dev easier part.

~~~
jinfiesto
I didn't mean to say that SPAs were easier at all. They're not. I think
they're under most circumstances much harder than traditional webapps. That
being said, my experience is that users and in my case clients are starting to
expect SPA features and it's harder to try and coax extensive SPA
functionality out of a traditional web app than it is to just write a SPA.

------
jv22222
I love the Indie Hackers community and mission of the site, but I can't
understand why on earth the site is so JavaScript heavy.

Almost everything on that site could be server side and there is no need for a
loading screen that takes 2+ seconds to load!

Again, love what they've done, love the community, don't understand the tech
choice.

[https://www.indiehackers.com](https://www.indiehackers.com)

Edit: I think javascript and dynamic stuff is great to use where it really
speeds things up like a comment popup etc. I think of it like seasoning. Use
it sparingly to make a site really great in the places that a full page reload
would be a bad experience.

~~~
jb3689
Yeah, in my ETL work we call things like this bugs. I've never understood why
this is acceptable on the front-end. Users seem to have been conditioned over
the years that it's just "slow internet" I think and are willing to wait for
an app to load

~~~
jv22222
Yeah. And how much code has to load?

Given that I can get 100k image in a few seconds!!! Ie Why would it ever need
more than 100k JS after compression and thus < 1s to load?

Even if it is a big size why not cache and be instant on load?

If the answer is it needs to use Ajax to load data after loading the js, then
why not include that data on initial load?

------
localhostdotdev
this is my definition of a boring programmer:

\- makes code that works

\- solves people's problems

\- doesn't care what other programmers think

edit: the truth is a boring programmer won't even read this, just doesn't
care, doesn't read hn, just does stuff

~~~
orange8
If the code only works but isn't maintainable (simple and extendable), then
you've got a very interesting programmer, just havn't realized it yet.

------
slg
Previous discussion:
[https://news.ycombinator.com/item?id=9879172](https://news.ycombinator.com/item?id=9879172)

This should also have a 2014 in the title.

~~~
dang
Added. Thanks!

------
newfangle
Does anyone that has been developing fe code in the past few years felt that
the pace of change has been overwhelming? I think weve finally settled down on
a few tried and true frameworks for frontend development.

~~~
throwaway8879
I'm working on something new and and the whole frontend ecosystem makes me
nervous. The last time I did any kind of production-level frontend work was
2004.

It feels like I woke from a coma and am trying to adjust to a new kind of
world with flying cars except they don't really fly.

I mean, I feel insecure for writing CSS by hand, not using webpack/roll-up or
a whole frontend build flow. I do like Mithril.js and Svelte though so perhaps
I'll start using bits of that in my new project.

~~~
mixmastamyk
The important part is shipping, not what tools you use. Facebook and many
others were started in PHP. That said I still lint my code.

------
arenaninja
But some of us do work on front-end applications where even modern frameworks
are scrutinized. I've started to dream of a maintainable application with no
runtime on top of the browser itself (no vDOM)

IMO frameworks nowadays don't give you much more than a rope to hang yourself
with, it's up to developers to recognize this. But some applications do need
these patterns in order to build front-end applications with dozens of
developers on the same team. The unfortunate reality is that too many people
think they need use the same tech for a landing page; and too few people with
front-end skills seem capable of profiling (in Chrome! nevermind trying to
figure out where your GC pressure is coming from in IE11)

But this article is pretty boring. I can think of some concerns that the
applications I work on need solved:

* Maintainable (TypeScript helps a ton with this)

* Stylizable/Themable (emotion/JSS, etc.; pick your poison)

* Reusable (presentational components in React; I imagine Vue could work for us as well)

* Asynchronous, reacting to events from user input/websocket/timers/local+remote storage appropriately

* Accessible via keyboard

~~~
wishinghand
> I've started to dream of a maintainable application with no runtime on top
> of the browser itself (no vDOM)

I believe the answer is Svelte.

~~~
arenaninja
I am currently looking into it :) So far the theming does not appear to be
fleshed out; I'm about to compare some performance metrics with some of our
animated components. I'm also not sure what the state management solution
looks like, but I only spent a couple of hours setting up today

------
jasonhansel
Also: the boring front-end developer recognizes that large single-page apps
can have significant front-end performance issues, which is why so many
"modern" web apps are unbearably slow & memory-intensive.

------
austincheney
I so tired of the excess tooling and incompetent reliance upon it. You don’t
need layers of frameworks and 150mb of dependencies to build a tiny web app.
Without all the helpful bullshit in the way I can get the job done 10x faster.
The excess nonsense isn’t there to help clueless users. It’s there to prop up
clueless developers.

When I start interviewing next month I am going to dive into this immediately
and if I don’t like the answer I am walking out. Interview over. They can hire
somebody else to write tiny react modules.

------
ng12
I hate these kinds of posts. It's all useless to talk about unless you talk
about _what_ you're trying to build. Not everything that runs in a browser is
cut from the same cloth. My job would be miserable without a UI framework,
it's a trade-off I've consciously made. I've lived through PHP and Ruby and
jQuery/Backbone/Knockout/Closure and my current stack (React + TypeScript) is
the only thing that makes my job actually enjoyable. The most important skill
is to be able to identify when and where building an SPA is a good idea (hint:
it's not your blog or your company's home page). If you really do need an SPA,
great, pick a UI framework and a few preprocessors/transpilers and get
hacking. If not, also great, just use server-side templates and jQuery.
Whatever way you go just remember to leave the zealotry at home.

------
winrid
Heh, I just built my new blog with zero client side scripting. It's so fast
(shameful plug: [http://blog.winricklabs.com/](http://blog.winricklabs.com/))

No real content yet, but there will be regular content about my side projects.

------
sk5t
This seems like an appropriate time to invoke
[http://boringtechnology.club/](http://boringtechnology.club/) \-- more
thoughts on why to avoid the flavor of the month when you're trying to build
useful software that doesn't _need_ dependencies on shiny new stuff.

~~~
kazagistar
Of course, once everyone does this, tech innovation grinds to a halt and we
end up using the suboptimal tools we have forever.

------
drivingmenuts
Where I work, we’re still using jQuery. Why? It works and everyone on the team
understands it, even the backend guy who hates doing UI stuff. We looked at
React and Vue, and they’re great, but it would be a nightmare to get everyone
on the same page and wouldn’t solve the problem of keeping our front end
lightweight.

~~~
halleonard
You would be surprised. After a couple tutorials I imagine, at the very least,
your backend developer will thank you. That's been the biggest migration in
the react world -- backend developers to the frontend, because the frontend
suddenly "makes sense" due to it being declarative and predictable, rather
than imperative.

As far as lightweight goes, jquery is much heavier than Preact, a React clone
designed to be lightweight. Only 16kb.

------
bryanrasmussen
ok since I worked at a place last year where compile times were hurting things
I can understand that part but in general I have to say really bad decisions
need to be made for compile time to even be noticeable.

~~~
rexpop
I'm working on a 1.6Ghz CPU and compile times are a frustrating several
seconds.

~~~
bryanrasmussen
The place where I was working was pretty big and had probably 10 big teams
handling different parts of their site, to compile your project you compiled
the whole site. Furthermore it did stuff like compiled images every time
although image assets were hardly ever added. Compile times at times could be
in the minutes. Not to mention that their gulp file was badly written.

A redesign of the whole compilation process was undertaken - assets that were
global were compiled through a different process and you pulled the
precompiled results, assets that were hardly ever touched in the normal
development flow were not automatically compiled instead you had to call the
process to compile them, only paths or asset types that had been changed were
compiled - thus if no sass files had been touched no style compilation
happened, and finally you no longer had to compile everybody's subsection of
the site only your own. Compile time was generally less than a second for our
part of the site on my machine.

------
jilles
Damn I am a cool front-end developer and that's not a good thing.

------
Romanulus
That was a very boring article.

~~~
drngdds
Yeah, I don't think we really need a hundred Modern Frontend Bad articles
every week

~~~
newfangle
We have 3. React, angular, and vue. Angular isnt even recommended anymore so
its really only react and vue.

I dont think there has been much change in the javascript world in the last
few years that hasnt been strictly beneficial. The biggest paradigm shift is
probably the widespread use of typing on the frontend with typescript and
flow.

~~~
tyingq
Job boards seem to have (a lot) more Angular than Vue work posted:
[https://medium.com/zerotomastery/tech-trends-showdown-
react-...](https://medium.com/zerotomastery/tech-trends-showdown-react-vs-
angular-vs-vue-61ffaf1d8706)

~~~
newfangle
I am not suggesting that vue is in more widespread use than angular. People
are reading too much into my comment.

~~~
tyingq
Ok. What did you mean by _" isn't even recommended anymore?"_

~~~
newfangle
That the default recommendation is react not angular

------
halleonard
loll

------
santoshalper
The boring front-end developer is trying to build for the web, not trying to
build shitty "apps" that just happen to run in the browser.

