Ask HN: Is web programming a series of hacks on hacks?

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.

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.

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

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

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.

Like wtf is this:

https://www.npmjs.com/package/string.prototype.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.

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.

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

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/

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

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

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

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.

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.

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.

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.

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/

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?

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.

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.

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

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.

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

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>

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.

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.

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.

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

As for the server side and the client-server communication, nothing really beats 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).

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.

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.

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

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

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

John Carmack also agrees with you, though not about the web per se: 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.

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.

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

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.

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.

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.

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.

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.

  > a fairly long-lived and large code-base

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.

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.

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.

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.

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.

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.

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.

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.

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.

The least bad stack I've ever used is 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.

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.

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.

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/)

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.

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.

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.

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?

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.

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.

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.

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 :)

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

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

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

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

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

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

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.

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.

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.

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

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

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.

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.

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.

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

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.

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.

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.

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.

Haters are missing the big picture...

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.

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

And the DOM was.

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

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.

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

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

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.

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.

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.

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

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.

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.

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

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

In practice, yes.

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