
Web Programming Is Getting Unnecessarily Complicated - Mister_Snuggles
http://en.arguman.org/web-programming-is-getting-unnecessarily-complicated
======
DougN7
I wonder how many are like me (old school? Just old??) and eschew platforms
and libraries and roll my own most of the time, because most of the time, the
needs are simple, and it's quicker to pound something out rather than learn
and use Yet Another Framework. Though using jquery is nice sometimes...

~~~
fenomas
> eschew platforms and libraries and roll my own most of the time

That's what nearly everybody does, when they're one person hacking on a one-
off project.

I like to hate on Big Web Frameworks as much as anyone, but it should be
understood that their value isn't replacing your hand-rolled code, their value
is to let big 20-person projects avoid having 20 different flavors of hand-
rolled code.

~~~
Silhouette
_I like to hate on Big Web Frameworks as much as anyone, but it should be
understood that their value isn 't replacing your hand-rolled code, their
value is to let big 20-person projects avoid having 20 different flavors of
hand-rolled code._

Or we could just adopt good coding standards and build with reasonable
software architecture. That's been working for longer than anything like the
modern Web has existed, to build software orders of magnitude larger than any
web app by any useful metric I can imagine, without the need to resort to huge
frameworks to keep growing code bases organised and consistent.

~~~
fenomas
Big Web Frameworks aren't there to "keep code bases organized and consistent",
they're there to do stuff like render state changes into a complicated DOM
without causing jank, without FOUCs, without crashing IE9, etc. Those aren't
problems that "adopting good coding standards" can solve.

Web frameworks have architecture to them, but their value lies in solving
technical problems, not architectural ones.

~~~
Silhouette
_Big Web Frameworks aren 't there to "keep code bases organized and
consistent", they're there to do stuff like render state changes into a
complicated DOM without causing jank, without FOUCs, without crashing IE9,
etc. Those aren't problems that "adopting good coding standards" can solve._

I respectfully disagree. You don't need a framework to do any of those things.

I do a lot of work with relatively complicated browser-based UIs. In my
experience, the DOM/layout thrashing and jank issues that have been getting a
lot of attention lately only became a big deal in the first place because the
early frameworks were so horrifically slow compared to just doing manual
updates of exactly what you needed to change. Even in the most demanding
applications -- and not many web apps actually are this demanding -- you could
achieve pleasant, smooth results with some modest attention to how you applied
updates so you didn't cause the browser to regenerate layout unnecessarily.
(This would be an example of a useful coding standard, BTW.)

Flashes of unstyled content/text/whatever are a symptom of serving web pages
in chunks and how browsers render incrementally as more of the chunks are
available. Again, dealing with these effects just requires some understanding
of what causes them and a little care in how your site/app is served and does
its initial setup. The frameworks don't do anything magic that you can't do in
your own code.

And finally, we were solving cross-browser portability problems with script
repositories and then libraries like jQuery a long time before any of the
modern frameworks were on the scene, and in a much more varied environment in
the early days. IE has certainly had its issues over the years, but for the
most part at least the issues were well known and you could just work around
them. And again, there weren't really that many horrible issues, and this was
an area where having some basic coding standards worked OK even if for some
reason you didn't want to just use one of the many utility libraries.

------
Falkon1313
In my early days of programming, things began with realizing that I could use
this wonderfully powerful system to solve problems (almost any problem you
could model!) and create things (almost anything you could want to simulate!).
I just had to figure out how to model the domain problem logically in a useful
way, or what aspects of something to simulate, and how to allow the user to
interact with it.

That soon changed. In learning about programming, one can't help but to come
across the writings of those preaching the gospel of the holy virtues of
'reusable code'. Modular code, libraries, object-oriented code, design
patterns, frameworks, plugins, APIs, services, stacks and toolchains!

So programming is now largely about resolving a ton of dependency issues and
getting scores of different modules, frameworks, libraries, APIs, etc. to play
nicely with each other. Instead of using our brainpower to understand and
model the domain problems that are ostensibly the reason for our software,
we're using it trying to figure out how the heck to glom together all this
generic abstract code and modify the output to vaguely resemble something in
the domain, in a way that won't perform so horrendously that customers
immediately give up on it.

