
Ask HN: Is web programming a series of hacks on hacks? - barefootcoder
Been doing application development, primarily backend development, for a number of years.  I&#x27;ve always found it quite easy to move up and down the stack and work anywhere from UI down to the bare metal in a number of environments and languages, and always the &#x27;fast learner&#x27; who quickly knows the system inside-out, even when thrown into some area that I&#x27;ve never seen.<p>Lately I&#x27;ve been doing some web development on a fairly long-lived and large code-base, but I&#x27;m finding it MUCH harder to wrap my head around than application development ever was.  I think my difficulty is that the whole environment feels so... HACKISH... everything is a horrible hack on top of a horrible hack. (yes, I&#x27;m familiar with the history, been using the Internet since before the web)  I&#x27;m not even talking about the fact that everything has to be stateless, in fact I develop desktop apps as stateless even driven UIs as well, but just the fact that it really feels like there&#x27;s no consistent way to do anything, there are 1000 different frameworks, all with their own way of doing the most basic tasks, and my experience is that they all ... well... suck.<p>Am I missing something?  Is it me resisting change?  Is web programming really that bad?  Is it really just that I need a new mental paradigm?<p>Can you recommend any good resources to help me orient my mind to this new way of thinking?
======
pixie_
Yes. I feel like we're in the dark ages right now.

JavaScript - Dynamically typed, does not scale what so ever. Code written in
it becomes 'read only' very quickly. Impossible to refactor.

CSS - Also becomes impossible to manage. Who knows if the class you wrote is
or isn't being used in HTML or JavaScript somewhere. Same problem, read-only,
it only gets bigger and more unmanageable.

HTML - At the heart of it, the foundation is the layout engine and
positioning, and it sucks. Flexbox was supposed to bring sanity, but I feel
like we're still waiting on it.

Put these three stooges together and you get where we are today. Rewriting the
same damn app every year in another framework in what can only be described as
some sort of high paying purgatory.

~~~
meredydd
If anything, this understates the problem. A modal web application today takes
an absolute minimum of _five_ programming languages and _three_ frameworks:

    
    
        * HTML
        * CSS
        * JS
        * A server-side language (eg Python)
        * SQL
    

And then come the (leaky) abstractions on top of them:

    
    
        * A framework to make JS bearable (eg Angular)
        * A framework to make server-side bearable (eg Django)
        * A framework to make CSS bearable (eg Bootstrap)
    

...and often...

    
    
        * A framework to make SQL bearable (eg SQLAlchemy...)
    

When someone asks me how to learn to build web apps - even someone who can
already program a bit - I feel embarrassed explaining to them what a pile of
patches the Web is. Even if the languages themselves were saner, this is a
_monstrous_ amount of complexity for something that takes one language and a
drag'n'drop GUI builder on any other platform.

Trying to fix this, at least for simple apps, is why we built Anvil -
[https://anvil.works](https://anvil.works) \- where everything is in Python,
and the GUI is drag'n'drop.

~~~
9point6
I think your use of "minimum" is wrong here. If you're using React running on
Node and Webpack as your task-runner you just need Javascript and that's it.

Node allows you to run isomorphic JavaScript that runs on both your server
side and client side (to ensure you don't end up with the Angular-style
skeleton pages coming from the server), You can pick a nice ORM (like
sequelize) to abstract away SQL, and Webpack allows modules to specify their
styles in JavaScript to allow compossible CSS for each given page.

Yes this is still using a couple of frameworks, but I personally prefer the
approach of a lightweight standard library to the everything-and-the-kitchen-
sink approach that other languages have.

~~~
zeveb
> Node allows you to run isomorphic JavaScript that runs on both your server
> side and client side

But then you're writing JavaScript on the server side, and I think I'd rather
shove live weasels down my trousers than write one line more of JavaScript
than I absolutely must.

~~~
BinaryIdiot
JavaScript is a fantastic language. I don't get this animosity towards it. A
decade ago it was made fun of by people who "use real programming languages"
but JavaScript has grown up. It's actually very good and very fast. ES6
brought improvements but honestly ES5 is still a great language.

~~~
nathan_long
JavaScript is not a fantastic language. It does a lot of things that make no
sense. It converts between types in nonsensical ways. Eg in Ruby, you can't
accidentally do `5 + "hi"` and get "5hi". If you really want to treat the
number as a string, you can do `5.to_s + "hi"` and it works, but you don't do
such crap accidentally.

In JavaScript, `4 / "cake"` returns `NaN`, which is sensible, but if I wanted
to check whether I just accidentally did a bad division, `(4 / "cake") ===
NaN` will lie to me.

There are LOTS of quirks like this. JS is like a floor with boards missing all
over the place. Yes, if you've walked on it every day for years, you've
already stepped in every hole and know where they are. But that doesn't make
it a good floor.

A _good_ language is consistent. JS is not.

The fact that it now has fast implementations has nothing to do with it. This
car goes 300mph, but don't use the left turn signal on Tuesdays because that
sucker will blow you up.

~~~
BinaryIdiot
> It does a lot of things that make no sense. It converts between types in
> nonsensical ways. Eg in Ruby, you can't accidentally do `5 + "hi"` and get
> "5hi". If you really want to treat the number as a string, you can do
> `5.to_s + "hi"` and it works, but you don't do such crap accidentally.

Uh, so two things here. First, even though it's a dynamic language you should
know what your code is doing. Your code should never be be "accidentally"
doing this. That would be very poor design outside of an accidental bug.

Second, some other dynamic languages do this or other weird type coercion (I
mean type coercion exists for a reason; sounds like you're against it in
general which is separate from JavaScript). PHP simply extracts numbers from
strings and uses them in this case. Many languages use + as a concatenation
operator JavaScript just doesn't have a good way to override it so it could
work properly in all cases.

> In JavaScript, `4 / "cake"` returns `NaN`, which is sensible, but if I
> wanted to check whether I just accidentally did a bad division, `(4 /
> "cake") === NaN` will lie to me.

It's not lying to you; you're using a feature of the language wrong. That's
like calling the wrong validation function and getting upset because it's not
working like you wanted it to (because there is a validation function for
NaN). At the same time a good design won't run into this issue anyway. Now
I'll admit NaN is a bit of an oddball so yes it's not the most intuitive but
at the same time don't say the language is _lying to you_.

> There are LOTS of quirks like this. JS is like a floor with boards missing
> all over the place. Yes, if you've walked on it every day for years, you've
> already stepped in every hole and know where they are. But that doesn't make
> it a good floor.

> A good language is consistent. JS is not.

Not really. This is the common statement repeated by those who don't use
JavaScript and consider it an awful language. If you're following best
practices I'd love to know where all these language quirks or inconsistencies
are because I'm for sure not running into them.

------
jaredklewis
I think it's worth noting that back-end web development is an usually pleasant
place. In most other types of programming, many technical decisions are made
by the platform and working with tons of legacy cruft is the norm, not the
exception. For example, where else can you so freely choose the programming
language?

Linux Driver? Use C. Mobile App? Java or Swift/Objective-C for Android or
iPhone, respectively. GUI App? Again depending on your platform that will be
either C++, Swift/Objective-C, or some .NET thing. Making a neural net? You
could do everything from scratch, but it probably makes more sense to just use
a platform like Tensor Flow and python.

Backend web development on the other hand: use anything! Wanna use lisp? Go
ahead. Wanna store your data in an unproven experimental database? No problem.
Wanna use micro-services? Monoliths? Anything goes.

Browsers are extremely complex application platforms. But despite how you may
feel, they didn't succeed because of their weaknesses. The browser as an
application platform succeeded because of its strengths. Web browser are the
least bad option (and beat out many other worse options).

For better or worse, browsers are what we have. Make the most of their
strengths, and deal as best you can with the weaknesses.

~~~
apatters
This is exactly why I've always been puzzled by the urge to move more and more
logic to the frontend. In backend development you have a choice of many mature
languages, tools and frameworks which are fairly sane. I'll take that
environment as the foundation of a web application any day and apply the mania
of client-side javascript to it selectively in cases where we need to minimize
server roundtrips.

~~~
dspillett
_> why I've always been puzzled by the urge to move more and more logic to the
frontend._

This is usually about a mix of scalability, responsiveness, and partition
resilience; with the level of importance of those being dependent on the
application.

* Scale: if the client makes fewer request of the server(s) then you have reduced server and network requirements. As server resources get cheaper (and the cheap options more reliable) that side of things is becoming less important, but the network requirements extend far beyond you and almost all the way to the user (see the following two points) who might have a very slow connection at times.

* Responsiveness: the more that you can do client side the quicker your application will feel to the user, even if there is a delay in updates actually hitting the global view you can make it look/feel instantaneous (though you do start to have more problems wrt conflict management when people are collaborating). Have a look at the different methods online games (where real responsiveness and the appearance of instant iteration are vital) manage this.

* Partition resilience: if the client can keep working for a while without needing to talk to other hosts, perhaps queuing updates for reply when communication is restored, your application can keep functioning if there is an issue at your end (glitch at your server provider perhaps) or the user's (on mobile and temporarily in a radio blackspot?) or in between (i.e. a routing issue between ISPs). Even partial resilience is better than none: even if I can't see other people's updates until I'm back in a good signal area, if the app calmly tells me so but allows me to continue to add my work and review already locally cached information I can continue to work (or play!) in a way that wouldn't be possible if more of the logic were server-side.

~~~
MustardTiger
>This is usually about a mix of scalability, responsiveness, and partition
resilience; with the level of importance of those being dependent on the
application.

I have never seen anyone make those arguments. I've seen people vaguely
reference them in a hand wavey "I don't understand this but google facebook I
am right" way. But that's as close as it gets. It is usually about following
trends.

~~~
dspillett
In some cases it may be about following trends.

But this particular trend started from an effort to push things client-side
for good reasons that are vital, or at least useful, to many projects. It
being trendy doesn't necessarily mean it is wrong! Don't be so fast to dismiss
something because to don't immediately see/understand the benefit.

There is often some confusion between "mobile first" and "offline first" \-
the two overlap considerably but being a good mobile app doesn't absolutely
necessitate being able to operate offline and offline capability does not
require or imply an app will be usable on mobile (it may be to large and/or
fiddly in terms of UI on a small screen, not practical to use in a touch
manner, or too demanding of CPU and memory resources). Some of the hand-wavey-
ness is people who _know_ they are driving for "mobile first" and _think_ that
means they _have_ to drive for "offline first" without really understanding
the benefits & implications of that.

~~~
MustardTiger
You are responding to a strawman. I said nothing about the trend, much less
dismissed it. I addressed the reasoning I've seen people use exclusively to
push for it.

------
meshko
It is scary how most commenters here are missing the point. No, not all
programming sucks. Yes, web programming sucks more than other things. No, it
doesn't have to be like this. Yes, even web programming was better 10 years
ago. No, I don't know how to fix it. Neither do I know exactly where we took
the wrong turn. One of my theories is this: had Sun not sued Microsoft over
their extensions in JVM, MS would have kept working on their awesomely fast
JVM implementation for Windows. That would make Java fast and not sucky in
browsers. It would have kept Java Applets as a viable rich web app development
option. Flash would have never risen. Java, being a significantly superior
language to ActionScript, would have allowed us to build nice RIAs in an
efficient, secure and portable way. Gmail and Google Maps would have been
implemented in Java. Isometric Java. Get it? Get it? Back end and front end
are written in the same language with strong typing and all that. JavaScript
would have been dead by now. World would have been a better place.

~~~
segmondy
I'm sorry but I beg to differ, web programming 10 years ago was a nightmare.
It's much better today. It's not web programming that sucks, it's programming
with others. I bet most people won't complain much if they got choose what
tools they wanted and worked alone. When working with others, different ideas
and opinion clash heavily. Programmers are not best known for their awesome
communication and the lack of it leads to more mental strain than necessary.

The reality is that one can drive the frontend with 100% javascript no
frameworks, html, css, keep things simple avoid the framework nightmare. Use
typescript if the project is large enough. How come people are not doing this?
Because they are not putting in the time to learn the language, it's all about
learning framework. I see the same in backends, people who know rails but not
ruby, laravel but not not enough php, android framework but not enough java.
This is the problem.

~~~
314
I maintain a web-application by myself: I choose the platform and exactly
which bits I wrote myself, and whre I pulled things in from other sources.

It still sucks. The target environment is undefined. In most programming
problems we start with with a well defined target environment (or at least the
language semantics are well defined and we quickly learn where the platform-
specific hacks are).

In web programming each of the browsers is slightly different in about a
hundred different ways. The main goal of using the web (presenting a platform
independent UI without needing to download native code) is not entirely
achievable. Instead, each year we apply slightly different hacks to go around
in circles.

~~~
kowdermeister
> The target environment is undefined.

Nope, that target environment is a responsive, standards compliant software.
Code for the standards and the displaying devices will catch up.

~~~
Nadya
Something largely only possible in hobby projects unfortunately.

On hobby projects I support only standards. Your browser not to spec? Not my
problem. Well, it would be my problem, due to less traffic from people with
broken browsers, but I don't monetize or track my traffic.

Professionally, I'm over here supporting IE8 and _Safari 5_ (the last version
available to Windows) still. Next year we'll finally be dropping IE (all
versions) so only a few more months to go.

Unfortunately if something is broken in Chrome or Firefox - I get to fix it.
Then when the browser finally fixes it - I get to go fix it by removing the
old fix which now breaks things. Really unproductive but I can't argue against
it.

~~~
fauigerzigerk
All true, but imagine you didn't have these browsers sitting between your code
and the native OS. Would that be any cleaner?

At least browser vendors do try to conform to some common specs and any
deviation from the spec can be bridged using JavaScript libraries.

Without browsers as a target you might find yourself supporting ancient
Android versions and Windows XP.

------
buzzybee
Web programming has never been wholly controlled by a platform owner. I think
that's the main difference from any traditional environment that might come to
mind; Unix has its traditions, so do Windows and Mac. This is even the case
for mobile. In the years when IE was the only browser anyone used, one could
also hope to come to grips with its buggy CSS implementation, but that is past
too, and in the meantime the backend was still churning from Java and the
classic LAMP stack towards Rails and Python.

This is the end result of uncoordinated, path dependent "bazaar" dynamics
where the core technologies are open, yet keep accumulating cruft, and are
subject to regular proxy wars between large entities. The solutions today are
better in that they are easier along certain axes - you can make a cookie-
cutter landing page out of the box with Bootstrap, or add some interactive
data viz by employing D3. For any random one-off there is an npm package that
depends on 50 other packages. They mostly aren't there to help you architect
your own thing in a self-consistent way, though - that's too much of a
"vitamin" and not enough of a "bandaid" to be marketable.

~~~
flukus
I'm not sure if the bazaar really applies. In the bazaar you have a range of
options and can pick and choose what suits you, but on the web we are
seemingly stuck on a few base tools (html js, css) that have so much momentum
that the will never go away. You don't get a restriction like that on the
server or desktop side.