We write hooks, overrides, and underrides to throw out the work that the
reusable code is doing and get it to do what we want (more-or-less). We write
translation and adaptation and bridge layers to convert the data structures
used by one module to those used by another (and vice-versa) and eventually to
something roughly approximating the domain data. We set up elaborate clusters
of interdependent modules, submodules, plugins for our plugins, all on top of
a generic framework that wasn't even designed with the domain in mind.

As a profession, we've gone way too overboard trying to do everything with
reusable code. This is why it can take several hours to do something as simple
as change a link (and that can completely break something seemingly-unrelated
elsewhere in the system). And it's kind of amusing that we're now adding
layers of complexity to manage the layers of complexity.

I want to get back to focusing on building logical models that fit the domain,
solving problems, and simulating things. For that we need a new doctrine of
vertical development that doesn't just religiously say "Throw another layer of
indirection and generic abstraction on it! Yay reusable code!" as a sacred
solution for everything. Sure, code reuse can be good, but let's be sensible
about it, not kid-in-a-candy-store crazy.

~~~
marklgr
Reusable code, frameworks or plugins are fine, the problem is their cambrian
explosion since now anyone can jump in and publish some JavaScript or Go code,
especially with the micro-stuff trend. So we end up with zillions of projects
competing for traction, and we move from one new cool and shiny thing to the
next, for all (micro-)components of the stack.

This is the often-forgotten cost of competition (for all its merits) as
opposed to cooperation: it wastes time and energy.

~~~
sangnoir
> , the problem is their cambrian explosion since now anyone can jump in and
> publish some JavaScript or Go code, especially with the micro-stuff trend

I do not buy that this is a problem. It's not an apples-to-apples comparison,
but anyone can publish a 'book' on Amazon as easily as publishing an NPM
module (and they do), however, no one is complaining that there are "too many
low quality books". Why is it easy to ignore books but harder to ignore shitty
projects? Similarly there are countless instances of bad poetry online, and
_very_ bad fan-fiction, but the sky isn't falling in the literary world. Can
someone educate me: why do other people's shitty software projects elicit such
strong reactions?

~~~
TheOtherHobbes
Because books and poetry aren't supported by package managers. They're self-
contained, so you can ignore them and no one cares.

They also don't purport to solve a specific problem. (Like left-pad.)

And they're not boosted by a FOSS ideology which their existence a political
choice and not just a practical issue.

So basically interdependence. You need at least some external code to finish
most projects, and the chances are good it will be somewhere between
overcomplicated, unreliable, poorly documented, poorly maintained, and
unnecessary.

Maybe package managers need active best-of-breed curation and industry-wide
coding and documentation standards. But professional standards are anathema to
the move-fast-and-break-things crowd, so I doubt that will ever happen.

------
thoman23
It's funny how everyone seems to hate "big frameworks" while at the same time
complaining about how "everyone uses them". It's sort of like the Yogi Berra
line: "Nobody goes there anymore. It's too crowded."

I for one will go against the flow (or am I with the flow?) and say that what
I see coming out of Angular 2 looks FANTASTIC. Many of the things I love as a
Scala developer are finally becoming mainstream on the client side. Add in the
promise of NativeScript (mobile apps) and Electron (desktop apps) and this is
an incredible time to be a web developer.

~~~
thegayngler
Tbqh what is coming out of Angular 2 is React with a higher learning curve,
more Angular specific syntax and not much in terms of a larger benefit. React
keeps things simple and easy to reason about. I don't feel like I should need
or be using decorator like syntax at all to create a component. I like looking
at one file and knowing exactly what that one file is doing but that's just
me.

------
angryteabag
As a novice developer, coming from Java, I was taken aback by how forceful and
messy JS's async programming style is (I started with node.js then moved to
the browser).

Callbacks, promises, generators are all there to essentially make async code
sync, which seems to make the code hard to follow, difficult to scale,
modularise and debug.

I think JS took this approach because of the limitation of older browsers,
which were unable to use threading, so as to not block IO they forced
concurrency using queues requiring async style code.

We must have just stuck with it because it's just been around for long enough
and it would be hard to get everyone to change.

it's 2016 and I like being able to use the return values of my methods without
sweating. PLEASE, for the love of god, replace JS with something with the same
cushy syntax but makes sense.

Then again, I could just be bad at programming and not know what I am talking
about - I sincerely hope that is the case.

~~~
chug
> Callbacks, promises, generators are all there to essentially make async code
> sync

I think they actually do quite the opposite: they keep async code async.
JavaScript doesn't really have a (non-terrible) way to make async code sync.

Note that I'm assuming that by "being able to use return values of my methods
without sweating," you mean "get the thing I want out of the return type
somehow." Or, in other words, things like getting a value out of a Future. The
problem with that approach is that it blocks the calling thread, so what
happens if you have 50 connections? Or 200? Or 10,000?

The same reason I like that JavaScript and JavaScript libraries try very hard
to keep things asynchronous is the same reason highly concurrent software
tends to be event based rather than thread based: it's simply more efficient.

I think it can be a challenge to keep mental track of state in JavaScript due
to the nature of async stuff, but it can also be liberating in a way once you
figure out the right way to pack away your state for whatever problem your
working on. It makes it easy to break things into small components and reason
about pieces instead of the whole while maintaining decent efficiency compared
to having tons of threads around.

There's also of course the incredible niceness of JavaScript being single
threaded in that typical multithreading concerns are not a problem. If you
want to update a variable in some callback, you just do it. You don't have to
worry about locking or atomicity, etc. I can't tell you how many times I've
ended up with a mess of Java code in which I'm not actually sure if it's
correct or not. That's likely my fault, but still something I enjoy getting to
not think about when doing JS.

In short, I suppose it just comes down to different preferences. I often find
myself working on concurrency in Java and wishing that it were more like
JavaScript :). Interesting, the JavaScript approach can be pretty easily
recreated in Java (and sometimes a very useful tool), but the Java approach is
much harder to do in JS, at least with Node.

~~~
AstralStorm
I have yet to see event based software that is more efficient than plain old
sync code.

Big threaded reactor style designs can be, but those aren't exactly event
driven.

Small events generally are the opposite of performance, increasing concurrency
and synchronisation dependencies between threads.

If you meant responsiveness or latency, maybe you have a point, but current UI
frameworks have been event driven since about forever.

------
nevster
I'm up-voting this purely due to finding out about arguman. I had an idea for
a website exactly like this about 6 years ago. Kudos to the people who
actually implemented it.

~~~
dudouble
Me too.

~~~
AstralStorm
Sadly, it exemplified the problems due to not working well on small screens or
with reflow reader modes.

------
gkya
For publishers of content plain html and some little css would get you a
result that's readable, and responsive (I think a better word for this is
adaptive), if the authors are willing to give up their prescriptivisism on the
rendering of their content. Compliant use of html and css almost always
results in a page which the browser will know to display the best way with
regards to the medium. But once one's determined to impose a certain layout no
matter what, he takes on the browsers duty, and actually has to work towards
implementing an abstraction layer that takes care of the incompatibilities of
all different web browsers out there. Now there are libraries for this, so he
fetches and uses them to unnecessarily impose his style. Eventually this is a
needless burden on both him and the user, as while the megabytes pile up, load
speed and performance decrease and Internet bills increase in price. As things
skip and grow and shrink on the screen, the UX becomes cumbersome too. But if
the primitives of html and css are used, all these issues are irrelevant.

Another factor that complicates web page development is ads. They bring a huge
pile of Javascript with them, but they go ignored most of the time and usually
are a burden to the user. Ad providers, instead of publishing ads that would
indeed get clicked intentionally (like the Deck network), bribe the publishers
paying for user actions that aren't actual impressions. Thus they also create
exaggerated statistics which they use to lure low quality ads which get the
most clicks from accidental behaviour, leading to worse and worse ads that do
whatever to catch attention but be actually interesting.

Lastly, it is a fact that coding Javascript is more fun than writing a
document. For the web developer, rendering innyeractive graphics with
Javascript is certainly more fun than making them with R or gnuplot and insert
into the page with an img tag and providing data and code used to generate
them.

------
Fifer82
Edinburgh Scotland:

Seeking Junior Developer 19k.