~~~
majewsky
That's just the platform. If you look around the operating-system bazaar, you
still have some basic notions that are shared among all of them (e.g. all
their VFS look basically the same). That's the role fulfilled by HTML/JS/CSS:
a hardware abstraction layer, if you will.

------
troels
My theory is that everything is a mess, once you get close enough to notice.
Every profession that appears as if its practitioners know what they're doing
really is a shocking hodge-podge of temporary solutions, strung together by
proverbial duct tape. From doctors to flight engineers to anything else that
you thought was running like a smooth machine. Programming is no different.

~~~
thwllms
Agreed. I was a civil engineer (specializing in water resources) before I
became a full-time software developer. The science of hydrology/hydraulics is
largely a messy pile of educated guesses, statistical relationships based on
embarrassingly small datasets, and highly generalized models.

~~~
Kalium
The more of engineering I see in general, the more surprised and impressed I
am that anything works at all.

~~~
cbHXBY1D
One of my friends, who is a new developer, and I took out a new Tesla for a
spin and the whole time he was saying his time as a programmer makes him trust
Tesla's self-driving software. My reaction was closer to "I've worked for some
of the Big 4 software companies and my time there makes me not trust any
software."

------
broodbucket
Honestly, pretty much everything is hacks on hacks. As a kernel hacker,
hardware is hacks, firmware is hacks, kernel is hacks, it's turtles all the
way down. The fact that anything works at all is a miracle. Some systems are
better than others, but everything has some duct tape somewhere.

Designs and algorithms are abstract, the implementation is never as nice. We
as engineers have to make the best of what we have, and to prevent making the
situation worse to the best of our ability.

~~~
cbHXBY1D
Could you go more into why hardware is hacks?

~~~
tonyarkles
I've definitely encountered hardware peripherals that are totally broken and
had to be fixed in firmware.

------
Uptrenda
Technical:

* Multiple browsers that respond to the same code slightly differently.

* Multiple platforms that all need to be supported.

* Countless different screen sizes to consider.

* Standards that aren't supported across browsers and platforms (and different versions of each in use)

* Hundreds of undifferentiated web frameworks that all claim to do the same basic task better than each other.

* Thousands of ways to host, distribute, and scale your application.

* Millions of ways to monitor service availability.

* Billions of ways to create APIs for your service.

Professional:

* Too many technologies and skills needed to do the job.

* Design skills required if you want to create anything significant by yourself.

* The average web developer is practically an encyclopedia of technology yet full stack developers are still undervalued, low-paid, and mostly replaceable.

tl; dr: It takes a very special kind of person who doesn't immediately develop
serious neurosis working as a web developer today.

~~~
kowdermeister
No, it just takes experience and a healthy amount of curiosity. I can handle
these types of challenges.

~~~
talmand
Experience is not always valued in the tech industry.

~~~
collyw
People here always seem interested in my 14 years of experience but want to
pay me closer to a junior / intermediate salary.

------
kinkdr
Without specific examples on what your frustrations are, my best guess is that
you are just overwhelmed.

It was not long ago that I was in a similar situation like you, all these
overlapping technologies looked unnecessary and redundant. Just the node
ecosystem by itself, felt like a pile of crap that depended on a bigger pile
of crap. For a simple application like "hello world" in React, I have to
choose between a large number of possible combinations of packages and install
and configure god knows how many of them.

But once you take sometime to adjust and familiarize yourself, you discover
that each one of them is a little jewel and are the quite opposite of crap or
hack you initially thought. At least that's the conclusion I arrived to.

So, my advice is to just take your time to familiarize yourself with as many
technologies as you can in every aspect of web development. After the initial
shock, you will start appreciating things and you will realize that they are
made by excellent engineers and each has its own merits.

~~~
barefootcoder
That may be, and some of my frustration may come from being thrown in the deep
end in a very large project that uses a lot of different technologies -- it
seems that every other page is using a different framework -- it's a lot to
learn all at once.

------
xg15
I think the "design notes" section of the HTML5 spec puts it best [1]:

 _It must be admitted that many aspects of HTML appear at first glance to be
nonsensical and inconsistent.

HTML, its supporting DOM APIs, as well as many of its supporting technologies,
have been developed over a period of several decades by a wide array of people
with different priorities who, in many cases, did not know of each other's
existence.

Features have thus arisen from many sources, and have not always been designed
in especially consistent ways. Furthermore, because of the unique
characteristics of the Web, implementation bugs have often become de-facto,
and now de-jure, standards, as content is often unintentionally written in
ways that rely on them before they can be fixed._

Long story short, HTML and its satellites have quite a long history behind
them, involving trade wars, religious battes and one or two revolutions (or
coups, depending on your point of view)

I think the unique thing about the web "stack" is that for a long time it was
the only platform usable and accessible by everyone and controlled by no
single entity. This means there was a tremendous amount of people, companies
and other entities that tried to influence it's design. Because background
compatibility is an absolute must, this lead to hacks accymulating and the
whole language getting incredibly messy.

From what I know, there has been at least one approach to start with a "clean
slate" and design a better framework - XHTML 2 - but it failed due to missing
backwards compatibility and a lack of political support.

The organisation currently in charge publishes the "HTML living standard"
(formerly known as HTML5) and has given up on most notions of cleanliness
(short of declaring it an explicit non-goal) in favor of backwards
compatibility and the ability to move fast.

[1]
[https://html.spec.whatwg.org/multipage/introduction.html#des...](https://html.spec.whatwg.org/multipage/introduction.html#design-
notes)

------
mashlol
You can't really compare "web development" to "application development". I
think it's more fair to compare a single web framework with a single native
framework. The web ecosystem of frameworks is much larger, meaning there are
far more options, much more to adapt to if changing projects. Switching from a
well-written iOS codebase to a well-written Android codebase would be no
different then switching to a well-written React codebase.

> I've been doing some web development on a fairly long-lived and large code-
> base

Perhaps it's just not a well written codebase. It's extremely easy to write
bad code for web, where perhaps it's slightly harder to do for native
development (although still very easily possible of course). It's also very
possible to write good maintainable code for both as well.

> I'm not even talking about the fact that everything has to be stateless

It doesn't have to be stateless. Take a look at React.

> just the fact that it really feels like there's no consistent way to do
> anything

That's pretty much the same with application development. Perhaps not as much
for Android/iOS themselves since there is basically only one option for each
of those. Even within those there are many many ways of doing everything. It's
up to everyone working on the codebase to keep things sane. That's no
different with web development.