Must know all the CSS preprocessors, all CMS's, all modern frameworks, all of
software engineering, all of the server side in all languages.... Ideally has
experience of everything. Must have worked Agile.

Needless to say, 7 years into my actual Web Programming career and I am
resigned to being stuck in a bad role. I don't have the confidence to apply to
anything since your expected to be an expert in what they announce tomorrow in
the next conference (and you had to do it in your own time) and if I do, the
pay is garbage.

I personally blame Recruitment Agencies for not having a clue what is being
asked for, setting a false market rate (maxium commission = race to the
bottom), and making the barrier to entry or even sell yourself impossible.

In short, I hope this year to re-boot my career outside of computing as pretty
much everyone I know makes more money than I do.

~~~
kiksy
I don't have much experience with the job market north of the border, but I'd
say your situation would be atypical. I'm outside of London and have seen what
you've described but the reality is that there is a shortage of people with
the skills you've described in that theoretical role. I'd advise you line up
4-5 interviews and just go and see how they work out. With 7 years experience
I'd expect you to be able to walk into a lot of positions without fuss which
pay much much more than £19k.

~~~
Fifer82
Thank's for taking the time to reply Kiksy. I appreciate it as I am a lone
developer and don't really have any real career advice. I just know that I
never seem to match my experience to any roles and it has been a while.

------
danso
Web programming is reaching not only far more people, but far more
combinations of people and devices, in far more scenarios -- think of how many
more ways you can do computing that don't involve sitting in front of a
desktop, which for most non-technical people was a relative rarity in day to
day life.

So web programming _should_ be more complicated because the world we now reach
is far more complicated. But I don't feel like complexity has grown nearly as
much as potential audience. And when things do get frustrating, such as trying
to do a heavy client-side app, I just have to look at the PHP Reddit/stack
overflow groups to get a reminder of how truly fucking annoying and confusing
it was to build a full stack app a decade ago.

------
formula1
Well yes and no. Javascript problems are what php used to solve before. Its
actually necessarilly complicated if you view it from what javascript is
attempting to replace.

On top of replacement, theres another question "is the common road the best
road?". Something as simple as a html5 video tag can be replicated through a
canvas, html5 audio and some ui elements. And as things get more complicated,
are we better off pretending complexity is the enemy?

The reality is that these are problems all languages have to deal with. The
reason the web is getting the most is because its the most widely consumed abd
provided. Why be involved in an ecosystem dominated by coorperate entities
that would only pay you just enough so you wont leave when you can be in an
environment where insanity is an acceptable road to sanity. Why the hell does
coffee script exist? It doesnt matter.

------
kiba
Because people are trying to cram down 10 different JS libraries down the
throat of a static page?

------
careersuicide
This arguman thing is really cool! It's such a neat idea in fact, that I'm
willing to overlook the horizontal scrolling. That's saying a lot!

With that out of the way... I'm firmly in the "but" camp here. I've been doing
web programming for 17 years now. I remember the bad old days. Things were
simple if all you wanted was HTML and images (CSS was still pretty iffy). But
the moment you needed more than a static page? The complexity of getting up
and running ballooned really quickly. And worst of all there were so few
resources to really learn from. And it was expensive. Granted I was a teenager
back then so anything more than a few dollars a month was pricey to me, but if
you compare the kinds of hosting offerings of two decades ago to something
like Digital Ocean or AWS today then the amount of possibilities is staggering
(no more shared environment!) and for prices that are almost too cheap to
believe.

My recollection of getting anything up and running that used a database back
then was that it was not for the faint of heart. Compare that to today and the
process of getting everything set up and connected with Rails, Djano, Express,
etc. Yes there's more stuff you "just have to know" in terms of code you write
and yes you have a box you have to stay within because of the framework but
I'll take that any day over gluing together some Perl scripts and hoping
you've got CGI configured correctly.

Maybe I'm conflating two separate things here: actual programming and
operations. But I strongly contend that with web programming you can't
disentangle those two things in any practical way. You will always be bound to
the context of your environment. Anything that makes getting a sane
environment easier leaves much more time to focus on the problem you actually
care about. And it's not like you have to use all of the shiny new toys if you
want to keep your code simple.

~~~
gkya
The server code has way less problems than the UI part of websites (i.e. web
pages). The complexity of putting up a webpage has made a very fast 0-60,
where it now may involve several package managers, JS libraries, to-CSS
compilers, multiple web browsers (multiple OS' if you want all of them),
minifiers, uglifiers, build programs and whatnot. And most web pages from
popular online publishers (news portals like the New York Times, blogs like
the Huffington Post, etc.) the ratio of content to CSS, JS, and HTML tags goes
towards 1/1000 and above. Most of the time features of browser are
reimplemented (history, page loading, scrolling...) and standard behaviours
hijacked (most often scrolling, clicks). Every website designs and imposes
it's own UI paradigm so that clicking around becomes a frightening and
challenging thing, as telling what is a link, what is a button, what is a
drop-down, etc. is hard, as either these are heavily styled to the point of
being unrecognisable or they are reimplemented in JS and the behaviour is
unpredictable. This hurts especially when doing critical things like money
transactions, various registrations that have become online recently, various
rendez-vous, etc. Together with this trends, HTML, CSS, and JS get more and
more complex in the specification level, which together with cancrous tooling,
make entry to web development (i.e. writing webpages or writing programs that
write webpages) harder and harder.

------
WalterSear
I, too, miss the days when web development was as simple as opening a file in
notepad.exe and refreshing a browser.

I made some boilerplate to solve this problem. If you are familiar with react,
it shouldn take a few minutes of `git clone && npm i` to get started.

[https://github.com/Jon-Biz/simple-static-react](https://github.com/Jon-
Biz/simple-static-react)

There are a few version up there: one has a router, one has a firebase
backend, one has Virtual Reality bindings. They all have the same purpose: to
get out of your way as fast as possible.

~~~
vectorpush
Web development is still that simple if you want it to be. Nothing is stopping
you from writing for the web like it's 1991 if that's all you feel is
necessary for your site.

~~~
blub
Unfortunately the web development profession has decided to shoot itself in
the face and make framework-oriented development mandatory. I mean sure, one
can still build sane web projects, just don't expect to be able to get a job
doing that and do expect to be mocked as some sort of luddite.

I am sort of curious if this pile of complexity will at some point implode,
but mostly I am happy that I got out of webdev when I did. Today's web
development is making a mockery of the ideas of usability, accessibility and
standards.

~~~
Silhouette
_I mean sure, one can still build sane web projects, just don 't expect to be
able to get a job doing that and do expect to be mocked as some sort of
luddite._

When we build web apps for clients, they generally don't care what tools we
use as long as the results are good. There's still plenty of work out there
like this and there are still plenty of success stories.

You just have to avoid the parts of the industry, particularly around the
startup scene, where most developers have just a few years of experience and
are heavily influenced by high profile online commentary. That type of
business tends to hire buzzword-compliant people because even their own
"senior" developers don't have enough experience to know any better.

~~~
Fifer82
You just have to avoid the parts of the industry, particularly around the
startup scene, where most developers have just a few years of experience and
are heavily influenced by high profile online commentary.

This is a great piece of advice.

------
Tiquor
Boo hoo. It's not that bad. Knuckle down and learn some shit. Crikey, some of
us learned this stuff before a crowd sourced 90,000 word wiki and versioned
online code repository was commonplace for a 200 line library. AND get off my
lawn!!

------
rajington
"Cooking is getting unnecessarily complicated." \- Caveman

Compare food nowadays to centuries ago, I'm glad things got unnecessarily
complicated.

~~~
JustSomeNobody
He cooked steak over fire. I cook steak over fire.

I'm just glad I don't have to hunt every day.

~~~
rajington
Not everyone is using the latest JS frameworks, and some people eat sous vide
grassfed steak.

------
nikdaheratik
I think there are many things pushing towards more complexity, and not much of
it is "bored developers pushing things to polish resumes".

1\. It takes longer to teach someone even "simple" web dev than it does to
leverage the programming talents of experienced devs. This means businesses
are better off making tools that allow a small group of devs to create many
simple websites or a few really complex websites than just keeping it simple.
Even a small dev company can produce output that matches what used to only be
possible with the resources of a much larger software company.

2\. As they mentioned, the path web dev is going is towards a device
independent software dev environment instead of simply serving up content or a
few simple tools. This is across the board from internal IT, to small B2B, to
large B2C resources. Alot of my personal programming time is adjusting the
generic B2B platform to meet the needs of a specific client we have that
doesn't quite fit the original project. It's frustrating, but a large source
of complexity and not "unnecessary" since it pays the bills.

3\. The number of devices that have to be supported by a platform is also
greatly increasing, and it makes the code itself, especially on the js side,
much more complex in response. I'm continually thinking "why do you want to
squish our site down to your piddly little phone", but that's the primary way
alot of users have access, and if you don't support it, you'll lose out to
competitors that do.

------
cm127
Ironically, I find that tree format unnecessarily complicated.

------
cttet
I like this website to layout an argument nicely. But in the case Web
Programming is not well-defined, the argument can just be people doing
different things assuming others are doing the same.

~~~
douche
I wonder how insane StackOverflow would look laid out with this kind of a
presentation scheme...

------
velmu
I think maybe web technologies are now everywhere and where it once took a
systems programmer to do certain types of things, now you're expected to do
that because "JavaScript is everywhere".

The language does not make the difficult problems easy to solve.

More: [http://medium.com/@velmu/on-ubiquitous-javascript-and-the-
un...](http://medium.com/@velmu/on-ubiquitous-javascript-and-the-unreasonable-
expectations-developers-can-set-themselves-f6994c07acd3)

------
ctulek
I am not sure if it is getting complicated in terms of libraries and
frameworks. We had prototype vs jquery wars, or gwt, dojo or yui discussions.

I bet the problem is Github! I mean, we are the victim of their success in
solving one of our bottlenecks: collaboration. Now it is not only easier to
start a project but equally easier to get followers, adapters, and
contributors.

------
sp527
Clientside code execution makes sense. Every last thing that can be offloaded
to the client should be. The tooling around this concept may be insufficient
or difficult to use, but the underlying premise is undeniably sound.

~~~
jasonthevillain
Not necessarily. The client device may be old, underpowered, slow, and running
out of battery. Which isn't to say thick clients are always a bad idea, but
they're not the One True Answer™.

~~~
sp527
Hah I rushed that answer but yes totally agree. When I'm dev'ing for web, I
always monitor perf against a crappy old Android phone. Similarly, Chrome
devtools makes it easy to simulate a bad network connection. I try to make
sure it's tolerable.

Also worth noting that analytics makes it easy to determine what device/OS the
majority of your visitors are using. Anyone building an app would be wise to
pay close attention to this to guide dev efforts.

------
pklausler
When it becomes easier for a site to write native iOS and Android apps for
clients than it is to write a pretty JS front-end that works on all browsers,
it's going to be bye-bye web as we know it.

~~~
prawn
Except for the fact that installing apps is an unnecessarily annoying process,
enough to mean that the majority of people very rarely install anything new on
their devices.

~~~
rimantas
If single tap is unnecessarily annoying, then web is already dead because
opening the web page is even more complicated.

~~~
prawn
Tap link, opens App Store, tap to install, wants me to login but I can't
switch to 1Password without cancelling and starting again, enter password,
agree to something about TouchID, T&Cs have changed so have to acknowledge
them yet again. App installs to earliest screen that has a vacancy, so have to
go through and find it.

The process can be quicker or longer than that.

------
jaequery
First thing that popped up in my head as I read this, React/Redux. :)

~~~
quantumhobbit
Meh. React + the twenty other things you need to add on to it is bad, but
somehow no worse than angular is by itself.

~~~
jaequery
Yes I reckon this thread is pointing at the whole client side frameworks
landscape right now

------
aardvark291
"getting"?

------
zem
i had very high hopes for opa [[http://opalang.org/];](http://opalang.org/\];)
i'm still sad it didn't catch on instead of node

------
draw_down
I mean, the entire name of the game is unnecessary complication. We took a
document platform and mangled it into an app platform... kinda.

~~~
copperx
We need to remind ourselves frequently that the web is a terrible platform.
Yes, TCP/IP changed the world, but the web is an embarrassment to our field.
It could be so much more.

~~~
gkya
Web is good. It's how we use it. If web was sex, todays web dev is basically
gang rape.