------
flukus
I think it got particularly crazy around the creation of npm/node:
[https://www.commitstrip.com/en/2016/05/10/a-moment-of-
nostal...](https://www.commitstrip.com/en/2016/05/10/a-moment-of-nostalgia/) .
This was an enabler for complexity to spiral out of control.

~~~
bikamonki
I give it to you: npm is a Gran Bazaar mostly selling crap....but Node is
brilliant.

~~~
copperx
I have been waiting for the dust to settle on the "Node is the worst idea of
mankind" vs "Node is brilliant" before taking a look into it.

~~~
flukus
The amount of breakages I get using my static site/blog generator has my
leaning toward worst ever. If that's any indication then anything actually
complicated would be breaking all the time.

~~~
jazoom
This doesn't sound like a NodeJS problem.

~~~
talmand
It's a common problem; someone or something uses the tool badly, blame the
tool.

~~~
goatlover
I wanted to blame Brainfuck, but I realized it was me, not the tool.

------
OliverJones
With respect, at least part of your frustration comes from the "curse of the
installed base."

Long-lived software with real users in any language running on any platform
becomes complex, and picks up strange-looking appendages. Sometimes those
appendages are nasty hacks, and sometimes they are well-built. But they are,
in most cases, necessary to the proper functioning of the software, and
responsible for its success with its users.

That's true of long-lived human work product in any discipline. Look at a
municipal utility map sometime, and then consider that it is probably at least
three decades out of date. That's why utilities send out "dig safe" guys to
construction sites. That's why things go wrong in utility work after longtime
engineers retire or die.

That being said, the capabilities in web browsers are definitely the utility
company equivalent of of a pickup truck full of random bolts, pipes, wires, a
shovel, a ladder, and a jackhammer. You can do many things badly with a web
browser, and our ways of doing them badly have evolved over the past couple of
decades.

I believe your frustration with aging web software is, in fact, a sign that
web software has become generally useful to the population.

~~~
Klathmon
It comes back to that wonderful quote by Bjarne Stroustrup:

"There are only two kinds of languages: the ones people complain about and the
ones nobody uses"

~~~
goatlover
It's apropos that the creator of C++ would say something like that. I wonder
of Alan Kay, John McCarthy or Guido van Rossum would agree.

------
elg0nz
" In Richard Feynman’s popular book “Surely You’re Joking, Mr. Feynman!” he
tells how during his college years he “often liked to play tricks on people”.
Most of these tricks were designed to show how dumb people are. For example,
in a mechanical drawing class at MIT where the students were taught to use a
drawing instrument called a French curve (a curly piece of plastic for drawing
smooth curves), Feynman informed the other students that “the French curve is
made so that at the lowest point on each curve, no matter how you turn it, the
tangent is horizontal”. He reports that the other students in the class were
excited by this discovery, and began holding up their French curves and
turning them in various ways, trying to verify that the curve was always
horizontal at the lowest point. Feynman found this funny, because they had
already taken calculus and supposedly learned that the derivative of the
minimum of any curve is zero. (Of course, it’s also intuitively obvious: If a
curve at a given point is not flat, the point is obviously not the minimum.)
Feynman says “I don’t know what’s the matter with people: they don’t learn by
understanding; they learn by some other way – by rote or something. Their
knowledge is so fragile!” www.mathpages.com/home/kmath687/kmath687.htm

"Easy to begin, hard to master" languages/frameworks let you go very far in
spite of your knowledge fragility. Some interesting topics to reduce this
fragility are data structures, design patterns, software and hardware
architecture and, distributed computing.

If I had a penny for every JR. Dev that thinks they can get around the CAP
theorem...

~~~
barefootcoder
Somehow I feel like this comment is meant to be directed toward me (OP), but
am struggling to see how it applies to what I was asking. In fact, I
specifically asked for resources to assist me in orienting my mind to the web
development way of doing things.

Perhaps I've misunderstood and you're actually directing the comment at the
hodge-podge of web frameworks that don't seem to follow the principles of
design that other languages do?

~~~
elg0nz
The main point I was trying to get across is that most software is indeed
Hacky, not because Computer Science is terrible, but because the people who
made it don't have a solid understanding of many fundamentals. They've taught
themselves to "program in 21 days" and later have a hard time understanding
why things break.

Peter Norvig said it better than I can, becoming a great programmer takes 10+
years. [http://norvig.com/21-days.html](http://norvig.com/21-days.html)

Data structures, design patterns, software & hardware architecture and,
distributed computing are subjects that all engineers should be familiar with.

For example, the question whether to use NoSQL or SQL is another way of asking
if you need to use a Hash or a Binary Tree.

Bad engineers pick one or the other based on Marketing or White Papers, Great
Engineers pick the right one based on understanding how their algorithms will
use that data and why there are no silver bullets.

------
BerislavLopac
> I've always found it quite easy to move up and down the stack

This is the most important point that most people overlook: the Web doesn't
have a single stack, even though we talk about "full stack developers" and
similar. Web is your ultimate distributed system (which is why you have no
other option but to make it static); you never develop a single application,
but a multitude of applications often (usually, in fact) executing on systems
you have next to no control over.

Just think of your quintessential "Web page": a server prepares an HTML page
which is then rendered in a browser. First, you have a server, which you
rarely control (unless it physically sits on your desk/rack, and even then
you're at mercy of your ISP). Second, even assuming the page was served
correctly, it then arrives to another system which has OS/browser/display/etc
which you have absolutely no control over except for hoping that it adheres to
all the standards you have adhered to when developing. Even if there is no
client-side code (i.e. Javascript) to be executed, even the simplest HTML (as
well as CSS) are instructions that need to be interpreted.

What you call "hacks" are essentially numerous solutions -- some good and
others less so -- to inherent problems of distributed computing, working
around the peculiarities of the underlying platforms (namely HTTP and TCP/IP)
to ensure reliability. Many things that are taken for granted in platform-
specific development simply don't exist here; as a reminder, take a look at
[https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing)

------
msoad
I don't know what are you referring to as hack on top of hacks? There are tons
of big open source and closed source web based project that are easy to follow
what's going on and everything is well structured. Look at VSCode code base
[1] or if you're a Googler look at Google Photos source code.

People look at React and Webpack and all these small little modules that
people put together to make something work and think that's all the web is.

Although, I think React, webpack, Redux and all these little hacks are amazing
for exploring what's possible in web.

[1]
[https://github.com/Microsoft/vscode/](https://github.com/Microsoft/vscode/)

~~~
voltagex_
I think the question then becomes: How do I make my code more like VSCode and
less like, well, everything else?

I'm not sure the answer is as simple as "use typescript".

~~~
onion2k
Using a meta-language like Typescript (if it's appropriate), and writing a
sensible number of tests, employing a consistent code style, documenting what
you write, and spending time to actually _design your software_ properly is
the answer.

You can write good software in any language and on any platform. Good code is
more about your processes than your choice of tools.

~~~
TranquilMarmot
Thank you! So many people here blaming the tools for bad software when people
have been using horrible tools to write good software for decades. I think one
major part of why React + Redux are successful is because they sort of force
you into a way of thinking that results in a better creative process and ends
with better code.

~~~
voltagex_
>they sort of force you into a way of thinking that results in a better
creative process and ends with better code.

That's the first time I've heard that about React, can you elaborate?

~~~
TranquilMarmot
Maybe it's just me, but when I'm working in React it really forces me into a
more "modular" way of writing things. Sure, I'll write something as a huge
file that's a couple of hundred lines but React makes it _incredibly_ easy to
step back and refactor to start pulling things out into modules.

I guess it doesn't quite _force_ you into thinking a certain way, it just
encourages writing code in a more modular and reusable way. Refactoring is
easy enough to say "yes, I should pull that out into its own component" vs "it
would take me a day to pull this out into its own component".

~~~
midwestcode
Totally agree with you here. React made me think of the web in a very modular
way... I found it very enjoyable to learn!

------
jorblumesea
While I hate css, sort of like js and hate html layout, a lot of the problems
come from accessibility. In that, it's so accessible anyone can do "web". This
means you get non-engineers with no engineering background put into situations
where thinking about things from an engineering perspective would really help
and might produce actual workable solutions.

Like wtf is this:

[https://www.npmjs.com/package/string.prototype.endswith](https://www.npmjs.com/package/string.prototype.endswith)
[https://www.npmjs.com/package/ensure-string-
endswith](https://www.npmjs.com/package/ensure-string-endswith)

str.slice, str.indexOf are standard lib. Adding another layer of complexity
for basic string functions that could easily be done natively is very poor
form. This kind of stuff happens all the time in the web world. There's a
layer of "lack of competency" bootstrapped on top of what I would consider a
non-intuitive base.

~~~
roblabla
Errm...

\- "test".indexOf("st") == "test".length - "st".length

\- "test".enddWith("st")

Am I the only one who thinks the second one is WAAAY more readable? And that's
a COMMON function. Using the former is bringing complexity UP.

Not to mention, endsWith is part of es2016 I believe. So this package is just
a simple polyfill.

~~~
EnigmaticLion
> "test".indexOf("st") == "test".length - "st".length

I don't think this is a correct implementation of "endsWith".

"testtest".indexOf("st") =/= "testtest".length - "st".length

~~~
roblabla
Good point. Should have been

"test".substr("test".length - "st".length) === "st"

Or is it substring? Might there be an off by one in there? Anyway, this kind
of reflexion only proves my point. There's no reason to question what endsWith
does, because it's obvious. It's the correct abstraction in many cases.

~~~
pablovidal85
Negative substr() already does the trick, I don't see the need for endsWith()
at all.

    
    
      'test'.substr(-'st'.length) === 'st'

~~~
roblabla
The thing is :

1\. You need to know and understand obscure behavior of substr

2\. This hides the programmer's true intent. What you want is to know if the
string ends with 'st', not that "the 'st'.length last characters of the string
is 'st'". Why make it harder on your fellow coworkers to understand what you
mean ?

If you only do this once, sure, maybe importing a whole module is overkill.
But as you write it over and over again, in separate projects, having the code
safely tucked away in a reusable module brings complexity down.

------
27182818284
Yes, yes, a thousand times yes. I completely agree with you.

John Carmack also agrees with you, though not about the web per se:
[https://twitter.com/ID_AA_Carmack/status/771749108780523520](https://twitter.com/ID_AA_Carmack/status/771749108780523520)

This is how I feel too. If I had to put a finger on the root cause, it is
because of the speed demanded. E.g., going back to the left-pad problems that
happened in the Node ecosystem, I know lots of folks that know how to do that,
but when speed comes up and they can just add a package, that's what myself
and others are often going to do.

------
kowdermeister
> Am I missing something?

Probably. Good folks to learn from.

> Is it me resisting change?

Only you can tell, but client side web development is fine, thanks :)

> Is web programming really that bad?

No, it's doing fine, thanks for asking.

> Is it really just that I need a new mental paradigm?

If you really want to take your time working with client side projects, then
you need to relax a bit and just learn a bit more and play a bit more with
these techs. Some you'll hate, some you'll love. That's it.

I don't really understand why is this hate against web development goes on HN.
I'm building web apps for lots of years now and the major obstacles were never
really the technology, but money or people.

Building UI-s in the browser with CSS is not a rocket science; a JS app is
easily scalable to 100k lines of code; backend wise you need some good team
and a sane PM who don't want to immediately scale your app to Death Star
level. Projects does get fucked from time to time, but if you picked your
stack well, you'll be fine. I admit it takes experience to identify the crap
tools, but what profession doesn't?

~~~
Klathmon
I don't get it either. Nothing in history has come close to the current web
platform. There has never been a language/runtime/framework/system where you
could have this much flexibility, that "installs" in literally seconds (from a
cold cache, never having been there in the first place), and works on every
platform under the sun (not just linux/windows, but mac, android, ios, windows
phone, ubuntu phone, my TV, my car!).

I see people in this thread talking about how it takes them 10X longer to
develop for the web than it did for a desktop system, and i'm just sitting
here confused as for me it was the exact opposite. I remember having to setup
a development environment to get a java swing application ready to start
working on. I remember the goddamn readme I needed to write to ensure that the
next developer working on my GTK+ project had the right environment, the right
libraries, the right platform, and the right compiler. I remember having to
find some bullshit bindings to a C library for my python project that really
half-assed the implementation, but it's all I had because that C library is
the "defacto standard" for what it does, so I need to just deal with it.

For me the web has been such a breath of fresh air. A package system that
works so effortlessly that I don't need to spend an hour deciding if that
package is worth the pain of setting up another virtualenv, I don't need to
worry that this library only supports Java 6 while this other one only
supports java 7 and I can't have both (even though I only need the Java 7 one
on this project). I don't need to worry that the next version of Windows will
break GTK and my project won't support that platform and there is nothing I
can do about it.

I run `npm install`, and in a few minutes, every developer with node.js
installed can compile, run, modify, and deploy my code. And when deployed,
every person with a browser on the planet can run it in seconds. It's amazing.

~~~
goatlover
I think it's when you get beyond the niceties of the delivery system that is
the web to making complex apps compared to other environments is where the
complaints stem from. Also, the JVM, Flash and Silverlight would have have all
been able to provide a similarly nice delivery system across all platforms if
they had been the equivalent of the web. But instead, they were used as
plugins.

~~~
Klathmon
But i'm talking about complex applications. I'm not talking about your average
website, but full blown 100k+ loc applications. It's so much nicer than the
alternatives that many developers are making desktop-only applications using
those technologies. I don't know if that is because of familiarity, or if it's
actually a better platform, but I know that when I did the "move" from GTK and
swing applications to HTML/CSS/JS based applications, i instantly became
almost a magnitude more productive.

And I don't buy that JVM, Flash, Silverlight, or any of the others could have
been able to provide something similar (or better) that the web world. The
biggest benefits of the web ecosystem currently are NPM and the "runs
literally everywhere". The JVM/Java ecosystem is closest in that area, but
that story gets really ugly when it comes to cross-platform UIs and startup
time. And while they could have created their own system that installs/runs
instantly without needing complex permissions, without needing to "install" at
all, automatically cleans itself up, and can be accessed from anywhere in the
world by a simple string, they didn't. Flash/Silverlight tried, but in the end
they ended up just being worse versions of the js world (remember the damn
loading bar that every single flash application needed for some reason?)

Like it or not, the web nailed all the right things, and it became pretty much
the most used platform over the course of a few years. Not by accident, but
because it did something right.

~~~
goatlover
Keep in mind that JS is leverage the browser, which gets installed everywhere,
and because of a persistent push to standardize, delivers mostly the same user
experience across platforms these days.

My point was that Java, Flash or Silverlight could have done the same if you
replace the browser with a similar platform in those ecosystems. JS is getting
to leverage the powerful browser platform with native integration, while the
others were mere plugins.

Would be very different if the browser was a JVM based platform.

~~~
Klathmon
But they tried, and for the most part failed.

JRE is difficult to manage and maintain, and security wise is a nightmare
compared to javascript (would you run random .jar's from any website?) Adobe
had multiple attempts at a "browser-like" runtime for flash, none of which got
all that far (although the Adobe Air system has done pretty damn well, and is
actually still alive and kicking).

It could be any number of reasons why web won over the alternatives, but I
just don't think that it won because of a mistake, or a fluke. The web was
doing something better than the others, and while I can't exactly pinpoint it
(hell, it probably isn't any one thing), it is winning.

And i'm in no way saying it's perfect. There are a ton of things i'd change
about it if given the chance. But you can't just act like it's a horrible
platform and that we should start over with something better (like many
commenters in this thread and across the internet in general are saying).

------
MrLeftHand
I feel the same thing to be honest. As a mostly Backend Java guy I just have a
hard time to get my head wrapped around the whole Frontend/SPA thing and the
multitude of frameworks, styles, tools and so on; just don't help at all. It
feels like everyone is reinventing the wheel constantly.

Right now I try to write a simple react SPA and I use more libraries as if I
would have done it in a tomcat webapp with static html pages.

Documentation is relatively scarce or non-existent at all and in the end you
end up looking at code on github. Hunting on Stackoverflow and blogs written
by people and realize that there are 100+ ways to do the same thing.

Looking at code would be fine, but looking at Javascript it's hard not to see
how easy it is to write in different styles, which makes understanding the
things harder. Also being in the middle of transitioning to ES6 makes it more
complicated. Of course ES6 will be a big leap, but ES5 won't go anywhere
anytime soon because of backward compatibility. So you will end up with
overlaps and weird code.

Sass definitely helps with css. React is a great way to develop nice SPA sites
webapps.

I don't know if the whole Frontend part is going in the right direction, but
it will need some time to settle. For now it's more fragmented then the
Android platform. And it really feels like we are trying to put a lot of stuff
on top of protocols, tools and standards which were never meant for this in
the first place. We might end up having such big scripts loaded for a page,
that it could have been just a thick client instead of a web page.

We threw away Java Apps, we threw away flash, we are throwing away jsp/jsf,
PHP, etc... And now we are recreating the same behavior with
Javascript/CSS/HTML5. Soon it will be only Javascript and you literally won't
write not a single line HTML. (Well React already does that to be honest.)

So yeah, interesting times. And it's hard to jump on this train whilst it's
moving so fast.

~~~
vonmoltke
I'm coming from a similar position as you (trying to merge a hodgepodge of
Swing, AWT, JSP, and Rails GUIs into a coherent, modular frontend) and running
in to the same problems. I built one application with Angular 1, which had
good documentation but seemed to be overcomplicated and had too much "magic"
going on under the hood for my liking. I'm now trying React; the main React
documentation is great but the documentation for supporting libraries is
horrible. I have also encountered the problem of every example doing things
differently, highly-opinionated tutorials, and (as I mentioned elsewhere)
everything seems to be a slightly different alphabet soup of supporting
packages. It has been hell for someone who normally tries to find the "best"
way to do things.

------
soheil
I'm not sure what you mean by "a new mental paradigm", the web is a complex
system you cannot expect it to be completely reducible to a few simple
constructs. You generalize the word backend programming as if it's just one
thing. There are hundreds of ways to program a backend system, you can choose
from .NET to C/C++ and rarely they are hack-free as you suggest that's not
even to mention the platforms they run on like for example BSD, Unix is a
series of hacks on top of others, there are often 1000s of different ways to
do the same thing.

I simply don't buy your point that "backend" environments are somehow more
elegant to work in and easier to reason about than the web.

You still have to decide which backend platform you choose and each has its
own series of convoluted hacks associated with it.

------
hannob
Yes.

I got this realization during a study project where I investigated the use of
secure cookies (was 2009, it's public [1]). It's just one example, but you can
find similar things everywhere.

Sessions in Web applications are realized using cookies, which is not a very
good way, because once someone manages to steal your cookie your session
management is broken. And there are plenty of ways to do that, because there
is no good separation of the session from the rest of the functionality.
Because both cookies and sessions weren't in the design of http/html before,
they were a later addon that. So was javascript. So were many other things.

The thing you have to realize though: Things work. It's been the most
successful technology of the past decades. There is no point in moaning that
things would be much nicer if we'd redesign them from scratch, because it
isn't going to happen.

[1] [https://blog.hboeck.de/archives/681-Study-research-
project-a...](https://blog.hboeck.de/archives/681-Study-research-project-
about-session-cookies,-SSL-and-session-hijacking.html)

------
Svenskunganka
I think the problem boils down to how the different browser vendors has
treated web developers throughout the years, not giving them a consistent
environment across the different browsers, not recognizing certain bugs so
they've lived on and become un-fixable due to backwards compatibility.

Microsoft with their IE has been the biggest culprit in this, luckily they've
taken Edge in the right direction and has really stepped up their game these
last two years, but now Safari is at a crossroads and may just end up like the
old IE if they take the wrong path. If only the large browser vendors could
really, really get together and give us web developers a consistent
environment without bullshit. Take Apple Safari for example, keeping Service
Worker "under consideration" because the features it brings rivals native
mobile apps which they make a lot of money from while all other "large"
browser vendors has already started implementing the feature, some even ship
it already.

------
aabajian
Some people have already mentioned GWT. I think this is the best evidence that
yes, web programming is extremely hackish. GWT is an entire framework to write
web applications in a strongly typed language - it compiles Java down to
JavaScript. GWT was made in an era that we're just now escaping: the era of
browser quirks.

IMHO, GWT didn't take off because of one reason: Its target demographic, web
developers, do not have the same technical training as traditional computer
scientists. What I mean by that is courses at places like General Assembly,
CodeAcademy, and even KhanAcademy emphasize JavaScript/CSS/HTML paradigm. This
triad makes it easy to create very nice looking website in very little time,
but there's little focus on code organization, software design, efficiency,
etc. It's much more of, "Now we want this box to fade out when we click on
this button, let's see how we can write a function that makes this happen."

~~~
ng12
> Its target demographic, web developers, do not have the same technical
> training as traditional computer scientists

I think this is the money quote, and the reason why this thread is full of
such ill-informed opinions.

I have a degree in CS. I've done systems programming, devops, and mobile
before settling on web. Just recently I joined a company of very strong back-
end people with a severe dearth of people who have any knowledge or interest
about web. The web doesn't have to be that bad -- just for some reason, it's
the orphan child """real programmers""" don't work with.

~~~
prewett
As a Real Programmer who started his career right when the web took off, I can
tell you why. At first, web apps were CGI scripts, so back-end only. But most
of the jobs were in native applications. At some point you play around with
interactive web page, and the DOM is a mess, browsers all behave differently
and you give it up in frustration. Swing, Qt, Win32, are all not bad, and act
quite predictably. Then you see web apps start coming, but they are slow, and
you still have that bad experience from earlier. Then you start reading HN and
notice that every six months the new thing changes, and you say, "hm, Swing,
Qt, Win32 don't need to change all the time, something about this web app
stuff smells like Done Wrong," and you avoid it like the plague. And when you
talk to your non-profit friends who are setting up an online store, they are
all hiring some guy to do it in WordPress, and it takes 7 seconds to load, 50+
JS files, and 30+ CSS files (I kid you not), and you don't even want to talk
shop with that kind of developer.

------
gfody
There are billions of dollars made annually that depend on the web being a
complicated clusterfuck of spaghetti. It's all about tracking and targeted
advertising that wouldn't be possible if a random website couldn't indirectly
load a script that indirectly loads a script that loads an image that
indirectly drops cookies from a thousand different domains based on a hundred
things just sniffed from your browser and the current marketing efforts of
thousands of companies bidding for impressions or clicks or whatever.

My pet theory is that commercial politicking is at the heart of everything
wrong with the web. Apple, Google, Microsoft, and Mozilla basically sabotaging
initiative after initiative for decades trying to fuck each other over in the
short term and long term. Like why didn't xhtml catch on, why did IE never
support xpath, where did flash go, what happened to silverlight, there are
hundreds of "how did we get here?" stories. And I imagine for every minor
decision that had far reaching repercussions on web development there was a
highly strategic debate at each respective company with high level executives
weighing in on technical subjects they had no business weighing in on with
shit like "if we support this simple protocol we risk losing our control over
this other simple protocol". Basically a bunch of cut throat executives
playing statecraft with their browsers.

~~~
phillias
Huzzah. Puppet would be recognized for the degenerate mess it is if it wasn't
marketed so well. I know everyone has the best intentions, but brogrammers,
tech savvy sales and marketing rejects, were the death-knell of quality at all
costs. It was hard enough before, but money has ripped the guts out of a fine
institution.

------
intrasight
Sometimes I ask myself the question by doing this thought experiment. If we
encountered a more advanced sentient species that writes code, would they say
"Yeah, we went through that html/css/js phase of development, and in fact all
sentient species do so. We got some good mileage out of it, and it was a total
hack for a generation (we refer to that time as the lost generation), but it
evolved into our current 'System X' for user-facing app development. Due to
the Prime Directive, we can't show you what 'System X' entails. You'll just
have to evolve there yourselves."

Or, would they say "You guys are bloody idiots. Come back when you shopped at
the galactic clue store."

~~~
copperx
That's too easy. We all know that in the ideal world, platform-independent
code would travel through the pipes instead of HTML/JS. That code "plug" into
an existing architecture in the client side to provide some service or
functionality transparently to the user.

Why don't we have that? mostly because of security concerns. That's why we
can't have nice things.

~~~
intrasight
Platform independent code would be no more insecure than the current scenario.
In fact I'll claim that it would be more secure due to reduced attack surface
area.

This HTML/JS/CSS scenario evolved. It wasn't designed. If you started with a
clean slate and designed the front-end, would you have something completely
different.

I'll make another claim that I'd be interested in hearing feedback from
others. If IBM had allowed CMU to make the Andrew Window Manager FOSS in '88,
we never would have gone down the HTML rabbit hole.

------
joemi
There are a lot of articles out there arguing that the web wasn't designed
with modern web apps in mind, and that that's a source of a lot of strife, so
you're not alone in this feeling. But there's also a lot of articles that
argue that that even though it wasn't designed with this kind of use in mind,
that there are ways it can work well.

Out of curiosity, what's your stack look like? Not all stacks (or components
of the stacks) are created equal, by a long shot. Some devs love to try out
brand new or new-ish frameworks/dbs/etc that haven't got all the kinks worked
out yet, simply because it's the new hotness.

------
Beltiras
I think you come to the conclusion because necessity is the mother of
invention. Web development is often done in a high-pressure environment with
great focus put on churning out features. This leads to the hacks-on-hacks
mentality because the needs of the day trump any sort of coherent principle
emerging from thoughtful work on the codebase.

I resided over a medium sized custom CMS that was going through changes on all
levels. I tried my best to keep it pretty. Fact it was made with Python made
it easier for me. Due to that I was quick to find aesthetics to guide my
coding. One of the "ugly hacks" actually turned out to save some 50 ms of time
on each request. That was significant enough for me to go find a deeper
principle for it and implement it in a nice, clean way.

Hacks-on-hacks is SNAFU for web development. Just remember to demand time to
refactor and clean up once in a while, otherwise you'll end up shoveling shit
from one pile to the next and never managing to vacate it.

------
BjoernKW
Isn't everything? With web programming that's very much a feature, not a bug.
You could say that Perl's - the first major web back-end programming language
- TIMTOWTDI paradigm is a feature of the web itself.

MFC, Swing, Cocoa, Qt all offer more or less consistent experiences but none
of those is as flexible as what you get with the web, which also is a feature,
not a bug, because with a certain OS you also want a somewhat consistent,
vendor-independent UI / UX across applications.

That said, if you aim for consistency, there are widely used frameworks and
tools like Bootstrap, Modernizr, jQuery or Angular that can help you in that
regard as well.

~~~
th0ma5
Cars, airplanes, ATMs... IMHO for every well defined standard or torque wrench
tolerance there's a rule of thumb and little piece of tape somewhere.

------
BinaryIdiot
I've done front end work for nearly a decade now. You're right and I think
frameworks are a big part of the issue.

Looking at how to do something on the web there is a different way to do it in
React, Ember, Angular, jQuery UI, Bootstrap, ExtJS, and about 50 more slightly
lesser known frameworks. They don't interoperate well _at all_. Yes it all
boils down to HTML / JavaScript in the end so there is always an integration
point but try writing a component that integrates well in even 2-3 of
frameworks.

Honestly if more people taught solid coding structures and the DOM API (which,
yes it's awkward but with the features HTML 5 brought in plus well structured
code it's not _that bad_ ) you could have a smaller, handful ways of doing
something properly _and_ you could even share components far easier.

Granted frameworks are not the only problem. But, in my opinion, they've
severely splintered the way the web is developed.

------
ng12
I don't know that they're all "horrible" hacks, but yes. We still generally
don't know the best way to build a complicated website. We can't even agree on
the simple stuff -- for example Angular2 and React, two of the hottest
frameworks, pursue wildly different philosophies.

I think it's exciting. It keeps me motivated to learn new things, and really
think about the code I'm writing.

~~~
mirkules
> We still generally don't know the best way to build a complicated website

We do. The web was supposed to be a content-delivery mechanism not an
application-delivery mechanism. The problem is that it was shoehorned into an
application-delivery mechanism, and the lines between content and user
interface were blurred so much that it delivers neither particularly well any
longer.

This quote from Alan Kay sums up my (and OP's) feelings about the web stack:

> The Internet was done so well that most people think of it as a natural
> resource like the Pacific Ocean, rather than something that was man-made.
> When was the last time a technology with a scale like that was so error-
> free? The Web, in comparison, is a joke. The Web was done by amateurs.

~~~
ng12
What makes you say the web was supposed to be about content-delivery? Gopher
was about content-delivery. I don't see how you can make the same claim for
http/html.

I'm not saying the web is great or anything, but it's a little funny to me
that people on a site for "hackers" are afraid to get their hands a little
dirty. Yes, the web was shorted sight (what technology isn't?) but to me the
fact that we're able to use it as an application-delivery system is something
to awe at not complain about.

------
vikaveri
Web development is like the scene from Indiana Jones and the Last Crusade. You
get to pick your poison and there are a lot of people who will choose poorly.
Doesn't matter how good you are, chances are, on occasion, you'll choose
poorly as well.

There's no point trying to read and understand every library and framework
that comes out. HN has half a dozen interesting ones I skim over each week
because what you need to know is what's out there, what's been done, so when
you come across a problem you don't have the tools for, you can come back and
choose the tool that best fulfills the requirements you have at that moment.

And those requirements will change from project to project. There's no cure-
it-all. Expect to switch frameworks or libraries very often. You probably wont
have time to learn all the intricacies of a framework before something else is
more suitable for your needs.

It's not impossible or required to write bad code and have bad design, but
it's easy to shoot yourself in the foot when you don't know what you're doing.
You will see lot of bad design and poor code though, there are a lot of coders
who are starting out with web development because it's an easy place to start
with.

Sometimes you need just a spoon and sometimes you need a fleet of excavators
and the hard part is knowing when to use what.

------
TickleSteve
Yes (simple answer).

but really, its less "hacks on hacks" and more "unneeded abstractions on
unneeded abstractions".

The inefficiency of modern web-stacks continues to absolutely astound me.

When people tout the 'efficiency' of language A against the equivalent C as
being "less than 2x"...

jeez... that means you're throwing away double the power that you need to.
That means you've got _double_ the number of air-conditioners cooling your
server-room. _double_ the power bill, etc...

</rant>

~~~
Crusoe123
...and half the people.

------
nostrebored
There is some stuff that actually makes logical sense, like CSS Specificity,
but yes a lot of it is hacky. I mean, negative margins? Clear? Thirty
different lines of browser-specific rendering tweaks?

WebKit is great, but any attempt to reform the competing browser shitshow
reminds me of that xkcd comic about competing standards:
[https://xkcd.com/927/](https://xkcd.com/927/)

(former web developer -- get out while you have your sanity)

~~~
mirkules
Rather surprised you didn't mention vertical alignment. I mean, this year
marks the 20 year anniversary of CSS. 20 fucking years of not having vertical
align!

(before someone says "flexbox", remember it's still in "working draft" stage)

------
combatentropy

      > a fairly long-lived and large code-base
    

Such could be spaghetti on any platform. To understand web programming, I
wouldn't start with something big and old. I've been doing web programming for
more than a decade, and I still don't get the majority of web frameworks.
Start instead with the basics, and work your way up:

1\. HTML. Don't view the source of websites and web apps to understand HTML.
Read a good book or tutorial. HTML Dog is a good one.

2\. CSS. Likewise.

3\. JavaScript. Definitely don't try to learn JavaScript by viewing source
either. Instead, maybe HTML Dog. There's also Douglas Crockford's _JavaScript:
The Good Parts_ and David Flanagan's masterpiece, _JavaScript: The Definitive
Guide_. I don't know how I would have ever understood JavaScript if I had not
taken the months to read Flanagan's book cover to cover.

That takes care of the client side. For the server side, it should come much
more easily. Basically you have a database, like I'm sure you're used to. Then
you need a web server, like Apache or Nginx, and some kind of glue language
like Python or PHP. Many people put a lot of code here. But I like to keep it
pretty thin: like the database and the browser just talking to each other.
Even so, just running this side of the affair can be a full-time job in
itself.

I recommend at some point familiarizing yourself with the HTTP protocol in
general: all the headers, request methods, etc. Basically once you can use
Telnet to imitate a browser requesting a page, you'll feel more comfortable
with how simple it really is.

------
narrator
>Can you recommend any good resources to help me orient my mind to this new
way of thinking?

The thing about web frontend development is that it suffered from the browser
wars and having to appeal to amateur developers. Amateur developers love
"Worse is Better"[1]. Basically sacrifice all consistency in favor of
simplicity and getting started quickly. "Worse is Better" makes things simple
to the point of making ugly hacks for certain situations that don't fit that
extreme focus on simplicity.

The browser wars made everything horribly inconsistent. Microsoft's strategy
was to make the most broken non-standard code possible automatically work and
everyone had to emulate that.

The most clean frontend development I've worked with was Angular with ScalaJS.
Typescript in Angular 2 should be really clean. The underlying web browser
stuff will never be cleaned up since it has to be backwards compatible.

[1]
[https://en.wikipedia.org/wiki/Worse_is_better](https://en.wikipedia.org/wiki/Worse_is_better)

Edit: Replaced the JWZ URL with wikipedia. Apparently JWZ has some anti-hacker
news redirect code on his site.

~~~
MrJagil
Ok, this is really weird, why did your link forward me to this NSFW page until
i copied the URL manually into the address bar (Again, NOT safe for work):
[http://imgur.com/32R3qLv](http://imgur.com/32R3qLv) Hovering showed the
correct jwz url as well. Is that your or JWZ's doing? JWZ's page has even
retained the imgur favicon (chrome, mac).

~~~
detaro
Because JWZ doesn't like HN and thus has decided to childishly redirect all
traffic coming from HN to this.

~~~
MrJagil
Thought so! Thanks. Guess the web _is_ broken after all.

------
Myrth
I think it feels hacky because it is, and it's natural. And by natural I mean
this is how spontaneous complex systems evolve. Internet is a result of half
of a century of millions of people's contributions for different and often
opposing goals and priorities. For other examples of hackiness take a look at
other complex natural processes, like multicellular living creatures and
ecosystem in general.

~~~
goatlover
But Is hackiness how we humans want to do engineering? I don't think that
biological systems are considered ideal models for building bridges or planes.
Is software different?

~~~
Myrth
I thought we were talking about what we already have, not what we want to
have?

EDIT: Bridges and planes are built by strictly organized companies, with clear
(ideally) leadership and plans. Internet has evolved much less centralized,
and as a result, in a more natural fashion. No one stopping you from
attempting to write a perfect software, but if you want to re-use results of
million man-years of development, you'll have to deal with natural processes.

------
isoos
The best analogy I've seen with regard to code health is that software is not
built, not engineered, rather it is grown. Depending on the technology of
choice, your garden may adopt to different climates, requires different
nutrients, and pleases different audience (or achieves different goals).

From that perspective, JavaScript is a garden where once planted, you can't
change anything in your garden, and pretty soon it becomes inflexible to build
upon old stuff.

The more tools you have, the better of you can get. E.g. TypeScript, and
especially Dart help a lot with tooling (and making gardening fun again). What
you end up with is isolated components that encapsulate their own code, HTML
template and CSS rules. It may be called web component, angular or one of its
many competitor, but eventually that is what brings you sanity.

And speaking of sanity: I've found that "the current hype" is almost always
broken, half-baked, and lacks proper engineering practices. Go figure why...
Use the tool that you enjoy working with and does the job well, and ignore the
rest.

------
kuon
I think one reason is because there are two kinds of web development.

Website dev and web app dev.

I don't think they are mutually exclusive, but website dev is about styling
and navigating into documents. It's stateless and the variety of content is
unlimited. I don't think there is a "problem" here, it works, has good tools
for what it has to do.

On the other hand, there is web app dev, and app dev is messy at present. My
guess is that is lacks governance, it's not necessarily a bad thing, but it
means things are taking time and must prove themselves to gain traction and
become standards.

But yeah, doing something like a calendar input, with really perfect behavior,
where you can navigate the calendar with the keyboard if focused, that is
accessible, works on all device… is insanely hard and not solved by the
platform yet, so everybody try something different.

Also, a lot of people that are more authors than programmers are "hacking"
"app like" functionalities into their website, and it can get messy very
quickly. No pun intended.

------
brlewis
_Lately I 've been doing some web development on a fairly long-lived and large
code-base_

Therein lies the problem. I've been doing web development for 22 years and
it's only just now getting good. React-like apps (I actually use Mithril) give
you a much better understanding of how the app gets into a particular state
when compared to jQuery.

Web programming on your typical long-lived large code base really is that bad,
but start from scratch with something React-like and you'll have a much better
experience.

~~~
ng12
Absolutely. I feel like we're on the cusp of greatness -- between evergreen
browsers, flexbox, Typescript, React/Redux, and Webpack my frontend experience
has never been better.

------
TheAceOfHearts
It's inconsistent, but it's getting better. The tooling has been drastically
improving over the last few years.

There's no "one true way" of doing stuff and the barrier to entry is low,
which causes lots of different ecosystems to evolve. The browser vendors are
trying to focus more on lower-level features, which the community is expected
to use in order to build better abstractions.

I don't think it's worse than other platforms.

It really depends on what you're building. If you're making something that's
largely document-focused, it's extremely easy. But as you start building more
sophisticated applications, the complexity increases.

------
socmag
Yes it is awful.

How people manage to build applications given the festering pile of rubber
bands, glue and fish heads that we call web development platforms these days
is beyond me.

There was a time when even I could build a website. Then I stepped away for a
few years to do other stuff and came back to witness in complete horror where
things are now. Let's be frank, the tooling is abysmal.

I've been taking a look at Polymer, Dart and Flutter recently.

Looking at the goals of those projects I'd say that reading between the lines,
even the likes of Google understand that something has to change.

------
cloakandswagger
The internet as a whole is one giant, hacked together system. There's no doubt
that, with a magic reset button, we could build an internet that is vastly
more secure, efficient and reliable than the current one.

But that's the nature of an emergent, distributed technology like the
internet. Once the concept was born we ran with what we had, and once adoption
hit a certain point it became impossible to start over again and do it
correctly. I see it as an innate challenge that comes with the domain, like EM
interference for electrical engineering.

~~~
SquareWheel
I'm not sure a reset is really necessary. "The internet" is abstracted and
modular enough that parts can be swapped out and improved without needing to
start over.

Internet Protocol is being upgraded to IPv6 (any decade now), HTTP/2 is
replacing the old HTTP 1.x (thanks SPDY!), TLS has replaced SSL, brotli is
stepping up for gzip/deflate. Who knows, maybe QUIC[1] will be next.

Even on the programming side we have new languages entering the fray.
Javascript has recently gotten huge upgrades, and WebAssembly has a lot of
momentum behind it as well.

So on almost all layers we're able to swap in new protocols or technologies
and everything still continues to function. It's actually a very robust system
when you think about it.

Still, there are a few sore spots. DNS is in need of a redesign in my opinion.
It wouldn't be impossible to replace, but not easy either.

A number of concepts in web design (such as "document flow") probably aren't
going away either. But newer technologies (canvas, WebGL? who knows) may
eventually replace the traditional DOM model.

[1] [https://en.wikipedia.org/wiki/QUIC](https://en.wikipedia.org/wiki/QUIC)

~~~
goatlover
The web isn't the internet. Someone else posted a quote (by Alan Kay?) about
how the internet was an example of brilliant design, while the web was an
example of amateurish engineering.

------
freyr
Yes. Web programming is a mess. It's layers and layers of half-baked
solutions, each patching deficiencies in the previous layer while introducing
new deficiencies. It's a convoluted Rune Goldbergian contraption, attempting
to make a general application framework out technologies originally designed
to display hypertext.

The individual parts make sense once you're familiar with them. Some are even
designed by conscientious and competent people. But the feeling that, taken
together, it's an ugly hack is inescapable.

------
unclebucknasty
Damn. If I didn't know better, I'd have thought I'd written this myself while
in an Ambien-induced fugue state.

This is exactly my feeling and much my own history. I think the intensity of
your pain can be felt most acutely by those who once knew a saner world of
software development.

For those who came of age in this era of Javascript hacks, framework of the
day, standard of the week, and separate open source tool for _every single
task_ an app must perform, I think it is simply normal.

I say this because after several years applying my craft to my own business in
the manner of my choosing, I have recently returned to Organized Development
Land. When I read the code or a module is explained to me, all I can think is
"are you effin' kidding me?" But I look around and everyone else has a
straight face.

If you've stayed in the industry during this evolution, you have probably had
moments of frustration or confusion wrought by this change, but have now had a
full WTF epiphany--likely induced while simply trying to get something done
for the hundredth time, that should've been relatively straightforward.

Mainstream software development is no longer about logic, algorithms,
creativity, and design. It's about trying to glue together a hodge podge of
disparate crap and trying to make it work. And, for the artisans of old, it
can feel like soul-crushing assembly-line work.

------
micro_softy
Do web developers find ways to create work for themselves?

You allude to it below when you say "zillions of hours".

There is a significant amount of money moving through the "web development
industry".

People are getting _paid_ to write things that suck.

The internet actually has made leaps and bounds in terms of what can be
delivered over it to the masses.

But the "web" has become a cesspool of redirects, overstuffed headers and
pages crammed with beacons, ad server links and ad-related Javascript,
accessible through ad-sales-company-sponsored software ("web browsers") to run
the ad-related Javascript.

If and when users grow tired of web advertising, the entire system is a risk
of a serious correction.

Again, significant and increasingly larger sums of money are moving through
the web ad and user data collection cesspool so no one really cares how poor
the quality of the "content" becomes.

And you want to learn to orient your mind to this "new way of thinking"?

Maybe you are not resisting change. Maybe you are resisting stupidity. Your
time may be better spent focusing on backend development. Today's "backend"
may be tomorrow's frontend.

All that "content" can easily be delivered without a single line of Javascript
and without using search-engine-ad-sales-company-sponsored software.

------
jacquesm
Definitely yes. I'm on the sidelines until things will settle down into
something that makes more sense and if it doesn't then I won't be doing any
web development.

Software is such a huge field there are a ton of interesting challenges
outside of the web and the current mess does absolutely nothing to keep me
interested. It's a veritable tower of Babel without a clear sense of direction
or longevity.

------
duncan_bayne
I think all programming is, but Web programming is _particularly_ that way.

The least bad stack I've ever used is Reagent ( [https://github.com/reagent-
project/reagent](https://github.com/reagent-project/reagent) ) - a
Clojurescript library for React. Perhaps that's just _adding_ layers of
hackery, but I found it made sense.

------
richardw
I use GWT for anything serious. It's not what the cool kids like, but it feels
super-solid compared to the flake that I experience when working with a heap'o
JS libs. And debugging it years later is awesome (barring a couple gotchas)
because it makes sense.

I've always thought GWT has a crazy learning curve until we did a project in
Angular2 on top of ASP.net core, using a customer-selected template that
required tons of JS fun, with random CSS class names that have zero obvious
semantic benefit so you have to look everything up. Not even Typescript could
save the feeling that we were building a house of cards in a strong breeze.
Same with Django + JS. Just felt too scripty for me.

I don't like leaky abstractions but honestly the modern web fundamentally
forces you to use them for anything vaguely complex. It's not getting easier,
it's getting much, much harder. GWT at least gives me a way to trade off
complexity for a clunky but solid language, and I get to reuse code on the
front and back ends.

~~~
sgt
Maybe it has changed since I last used GWT, but I remember GWT compiles taking
a very long time, steadily increasing with the size of your app. Has this been
fixed? I have some not-so-very-fond memories of 2 minute long compile times.

~~~
diyfund
It has changed a ton. there is now super dev mode (I don't know when you last
used it), so it no longer requires that java applet plugin. Also after the
first compile, you only need to recompile changes. I agree with others after
going to Angular, etc, I continually scratch my head on why GWT is not
universally used more.

------
nallerooth
The web itself as we know it, was born from a bunch of hacks clobbered
together by people who thought that the most important part of development was
to "ship code". Features like images in browsers, or JavaScript, were designed
and implemented in very short amounts of time and then all the cool features
were copied by other browsers. With such a foundation, I think we can
establish that modern web development indeed is a "hacks on hacks" thing.

A lot of people still believe that software development is all about "shipping
code". And since many developers work alone, or in small teams - things like
architecture, knowledge of web interfaces/APIs, etc. may not be something the
developers are familiar with. Then the project becomes popular, which makes it
harder to clean stuff up without breaking code depending on your project.

New developers hearing about companies embracing stuff like "Break stuff -
ship code" isn't really helping them focus on quality either.

------
toddan
This is why i find it so much fun to do applications on windows with .net you
only need to know one language C# or VB.net and then you are set. You can
create anything with just this, of course it will only work on windows but i
dont mind, it just such a pleasure to only have one toolset and then just
focus on the task at hand.

------
otabdeveloper
All of human civilization is a 'series of hacks on hacks'.

~~~
3chelon
Like biological evolution before it.

------
EugeneOZ
Some parts of web-dev are really chaotic right now, but other parts can be
very well-organized, same as server-side code.

For example, you need to compile all of your es6/es7/typescript code to JS
(because nobody will write in pure ES5 nowadays), minify and concatenate
resulting files - this part is very chaotic. But you need to touch it not so
often.

You also need to write unit-tests. Tests itself will take 10% of their
configuration code, it's very annoying also.

But when you'll write e2e tests, everything will be much more clean.

Main part, JS code (I recommend TypeScript) can be organized by same rules you
use on the server.

Frameworks: Angular 2 is closer to Java enterprise apps (with all good and bad
parts of it), React and jQuery are not frameworks and if your codebase is
built on jQuery - bad news, it will be mostly spaghetti-code.

------
webXL
Ah, yes. Another round of grumpy 'ol "why can't I pick/control every aspect of
my application environment in the languages I love" developer whining. I swear
some people just love saying "hacks on top of hacks". It's the new pejorative
of our industry, despite the unparalleled success of what it's intended to
dismiss. The hacky-ness we're observing is just an evolutionary byproduct of
the "power vacuum" of software decentralization and democratization. Yes, it's
inefficient and ugly in some places, but it's an amazingly practical way to
distribute software. Just remember your perfect system is only perfect for you
or your financials. To state otherwise is sophomoric and unscientific.

~~~
barefootcoder
Strange that you feel that's what I was saying given that my original post
said that I've worked in a variety of different languages and environments.

~~~
webXL
I apologize if I'm being too harsh, but I see these arguments over and over
again and I don't think they result in anything beneficial. The thing we
should be fighting is not-invented-here syndrome and only re-invent things
that which cannot be improved upon for one reason or another.

------
thrilleratplay
Yes/no. Code is developing faster than standards update:

HTML - HTML 4.0.1 -> HTML5 (14 years)

CSS3 - in development since 1998

JS - ECMAScript 3 (1999) -> ECMAScript 5 (2009) -> ECMAScript 6 (2015...ish
[http://kangax.github.io/compat-table/es6/](http://kangax.github.io/compat-
table/es6/))

I think web development is a lot like Perl. It is flexable enough for anyone
to write something simple and quick but creating a large maintainable project
takes a lot of discipline.

I use a series of linters, style guides and naming conventions to keep from
shooting myself in the foot but still will need to go back and clean up from
time to time.

------
crearo
I felt the exact same thing when I started webdev after 3 years of app dev and
a little bit of REST APIs (and backend) using python flask. For me JS, and all
frameworks built using JS felt like attempts at revival of something that
should have long died. Every new framework gives JS lovers (honestly no
offence) a little bit of hope and adds a year or two to its survival. For a
long time, I felt JS was a hack on top of a series of hacks!

I've just come to accept it now. The reason you're disliking it is probably
because of its extreme hit and trial nature - unlike appdev which is more
fluid and consistent.

------
ilaksh
My take on this is that backend developers have always been at odds with
frontend developers in terms of being given larger salaries than frontend
while not having to keep up with new UI technologies and simultaneously
downplaying the skills of the front end programmers.

So now, when you have to learn about the web platform since you just cannot
ignore it anymore, you are feeling pretty overwhelmed, and can't help yourself
-- you fall back on what you know, which is to shit on the skills of front-end
developers.

I say this as someone who has done front, back, database, ops, on web-based
and desktop stacks.

~~~
barefootcoder
Did you even read what I said?

"anywhere from UI down to the bare metal"

I've done a lot of frontend work, including iOS, Android, MFC, OpenGL, Qt
(with and without QML), etc... My UI work has often been praised, and I've
salvaged many failing projects, including fixing completely broken UIs. I'm
not sure where you got "not having to keep up with new UI technologies" or
"downplaying the skills of front end programmers" from anything I said.

If anything, the frontend developers get a lot of credit for what the backend
developers do. I enjoy backend work more, and it is frustrating when a GUI
developer spends a few days and slaps a few screens on that update in response
to signals that took months to implement, but they get all of the credit for
the feature. It goes both ways, you know?

~~~
dandv
I'm curious, have you looked at Meteor?

[https://wiki.dandascalescu.com/essays/why_meteor](https://wiki.dandascalescu.com/essays/why_meteor)

~~~
barefootcoder
No. I have no control over the software stack for this project, so for now I'm
focusing on what they use first.

------
sp527
What you're witnessing is the migration of complexity to the frontend. It's
becoming very difficult to find a backend problem that doesn't have a well-
defined, generally accepted solution and accompanying FOSS that you would be
stupid (or even borderline criminally negligent) to ignore. In fact, full-
stack programming in general is boring enough that I welcome anything that
stirs the pot a bit. That said, having tried at one time or another PM,
management, and sales: programming is the worst monetizable career option,
except for all the others.

~~~
copperx
> That said, having tried at one time or another PM, management, and sales:
> programming is the worst monetizable career option, except for all the
> others.

Could you clarify that sentence, please?

~~~
sp527
Just an Easter egg:
[http://wais.stanford.edu/Democracy/democracy_DemocracyAndChu...](http://wais.stanford.edu/Democracy/democracy_DemocracyAndChurchill\(090503\).html)

------
tekacs
I'm more unnerved by how few maintainers so many critical/core open source
projects/libraries have, whether in web or otherwise.

However high our project or company's bus factor gets, it's concerning to
realise that the framework or critical library underlying has a bus factor
close to one. We can certainly adopt it, but that's folding in a lot of new
complexity. o_O

This applies irrespective of the language, incidentally - it's often true in
Java/Python/Scala even as in JavaScript/npm, as much as people like to bash on
the latter.

------
popopopo
weird. commenters seem to be either new web devs, or non-web devs at all
judging from comments and cries.

web development is as hard as any other development environment. you must know
a lot of stuff, hacks ARE NOT mandatory at all and it is not as bad as people
tell you.

maybe you just work with terrible base code is the answer?

------
kafkaesq
Was it ever anything different?

From the very beginning† -- you know, back to the _< img>_ tag, HTTP 1.0 -- it
was always a series of shrewd tradeoffs (a.k.a. "hacks") in favor of what _can
be put in front of people now_ instead of what might take another 5-8 years of
IETF meetings and mailing lists debates to hash out.

† Referring to "the web" as such; not "the internet", for which the initial
design choices, while still hackish in their own way, were arrived at in ways
decidedly less brutish and expedient.

------
SZJX
Reading through all these comments, I feel there's one salient question left
unanswered: What's the alternative, then, under such a divisive landscape of
various OS and standards? Surely it's infeasible for the vast majority to
develop native applications for each and every platform out there, for
everything we want to do? The current web application solutions are the best
people have come up with. If they're indeed so rubbish and we're in a "dark
age", then why hasn't an alternative triumphed? It's not like companies with
money and might haven't tried over all these decades, they just simply didn't
succeed. There is a reason why web application is being so widely adopted, and
attributing all to "errors and flukes" makes no sense.

Either you unite all the platforms to make them one, which I'd rather not for
diversity's sake, or you accept the fact that there has to be something out
there that supports all of them, which isn't going to be an easy feat no
matter what.

By the way, I surely also hate CSS, and JS to an extent, but my experience
programming UI in other platforms haven't been exactly pain-free either. The
hate might have been a bit overblown. The nature of computer programming in
its current form just simply fits badly with UI design. That's the fact.

------
brwr
Web developer is not ideal. That is more of a people issue than it is a
technology issue.

Whatever our collective gripes about JavaScript, HTML, and CSS, we all know
how to use them. We know how to handle cross-browser compatibility and
different screen sizes. What we need to do a better job at -- and I think this
is the root of the problem you're describing -- is pushing back on businesses
wanting to ship features too quickly.

We've all been at places where no one values good work on the client. The
C-levels want to get things out the door as quickly as possible. They complain
that our work has bugs and we tell them "Well that's what you get for telling
me I had 3 days."

Because of this heat, front-end engineers rarely engineer their software. As
you put it, they hack it together on top of libraries that have been hacked
together by others. The solution is to take the time required to do things
correctly. That means testing. That means not shipping features so we have
time to refactor and upgrade frameworks. That means paying attention to
performance and developing tools for debugging errors in production. If we
want web development to get better, these things can't be afterthoughts. They
must be considered before we say something is "done" and ship it to
production.

------
endgame
[http://www.stilldrinking.org/programming-
sucks](http://www.stilldrinking.org/programming-sucks)

~~~
rohmanhakim
Well, this is so good to read. Thanks for sharing!

------
altern8tif
One thing I haven't seen mentioned is that while the developer experience is
getting more complex, the user experience is getting better and better.

That, in my opinion, makes all the messiness worth it. I'm not saying that
there's nothing wrong with the state of web dev now, but it's not without
reason that we are here today.

Remember the days of table-based layouts in HTML? _shudder_

~~~
some-guy
I don't think the complexity of the web _caused_ better UX. I think we just
happen to care a lot more about UX in 2016 than we used to in this industry.

~~~
altern8tif
Sure, but caring a lot about UX necessitates pushing the envelope when it
comes to web tech.

If we were satisfied with our HTML tables, we would never have moved on to
jQuery, HTML5/CSS3, React etc.

------
xorgar831
I'd love to know too, are there any frameworks that are at least more
straightforward than React and Angular? One where you're not passing anonymous
functions into functions with all sorts of confusing syntaxes, where you can
just express what you want to do without having balance three types of
punctuation that require the shift key to type.

------
benoror
Hackish? yeah!, immature? still yes!, sucks? hell no!

I believe the very nature of the web, and the internet itself, is a story of a
hack onto another hack.

Think about the first internet communication mediums, protocols, etc. They
were all "hackish" solutions. Internet over the telephone landline? why not?
change it to the cable TV infrastructure? Sure!

The web itself morphed from text-based solutions (think telnet, gopher) to
hyper-text documents and nowadays to full-applications. I acknowledge that
this last iteration has been a growing pain indeed, it's a mess and hasn't
been consolidated, yet.

Nevertheless I think the reason behind this hackish nature is due to the fact
that the web (and the internet as a whole) are always pushing towards an Open
Platform, open to everyone to develop and consume, without any corporation
behind it.

Compare that kind of ecosystem with the more closed less-hackish ecosystems
like Windows/OS X, Android/iOS app development, you can see the difference.

Just my two cents :)

------
david927
We're a smart industry, but we're not a wise industry.

We focus on solving tactical problems, ignoring the mountains of technical
debt that are created from it, and that it leaves the strategic problem worse.
We will do this because we need the solution today, not tomorrow.

We can elevate out of this when we're ready, when we say "enough is enough."

------
dandv
Yes, the web was meant for building _pages_ , not _applications_ , and that
shows. HTML and CSS are horrible at laying out apps (even with flexbox). Which
is why using front-end libraries is critical. Have a look at
[https://webix.com](https://webix.com) \- it's amazing how expressive that
widgets library is: 10 lines of code for a master-detail tree+grid layout.

As for the server side and the client-server communication, nothing really
beats Meteor -
[https://wiki.dandascalescu.com/essays/why_meteor](https://wiki.dandascalescu.com/essays/why_meteor).
It removes a lot of the paradox of choice, while still letting you swap
components out when you're ready (e.g. you can use PostgreSQL instead of
Mongo, or React instead of Meteor's default view library).

~~~
dandv
Also, while JavaScript has been a hacky language, ES2015 and ES2016 have
really upped the game:

* Classes

* Modules

* Block-scoped variables

* Multi-line strings

* Default parameters

* Template Literals

* Arrow functions

* Promises

* Async/await

And JavaScript keeps eating the world:

"In three months from today, 98% of all Walmart.com traffic will be serviced
via Node APIs and displayed with React.js according to Alex Grigoryan,
Director of Software Engineering at WalMart Labs. Three months after that,
SamsClub.com, Walmart’s second biggest property, will be 100% javascript
based. Even their iOS and Android experiences will eventually be done in React
Native, a javascript technology that’s made to replace native Java/Objective C
coding." \-- [https://medium.com/presence-product-group/javascript-and-
nod...](https://medium.com/presence-product-group/javascript-and-node-js-
continue-to-eat-the-world-d41918a0615b)

~~~
goatlover
You mean eating the visible world. There's all the code which isn't public
facing that runs everything else. For that matter, JS is dependent on layers
of code not written in JS, some of which is visible.

Also, it's not like other programming languages don't have the features you
listed. JS is playing catchup.

------
jorgeleo
That is because Html is a more readable form of RTF, but still a document
descriptor none the less. and hack in with javascript.

If the world had settle in Word format, instead of javascript we will be using
VBA, and everything else will look exactly the same.

I think what we really need is a web app environment, with programming as the
first though

------
achen2345
I have been working with web technologies directly (not through Java or some
other language) full time for almost 20 years. Here is the problem:

* In the 90s sloppy was awesome. The web is driven by marketing interests and not by technology interests. The name of the game back then was "get big fast". You need incompetent developers (many of them) to work in the technologies for extremely low pay, which means the technology must be extremely forgiving. The technologies tolerate a tremendous amount of sloppiness and so become sloppy themselves.

* The education around web technologies is deplorable. There are a couple of reasons for this. The technology is moving, growing, and enhancing rapidly making it hard to keep up with. Because there is sloppiness baked in its hard for people to immediately jump in and know the best approaches and avoid the pitfalls. Web technologies are generally considered incompetent toys (in academia) compared to more entrenched technologies like C++ and its spawn (C# and Java).

* Don't break the web. This means old broken approaches (the sloppiness) will continue to be supported forever even after they are deprecated and killed. We know what the best approaches are, but making the technologies more strict and unforgiving is the enemy of all marketing and shames incompetent developers (most of them). It is one thing if your language of choice fails and yells at you during a build process, but it is something different when this happens in production because web technologies don't require a build process.

You can safely ignore the technology excuses from many of the replies on here.
These opinions come from people who learn web technologies only after learning
something else (unrelated) first. For example, JavaScript is not Java, and if
you look at it through a Java lens it will be incompetent for all kinds of
reasons, but really the developer is just wishing they were still writing in
Java. JavaScript will never be language x, but that isn't a valid reason to
call it incompetent.

------
SimeVidas
The web platform is disorganized and has many missing pieces. It has also
grown quite a lot in the last couple of years, so it’s virtually impossible to
understand all of it. As long as you’re disciplined about learning from the
relevant blogs, it will “become better” (but it may take months).

~~~
shabbyrobe
How can you know what constitutes "relevant" though? There are loud voices in
the community that seem right at first but the more you learn, the more you
realise you may have been led astray. I guess that's a way of learning, but
that particular path to enlightenment is covered in litter.

~~~
SimeVidas
For the record, you inspired me to add an “Ask me anything” section on my Web
Platform Daily website. Cheers!

------
sheriffderek
I suggest you choose to fall in love with Ember.js. She is the prettiest girl
in your small town and she's really friendly. Start calling yourself a
programmer instead of a coder - and help move Ember toward being, not just a
framework, but an SDK for the web. Everyone can complain all they want about
CSS and how it's broken etc, but no one has come up with a better solution.
It's not the dark ages... in fact, it's the best time in web development so
far. Developers haven't had to be 'designers' in the way they are being forced
to now - with variable screen-size, and alternate UI patterns for each. HTML
in little dynamic templates, variables for CSS preprocessors, ES6, and modular
JS patterns. Things are wonderful. +1 for a new mental paradigm.

------
Shorel
In my work I can be writing C++, or PHP or Javascript, depending on what part
of the stack I'm working on.

C++ bugs are a bit hard to find, because the error messages are not very
useful, so I launch the debugger, do a stack trace that fills the screen with
arcane texts, then open the relevant source file in the line pointed by the
debugger, and after about a minute of staring at that line and thinking, the
bug is fixed.

In comparison to modern C++, JavaScript issues are complex beasts that can eat
all your morning and give nothing in return. And then you test with another
browser and it starts all over again.

Even so, some things like detecting the decimal separator supported by your
operating system work in IE and Mozilla but were never implemented in Chrome,
so you can't never really fix that 'bug'.

------
flushandforget
I think what saddens me with web programming, is constant rewrites of the same
old projects, that pretty much do the same thing. As a community we'd be
better to focus on a few core APIs like a web shop or a booking app.

A church or school could have a common underlying built platform. Where
functions of outfits are unified, we could drop in one size fits all
solutions.

In England (UK) you have about 24 thousand schools these could be aided/driven
by a few competing platforms. Charities and small shops likewise.

Platform constraints can also help. Having fixed html, perhaps would let
designers just swap out CSS and imagery - job done.

Much web work is a brain drain, and a lot of good talent in my eyes is being
squandered on petty engineering problems, when there is still a world out
there that needs putting right.

~~~
IanCal
Why do you need any new APIs for that? Sounds like you just need a shared
template.

~~~
flushandforget
I appreciate that a web shop could want for more than basic html
representation. Although arguably there is something already like this:
[http://schema.org/Product](http://schema.org/Product) . A search API?

But yes, good templates go a long way.

~~~
IanCal
Hmm, interesting ideas. I particularly like the search one, it'd be
interesting if I could generate a search index that conforms to a particular
spec and just store it as a static file which your browser can grab.

------
ankurdhama
Any software, no matter what type, that evolves over time will become a series
of hacks on hacks. The more the frequency of evolution is the more hacks will
be there. Unfortunately the frequency of evolution in any web app is way way
too much then other kinds of applications.

------
buro9
Everything is simple.

There is just a lot of it.

That's pretty much my view of internet and web technologies over time. It all
did work, it all continues to work, to address
security/performance/convenience we collectively add a few more little simple
features/workarounds/quirks.

But ultimately the perception of the hackery of it all really stems from:

1\. Quantity. There's a lot of stuff, it all works to some definition of
"works" and there is typically more than one way of doing something.

2\. Quality. When things are made, they are made for that time. As time goes
by we can more clearly see the ambiguity of something, or the incompleteness
of a feature, but by then it's too late and it's set in stone, our fix is
usually to add something new (see #1).

------
nigelg
This thread is just a big circle jerk of non web-developers hating on web
development.

Minimize you dependencies, organize your code into easy-to-fit-in-your-head,
single-responsibility modules. Write a simpler solution instead of including
another 100kb minified mess.

Someone else said it, but I'll repeat it: systems scale, languages don't.
Javascript can be as good a language as any if you use it correctly. People
bitch about the footguns but don't take the time to design their systems
correctly. Yeah, Javascript fucking sucks when you write 10k lines of
incoherent JQuery-soup in a single index.js file that provides all the
functionality of your shitty asp.net page from 2001. Well no shit? You can
write garbage in any language.

/rant

------
Fannon
Yes, the web is a very messy place. Maybe a kind of wild west of programming
practices?

But it's also a place where you can do a lot of things that no one has thought
before. There are not many rules and a wide diversity of approaches. The web
platform never had many of those approaches (e.g. complex web applications) in
mind when it was created. It works somehow, anyhow. It's chaotic, yes, but
also flexible and full of freedom.

To stay sane in this world, you have to voluntarily and deliberatly (!) reduce
this freedom and create yourself some small sane pockets that you understand
well enough and feel comfortable with. This can be done by increasing the
abstraction level and restricting feature sets (e.g. ESlint), using Frameworks
(React, Bootstrap, ...) and transpilers (TypeScript, Babel, Sass). Note that
you're loosing freedom here and you're buing into other peoples understanding
how a sane place of web programming should look like. In the Web there are a
lot of ways to do things, there's no monoculture! And if you don't like the
existing ways, roll out your own (though I wish people would be more careful /
sceptical with this attitude).

And there's the backend. You've got all choices of programming languages and
frameworks there. If you're making a mess of you're backend, you really can't
blame the web for it.

For someone without much web experience, this process of choosing frameworks,
workflows, toolsets just to get to one (of many!) sane programming experience
is surely daunting. You have to choose and configure your envirionment
yourself first, just to get started. You really need someone experienced to
set this up and understand most of its implications. If you're having so bad
experiences with your current web project, maybe some bad decisions were made
regarding this. Or too much freedom (and therefore chaos) was left in place
and got out of hand.

If you don't have the experience to make those decisions, you could just start
with one approach that is pupular right now. I guess on hacker news this would
be something like React, Babel, etc.. There are a lot of tutorials out there
to put this all together.

~~~
glenda
I totally agree you except I do think that the web can mess up the server-side
stuff as well.

At the core things can be really simple, but then you need to set up SSL, some
kind of database and potentially integrate a bunch of different services for
things like sending emails, analytics, etc... At that point it is pretty easy
to and up with a giant mess. These types of dependencies are not totally
necessary but they are definitely part of the culture of web-development.

~~~
Fannon
Ok, you're right, and I wasn't completely sure myself when writing this
sentence. There are cases (integration of web services, the overall
architecture) when some difficulties from the web architecture swap over to
the backend.

But wouldn't you have a similar problem if you try to integrate something
other than web services, too?

------
palerdot
One thing that frustrates me as a front-end dev is the inability to settle
down in an ecosystem. Every minute, new tool/framework is coming with a
tagline "There is no need to do that like you did with X, Y takes care of it
for you".

Now the Y might be webpack/React, tomorrow it might me something else. Whoever
says React gives them a consistent way of doing things, they would have said
the same thing to Backbone/Angular/ember/bower/grunt/less/sass/precss/postcss/
.............

Ultimately, it is about controlling your mindset and navigating through this
onslaught of tools/frameworks in the front end ecosystem.

~~~
acemarke
One of my absolute favorite online comments is
[https://www.reddit.com/r/reactjs/comments/39wsfi/what_are_pr...](https://www.reddit.com/r/reactjs/comments/39wsfi/what_are_pros_and_cons_of_using_reactjsflux/cs7msvp)
:

"Every framework can be viewed as an attempt to say "the hardest part of
writing a webapp is {X}, so here's some code to make that easier". ...
Backbone is the result of feeling like the hard parts are fetching and
persisting models to a REST API, and client side routing; that's basically all
it does. Figuring out how to turn your models into HTML is easy (apparently),
but models are hard, so it helps you.

Angular is what you get if you think the biggest problem with writing webapps
is that Javascript isn't Java; Ember that it's not Ruby. (I kid. But I'm less
familiar with those frameworks.) And so on. Everyone has their own ideas of
what's hard to solve.

React + Flux is based on the idea that what's really hard with writing webapps
is non-deterministic behaviour and unclear data flow. And if you've worked on
a large Knockout or Backbone project, you're probably inclined to agree."

------
icedchai
I've been doing web development since 1995, starting with CGI "apps" in C and
Perl. Yes, it is a pile of hacks. The fundamental issue is we're building
"apps" on an environment intended for document delivery.

------
ubernostrum
Is it really that there's some exceptionally high amount of hackery? Or is it
just _different_ hackery than the kind you're used to and have so thoroughly
internalized that you no longer see it as a pile of hacks?

------
jamez1
I like to think of web programming like the english language, how it's a
mashup of all these other languages and ideas. It's hard to learn as an
outsider and has many gotcha's and wrote learning exercises

------
cdevs
Currently at work someone wants to learn to create web pages and prototype his
ideas. He asked me if he's ready because he's learning JavaScript and I had to
reply you still need to learn html, Css, sql and a server language to do what
we do how we do it. It's a shame so he moved on to some new site / page from
mit that's allows drag and drop boots troop elements and drag and drop
database logic like "users must be logged in". It's unfortunate there's not
much of a middle grown between learning 5 things and drag and drop.

------
agentultra
Web programming is not that bad and I think you are missing something.

You're entering a time where ES6 is mostly implemented and should be feature-
complete in most platforms soon. I cannot explain how big of an improvement
this language is. Javascript used to be a language that other people worked in
and I refused to understand. I wrote some thing in it and dabbled when
necessary but I was always amazed at how primitive it was for such a high-
level language. It was usable though with a bunch of libraries to support you.
ES6 makes most of that legacy obsolete.

However ES6 is a bit of a kitchen-sink language now. There are multiple means
to iterate over a collection, there are classes, monads and functors... did I
just say _monads_? I meant Promises. And did I say _functors_? I meant
sequence types with a useful prototype. The point is that if you choose the
right subset for you it's a decent language now.

HTML5 kills the notion that, "the web is only for documents!" The acronym has
aged a bit and is not really descriptive of what HTML5 is anymore. Most GUI
libraries and systems I've seen implement the interface in terms of a tree of
"objects" with the root node being the Window itself. That is essentially what
the DOM is now with the browser providing the run-time loop, input, etc. We
have a rather rich array of elements to work with... buttons, input boxes, a
rich layout model, 2D canvases, WebGL contexts...

Where it does still suck and where I think you might be getting frustrated is
in the tooling. There isn't much of a standard library in Javascript save for
the objects you're given. They all loosely fit together with little cohesion.
It is quite frustrating to get a program started and take it all the way to
something on the level of Gmail, Facebook, or Twitter. It's even more
frustrating if your expectation is an environment such as Qt where you have
standard tools, libraries, and all of that.

However with some effort and determination you can tame the beast. The part of
the kitchen I find most effective is the functional programming side. I use
Fantasyland compatible libraries and wrap other libraries with them. I've
devised my own configuration of build tools based on Webpack, npm, that I can
spin up with Yeoman. It's not great but it's tolerable.

... but now I'm looking into Bucklescript since I'm a closet OCaml fan... and
that seems to be another popular angle for building "large" applications in
Javascript: compile down from a more familiar language with the tooling you
need.

Nothing is straight-forward. Not immediate-mode custom UIs; not big, fancy
frameworks like Qt; and certainly not the web... but the web as a platform is
awfully powerful, flexible, and open.

------
segmondy
Nah, you are not missing anything. You are not alone, but you are also
resisting change because you are not use to this fast pace of change. The
reality is that you need really great memory and ability to organize and
discover information fast to make sense of todays applications. It's layers
upon layers of abstraction. It's terrible in a way when you have to work with
others you have to deal with it. When you work by yourself, just keep it
simple, choose a few well proven and solid stacks and just stick with them.

------
avisples
Application development on a web platform meant for documents is inherently a
hack, but the evolution of the ecosystem is reaching a point where many of the
hacks are quite good. There's just a lot of inertia from existing codebases
and developers used to the previous ways of doing things, and FUD from places
like Google with Angular and Polymer.

Web development seems to be particularly suited to the model of building a
hack, then pouring concrete over it, then building the next layer of hacks on
top.

------
transfire
I was thinking about this the other day, and one possible way to improve the
situation is place a hard separation between web documents from web
applications. Currently we try to shove both capabilities into a single
paradigm (stack). But the two don't mix well.

What might that look like? Ultimately a much more elegant HTML and simplified
CSS for web documents, and quite likely no HTML for web apps -- the Javascript
and CSS would merge into a GUI-oriented language.

------
pjmlp
Yes.

It should have stayed as hypertext documents, just plain HTML + CSS, with
everything else just covered by network protocols.

Instead it is a pile of hacks of trying to bend HTML + CSS + JavaScript to
behave like native applications, but not quite, because the browser is in
control of the L&F leading to yet another pile of hacks to make the already
existing hacks to behave the same across all required browsers (including
different versions of the same browser).

------
palerdot
One important thing is a final web page is a confluence of code coming from
different sources, and not controlled by the end user or the
developer/website. If you define some functionality, I could just override
(intentionally or not) with my code which also gets loaded along with yours.

Combine this with the inconsistent browser playground, you might get some
perspective of the hacky nature of the workings in the front end world.

------
peter_retief
I agree, its way more complex than it should be, probably something to do with
the browser wars and propriety software battling to add barriers of access

------
Kaizyn
Have a look at Elm. That looks like a fairly promising alternative to some of
this mess. I don't think you can get away from CSS and HTML5 though.

------
mmilano
Are you sure the assessment web programming being a series of hacks on hacks
isn't an artifact of inheriting a fairly long-lived and large code base?

I don't think I've touched a large codebase that has been around for a long
time which didn't feel hackish.

I'd make the evaluation of web programming based on a language and framework
that feels most proper to you, and based on the use of it with a brand new
app.

------
samblr
My view is exactly contrary coming from system development experience. I
cannot think why would anybody handcraft MVCish frameworks in js, jquery etc.
I have programmed MVCish UI frameworks and middleware in c for AV products 10
years ago. And as a UI dev u want a working MVC. Now I'm using angular and
totally feel at home. I think sans these new frameworks web must have been
really dark place.

------
stevesun21
As working on backend and front end for many projects for different size of
projects over years, I would say 'yes' as my short answer.

------
prawn
It might be hack on top of hack, but I find it quite enjoyable when I'm
completely in control of what I'm delivering. When I know what's reliable and
what's dangerous, I can work around those limitations. Where things get
particularly painful are when you are at the mercy of decisions made by a
client or boss who won't listen to reason. Then it's hell.

------
shurcooL
I agree, and I decided I won't accept the hacks and compromises anymore, and
started building everything in Go (even frontend stuff) in my free time.
There's much to do, but at least the foundation (type system, type safety,
etc.) is very solid.

This way, I don't have to build on top of the hacky and messy things anymore,
but slowly take my time and do things very right.

------
eksemplar
There isn't much of a difference between web and application development in my
eyes. Both should be build on a service backend, with a common architecture
making different systems work together through APIs or MOX-agents.

In that world the "view" part of your system might as well be web based.
Making front end look and feel good, is terrible in everything anyway.

------
saosebastiao
Not gonna comment on most of this, as I'm right there with you. Web
development is a gigantic shit sandwich. But I have to at least respond to
this:

> _I 'm not even talking about the fact that everything has to be stateless,
> in fact I develop desktop apps as stateless even driven UIs as well, _

No, you do not. UIs are state machines (not _like_ state machines, they
actually _are_ state machines). It is _impossible_ to have a stateless
interactive UI. If it is stateless, it might be a web page or document, but it
is not a UI.

Any attempt to make a "stateless" UI will fail because of this impossibility.
What many half-baked frameworks will attempt to do is make them as stateless
as possible, which is a recipe for disaster, as they can't actually get rid of
the state, they can only move it to some location where it wasn't designed to
store state (Routes? Cookies?), or to some location where the semantics and
comprehensibility have been compromised. In fact, this statelessness is
precisely one of the major problems with web programming...you're trying to
bolt something inherently stateful onto a format that was designed for
statelessness (HTML was created for documents, not apps).

Programmers in general, and UI programmers in particular, need to get over
their fetish for statelessness. Sure, modeling a stateless problem with
stateful code is ridiculous, but if you try to model a stateful problem with
stateless code you are going to have a much worse time. Modeling state is
hard...don't make it harder by pretending it doesn't exist.

------
paulftw
Frontend always was and always will be harder than backend, regardless of the
platform/framework etc. Yes, the fact that HTML / CSS is a technology designed
in a different era (slow keyboard+mouse desktops) for a different purpose
(displaying static hyperlinked documents) doesn't make life any easier.

------
patatino
Everything is a mess, so keep it as simple as possible. Yeah it's nice to have
an awesome frontend with javascript but it's much simpler and cleaner to post
something back to the server.

I fell in love with web programing 14 years ago because I don't have to save
the state of the UI and activate or deactive buttons.

------
hellofunk
true, unless you look at incredible new ways of UI design like React and its
Clojurescript counterpart, Om and others. FRP and similar concepts has so
dramatically changed how I think about software design that I now use it for
most of my native C++ projects as well, or at least, I get as close to it as I
can.

------
35bge57dtjku
> Is web programming really that bad? Is it really just that I need a new
> mental paradigm?

In the sense that there's 1000 web frameworks that all put their own shitty
spin on everything, yes definitely. OTOH it shouldn't be hard for you to
improve on those things and release web framework #1001.

------
chunkyslink
This is a good resource in terms of 'getting your head into the space'.

[https://12factor.net/](https://12factor.net/)

Not aimed at beginners but it made me think a lot more about how complex this
can actually be then a set of related technologies.

------
dreta
HTML and JS are bad, but you can reduce them to a basic syntax that you can
work with. CSS on the other hand requires hacks to perform the most basic
operations like positioning an element relative to another element or
centering an element inside of a container.

------
kharms
As a non-web-dev, the hardest problem I've encountered is choice.

Which framework should I choose to do X? To do Y? Do they play together? Are
they still supported? Are they well documented? What assumptions are made by
them?

There are dozens of options for most things, but no guide to them.

------
plg
Isn't everything? The older I get the more I realize that all of the orderly
systems I thought governed life, society and the universe are in fact a system
of hacks and bag of tricks. Sure there are rules. Except when there are
exceptions. And on it goes.

------
p333347
From my experience, it is, especially in front end development when you must
have cross-browser support. For me the term _cross-browser support_ itself is
quite amusing and nonsensical given that there is supposed to be a standard.

------
bikamonki
So what exactly are the front-end stack haters proposing as an alternative to
hack-on-hack? Should we just dev/maintain N code bases of native apps to run
on every OS and then somehow _connect_ them?

Haters are missing the big picture...

------
sidthekid
I wonder if 50 years down the line, maybe when humanity is building spaceships
to go to other planets, will the interstellar software be written in C++/Java
or Assembly or be produced entirely by AI subsystems or what.

~~~
goatlover
Machine learning algorithms written in Perl 7.

------
godzillabrennus
Yeah it is. Django is a good example of a framework that is popular and well
documented overall. Yet when a new Django revision comes out the books and
documentation from third parties take months to follow on. So by the time I've
learned all the major changes in a revision well enough it's already party
over for that revision. Official support is just ending because they have a
new revision out. Unless it's an LTS build but that means there is a whole lot
of new stuff in these non-LTS releases.

I for one would prefer to have Django and other projects abandon the minor
revision numbers like 1.8 and 1.9 in favor of what Asterisk did and call them
what they are. Version 8 and Version 9.

That'd make it feel less hacky and if done right they could encourage longer
support cycles for these major version releases.

~~~
collinmanderson
Django is moving in that direction by having each LTS have its own major
version number, and backwards compatibility guarantees within each major
version. So you can think in terms of major versions every two years if you
want.

You can start your project on Django 2.0 (expected December 2017) and "Version
2" will be supported (via 2.2 LTS) through April 2022.

[https://www.djangoproject.com/download/#supported-
versions](https://www.djangoproject.com/download/#supported-versions)

------
GoToRO
It's the same like any other open source project: it gives you 100 ways to
hang yourself and maybe only one way to do it right. Your job is then how to
find that one way.

Frameworks? use them when you need to deliver crap, fast! :)

------
realworldview
You are not crazy. Many, many people have come before you and asked the same.
The reply is always the same. Yet the craziness continues, it multiplies and
it leaves nothing in its wake. Nothing stirred in the embers.

And the DOM was.

------
wepple
my biggest realisation of this was when reading the opening chapters to Michel
Zalewski's Tangled web [1]. He does an excellent brief intro to how we got to
where we are, warts and all.

Things like content sniffing where a browser can't work out what type of file
it's been given, so has an algorithm to take a guess and render based on that
are what we've got to deal with.

[1] [https://www.amazon.com/Tangled-Web-Securing-Modern-
Applicati...](https://www.amazon.com/Tangled-Web-Securing-Modern-
Applications/dp/1593273886)

------
bikamonki
If you've been codign "since before the web", then you should be able to see
the whole picture. The browser is the new VM. Horrible hacks are necessary to
test ideas and move forward new paradigms.

------
mathgenius
About 15 years ago I made the conscious decision to ignore web programming
entirely, in the hopes that in a few years things would settle down and get
some sanity. Apparently this has not happened.

------
jaunkst
Its very, opinionated. It has to be! (for now)

I can agree with almost every opinion in the comments, almost everyone is
right. But with a strong opinion and a strong mental model there is light at
the end of the tunnel.

The future is bright for web applications, and almost everyone in the space is
aware of the biggest issues, which is important as the browsers adapt new
features to help ease the pain.

Web development is a scary place but it can be enjoyable when the right pieces
are in place. Older web applications have crazy hacks and made up anti-
patterns to solve problems, which mix context between the client and the
server making it a nightmare to wrap your head around or even implement new
features.

Often a new feature in such application guides the developer to accept the
fate of adding more technical debt, and creates a strong desire for a better
way with no way out without a major overhaul of the backend and frontend. I
have spent countless hours building patches to older systems just to prepare
them for the option of pivoting to more modern approaches.

Today web application development is a fast moving target. Design patterns are
changing from framework to framework. Even from framework version to version.
i.e Angular 2.

It's almost as if the current state of frontend development is very comb
shaped. broad in approaches, and that the community is digging deep into
patterns that are showing success in scaling, and performance. We have to deal
with various topics, the lack of concurrency, performance of the DOM, managing
scope, and state.

I have a few opinionated methodologies to help me in modern web development.

1\. Pick a strong frontend and backend frameworks and know them well.

2\. Don't mix the backend and the frontend code. Keep the backend API in
context to the business domain, data validation, and security. Allow the
client to be an independent consumer of the API for portability and scalable
distribution.

3\. Keep your JSON responses as flat as possible, and avoid deeply nested data
structures. Rely on functional programming to map and reduce your data on the
client into deeply nested structures if needed.

4\. Decide what the client can compute for free computation cycles.

5\. Stay as data-driven as possible. Fall back to the server or micro-service
if the client is not efficient at a demanding task.

6\. Choose libraries with the least restraints and high flexiblity. They
should not obfuscate or complicate your ability to implement the design. I
find most libraries can assume to much control.

We are in a better place today then we have ever been for web applications.
Though the learning curve is intense and the subjects broad. Especially for
fullstack developers. I feel that finding what works and an opinion of how it
should be done is important.

I am less picky about the backend technolgies as I am with the frontend. I
would really only consider Angular, or React for my frontend. Both Angular and
React expect you to form a mental model of how they work, and what a build
pipeline should look like which is very project specific in my experience.

Its the wild west our here, and expect things to continue to change. Building
an opinion, vetting new libraries to add to your toolbox, and experimenting is
just part of the web application world.

------
the_common_man
I think any programming model that's been around for a long time is complex.
Backward compat is the devil. Take OpenGL for example. All the compat stuff
has made it practically impenetrable.

------
BasDirks
HTML, CSS and JavaScript are improving. Your experience as a web programmer
depends on the browsers you are working with. If your clients include IE6
users, your life is going to be worse.

------
solidsnack9000
It is the amazing architecture that integrates those hacks, though.

------
bigopon
Because it has to do something nothing could everdone before ? Unites the
worl, provides collaborative environment. So it needs time to evolve. You will
hate it less overtime

------
justifier
where does the hacking end?

i see using an electron passing over an elemental substrate as a hack of
electromagnetism to allow its properties to represent arithmetic logic

i see little endian as a hack of binary notation of sets to be able to compose
information

everything you do is a hack on top of a hack.. on the shoulders of giant
stacked turtles.. or some such

what about web development sucks for you? in recognising them do you have any
ideas for how to relieve your pain points?

web development is the same as application work.. solving problems

------
tracker1
I know there's a bit of boilerplate to learn, but if you stick to React +
Redux + Fetch using Babel and Webpack, you'll have a much easier time of it
overall.

------
kelulon
Yes, it is. That is exactly what I have found. It's just insanity. I can
honestly say Javascript made me cry today. It's not just you. There is a
better way.

------
tempodox
Yes, very much so. And everybody is too busy making money to go back to before
all those wrong decisions and apply the knowledge we now got from hindsight.

------
patsplat
You are resisting change. User experience code is different from backend code.
It is often a pile of incomplete abstractions and device specific hacks.

------
mruniverse
It is but don't worry about it. It's getting better by the hour.

Just think about this: Has it ever been easier to reach so many people with so
little effort?

------
z3t4
The trick to web-dev is to avoid a "back-end" at all costs. Just make all your
"data" available in human friendly HTML.

------
gvilarino
Programming is just a series of hacks on hacks.

------
robbyt
Yes, it sucks. So how do we fix it? (In perfect world, how would you reinvent
the web as an application platform...)

------
carapace
Elm [http://elm-lang.org/](http://elm-lang.org/)

------
sboselli
You sound like a good candidate for something like Elm (elm-lang.org), with
its Elm Architechture.

------
zebraflask
That's a colorful way to put it, but yes! Of course it is. That's what makes
it fun.

------
ktRolster
Web programming is ok. A lot of the complexity comes because it is actually
two different problems:

1) The problem of displaying a (mostly static) page of HTML

2) The problem creating an application

There are web frameworks in existence that solve either of these problems, but
things get ugly when people don't think about which problem they are trying to
solve.

~~~
goatlover
The real problem is that 1 was turned into 2 without replacing 1. It's kind of
amazing that HTML and CSS have survived all the way through 2016, and don't
look they're going to be replaced for a long time.

------
exabrial
Yes. And while HTML5 brought a lot of awesome features, it also created
another set of problems, the least of which, is the syntax is impossible.
There are 100 "right" ways to do things now, when in fact, a language should
specify an exact way of doing something.

------
gruzilla
I have a a very similar background as the OP.

Also seen/worked on projects that are a mess and devs there built hacks upon
hacks to keep everything up.

I also felt like I am stupid (besides studying software engineering and
working in the web business for 15 years) or I miss something. But then I also
had the privilege to work with very skilled people and get a different
perspective.

Here comes my argument:

I argue that most projects that went to be a mess have been set up by people
that had to work with incomplete information or insufficient time to conquer
the stated problem. So I project the question "is-technology-the-problem?" to
"is-the-team-the-problem?".

In my experience much bad influence - that create messy projects - comes from
the lack or the way of communication between technical designers (who say
whats possible), developers (who say how its possible) and other stakeholders
(who normally "just want something"). I think of a situation here, where I had
to work with a sales guy who proudly sold "rapid development" and "agile
iterations" without understanding the technical or management perspective of
true rapid development.

When it comes to making design decisions (which WILL influence the
"messiness") the web is full of different approaches, technologies and so
called "best practices". If you're a designer of a "will-become-big"-project
it is difficult to make those decisions based on this variety of solutions
(which as the OP stated almost everytime suck after some months). The fact
that every framework presents itself as the best and most versatile does not
help at all.

My best practice to go out and talk to people about my problem and not ask the
internet. Its others people experience you only can access in a discussion,
because normally you don't and cannot know what information you lack and
therefore ask superficial questions on the web and thus get superficial
solutions and have to conquer previously unexpected problems in long-term.

Another argument I want to make:

If you were a carpenter and would have to build the interior of an opera you
would not go to the web, google for a month and then think you have exhausted
all available resources and now you are ready to build that opera interior.
The ubiquity of "quick solutions" make developers believe there are no long-
term-effects of such decisions and thus most such small decisions never get
discussed. If you have worked in teams in other branches (building digital
arts, building a house boat, stuff like that, where you MUST have a team) you
get the point of what I am saying. Its only computer science where people stop
talking because they think everything is clear to everybody.

About your question about orientation:

I suggest getting aware of the high level concepts of full stack web
development and truly understand the concerns every layer tries to attack.
Web-Development - like every other software engineering discipline - is all
about Devide&Conquer. N-Tier development (one approach to D&C) is nothing new,
but the semantics of web development are new. A good designer has to speak
those new semantics fluently. It also helps getting a good feeling about what
actually is a "best practice" and what is just sold as such. There simply is
no universality to web programming as there is none to other software
engineering disciplines.

I gained a lot of confidence in knowing about the classification of problems
and how you would generally combine them instead of building a big hashmap of
problem -> web-tech-framework (This also reminded me of some complexity
courses I took in my studies). Giving clear semantics to different parts of
your application and discussing those layers using natural language also
reduces your teams vulnerability to total chaos and prepares for unexpected
changes of requirements.

Further I learned from experience that its often the time-constraint that
promotes messy code that never gets cleaned up because the project somewhat
dies a slow death, which in my eyes is just a reminder that web-tech is
something new to the society as a whole.

Finally:

Thus I developed the following perspective: I see myself as a moderator of
language and problem-awareness. I often argue in front of customers that if
you describe the project as a map of the problem domain there are A LOT of
blank areas and its our teams effort that will unveil/debunk/uncover those
blank areas. I also point out that there are a lot of semi-blank-areas on our
project map. I for example know how agile development looks like that does NOT
generate a hack-upon-hack architecture but the others don't. On the other hand
I have no knowledge whatsoever about interiors of operas (to reuse the example
from above). Its that explicit merge of information that prevents a projects
structure going astray.

------
joelbondurant
HTML5 seems significantly less advanced than Java AWT was in 1997.

~~~
flukus
But it looks prettier.

------
naranha
Are you talking about the client or server side?

------
jimjimjim
house of cards.

with each card being the flavor of the month provided by an external source.

it's almost enough to make me want to go back to activex.

------
gotofritz
Yes, it's you resisting change.

------
keithnz
The web world is just a new world of different problems. One of the most
interesting things about this world is there are a LOT of participants. A big
part of the web world is diversity, it's kind of like moving from the country
to a big multi cultural city. Many many many ideas are being thrown around.
Finding cohesion between ideas is tricky. Being a learner in this world is
bewildering.

Understanding the browser is very important, perhaps start with
[http://www.html5rocks.com/en/tutorials/internals/howbrowsers...](http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/)

If you are a good coder, javascript can be awesome. Put a lot of time into
understanding the language. Don't stray into variants like typescript or
coffeescript or elm or anything else till you are pretty happy with js.
Prioritize learning ES6 over any variants. The bulk of information on the net
and libraries, etc is standard js.

Get a good understanding of webserver, HTTP / Web sockets. Sniff packets and
also understand HTTPS.

Invest a lot of time into HTML and CSS, there's a lot of advice on how to
build your own CSS frameworks from the ground up, this is really worthwhile.
But also spend a bunch of time with something established like bootstrap ( or
any other UI framework ) so you can see what problems frameworks are trying to
solve.

Language? Frameworks? This is where it gets tricky. I suggest understanding a
Node stack, as it's popular, and a lot of examples use it as a backend. It may
not be what you actually end up using. Checkout Angular2, React / redux as
they are popular javascript frameworks that run in the browser to deliver
application like UI. However, go for statically generated pages if you don't
need that kind of UI, classic GET/POST delivered webpages still deliver a lot
of value.

Security / Authentication - Can be very tricky and in some environments it's
left to roll your own

Data - Can be super convoluted, often taught in a web context without much
concern for security and authentication (depending on stack). In general avoid
having too many layers between your data store and the UI. SQL / NoSQL /
BigData Stores are all toys to play with (but each data store tech has its own
problems and tradeoffs) and more often are getting mixed together.

Now, because you can pick and choose nearly any aspect of the above, it can
become very hackish, especially as new toys are coming along all the time.

If I was going to recommend a single thing to start playing around with?
probably meteor. It packages up a lot of modern web things for you, it's all
javascript, it uses a mongo back end (which is a json store, not necessarily
the greatest choice of DB though), has a easy package system, and supports a
number of popular front ends. None of which is how you should choose a
production stack, but it can be a good way to get started.

~~~
dandv
+1 for Meteor. It makes is far, far easier to develop a client-server + mobile
web app than any other combination of server-side framework and client
libraries. You get web, Android and iOS apps from the same codebase, and
direct integration with the largest repository of libraries,
[https://www.npmjs.com/](https://www.npmjs.com/), with over 300k libraries.

Yes, 300k libraries means a lot of crap one, which is why there's
[http://npms.io](http://npms.io), which searches by code quality + popularity
+ how well the library is maintained.

Meteor covers security, authentication, database, client-server sync, mobile
app generation, but leaves the choice of front-end library to you. It works
with Polymer Paper Elements (Material Design for the web), as well as with
React.

It's an opinionated platform that makes a lot of choices for you, but has
become more and more flexible. You can swap the view layer, and the database
layer too (Postgres and MySQL are supported besides the default MongoDB).

More at
[https://wiki.dandascalescu.com/essays/why_meteor](https://wiki.dandascalescu.com/essays/why_meteor)

------
emodendroket
It can be OK, but yes.

------
jtrtoo
Yes.

------
justaaron
yes

------
the-agreeer
All these dozens of disparate ad-hoc web technologies and defacto standards
are built like a tower of babel on quicksand. No one truly understands all of
it. Without View Source and a healthy dose of copying/stealing no one could
get any of it to function. Yet in spite of all of this - this web thing
somehow works. The only takeaway is to not bother trying to grok all of it. It
would only lead to madness and missed deadlines. Just try to avoid frameworks
that emphasize purity of design over pragmatism and instead use a workflow
that gets you to the finish line.

~~~
AgentME
I think you're extremely overselling the complexity of things. Sure, there's a
lot of layers and parts involved in making web pages work and in the popular
web development ecosystem in general, but they were usually created to solve
specific problems, and knowing of them can help you recognize how problems you
may run into may be solved. None of them work by magic or are beyond
comprehension.

The browser speaks the HTTP protocol to a webserver, and receives primarily
HTML. The HTML is styled with CSS and can execute Javascript. Javascript
running in a web page uses the DOM (Document Object Model) to interact with
the page's HTML.

Javascript bundlers (Browserify, Webpack, etc) let you modularize your code
across multiple files and bundle it up into a single output file for browsers
to download. Javascript minifiers exist to strip out everything from a
Javascript source file that's not strictly necessary to execute it (comments,
whitespace, original variable names, etc) in order to make it smaller for
download. Various compile-to-javascript systems exist: Babel to let you use
upcoming Javascript features, Flow and Typescript to let you use annotations
for static typing, emscripten to let you C/C++ on the web, etc.

Like any other popular programming language, there's a healthy ecosystem of
libraries for Javascript. There are a lot for algorithms and data structures
like any other language, and you also have plenty specifically for adding
abstractions to using the DOM. The DOM is definitely usable on its own, but
many applications benefit from using abstractions from libraries to interact
with the DOM. This isn't very different from the popularity of GUI libraries
(Qt, GTK, MFC, wxWidgets, etc) in desktop applications over the raw OS
windowing APIs. jQuery provides a fluent API for manipulating sets of elements
directly. React provides a system for making modular user interfaces taking
some inspiration from functional programming and de-emphasizes manipulating
elements.

All of the parts mentioned above were introduced to solve a specific problem.
If you understand the problem they were built to solve, then their designs are
often intuitive. If you don't currently understand the problem they were built
to solve, then (for anything after the 2nd paragraph) you probably haven't hit
that problem and often don't need to use them.

~~~
the-agreeer
Thanks for a lesson on how the web works, but I'm already quite familiar with
it. Your long answer proves my point about its needless complexity and layer
upon layer of historical cruft. Can the complexity be buried under various
frameworks and toolkits? Sure, to some extent. But not entirely. Browser
inconsistencies always manage to sneak through forcing the developer to learn
the entire stack.

~~~
AgentME
If you do know that much, then I'd think painting the ecosystem as beyond
understanding seems a little disingenuous! A little sorry for the textwall, it
was mainly intended for outsiders considering webdev and got re-purposed into
a reply to you.

------
andrewmcwatters
The cleanest and most efficient methodologies for web development today are
largely unpopular.

The people who know how to write efficient websites, web pages, and web
software in general are going to be either the people who have been doing it
long enough to remember the old ways, or those who wade through enough of
today's bullshit to understand how to do things with less code, and faster
rendering times.

------
cureyourhead
We are all Windows programmers now.

The web is really just one enormous operating system we're all just hacking
on.

But it's only slightly better then this but not as clean as Linux. W3C sort of
plays the role of Torvalds

------
hmans
It's been ruined by a generation of developers who believe it a good idea to
build stateful applications on top of an inherently stateless document-centric
infrastructure.

~~~
logicallee
when I glance over your words I hear the sentence you've written in my mind's
ear - even though tongues were never made for speaking - we LITERALLY use an
organ that is for chewing and swallowing food, and using it to talk with,
which we can only do while our mouth isn't doing what it's actually built for,
which is to chew and swallow!

And that's what we choose to imitate to communicate with each other? A hack on
top of a hack!!! Why should I write something that makes you hear in your
mind's ear my chewing organ fashioning air.

Wouldn't it be a lot better to ACTUALLY communicate with you some kind of
direct meaning, rather than trying to jury-rig an entire civilization on top
of imitations of flapping meat? Plus, the spelling is linked with the meaning
anyway, if I had misspelled "meat" as "meet" just now you would have been
confused! So why not take away the part where you're hearing this in your
mind's ear, and just communicate!

blah blah blah. In other words, it doesn't matter what "INFRASTRUCTURE IS". A
two year old's infrastructure for language is a mouth organ that they also eat
with. It's OBVIOUSLY a design wart. This is completely obvious.

It also works. Gmail is fine and fun to use, even though as I type a to: field
it predicts the address. Not something a stateless document-centric
infrastructure was designed to do.

Oh well. It's called progress and civilization. It doesn't matter if it starts
with flapping a chewing organ, and then imitating a poor abstraction of that
through writing. who cares!

------
ionised
As primarily a back-end developer I am being exposed to some front-end work at
the moment with AngularJS/CoffeeScript.

I have to agree with you. I'm not enjoying it at all.

~~~
aredherring
I feel for you. You're being exposed to a framework that is a mess in one of
the [most hated languages of 2016][0]

[0]: [https://stackoverflow.com/research/developer-
survey-2016](https://stackoverflow.com/research/developer-survey-2016)

~~~
ionised
The most popular back-end language being Javascript makes me sad.

------
gjolund
In theory, no.

In practice, yes.

------
craigmcnamara
Nailed it!

------
forrestthewoods
Yes.

Whoa. Betteridge's law doesn't apply here. Weird!

