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'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 'fast learner' who quickly knows the system inside-out, even when thrown into some area that I've never seen.

Lately I've been doing some web development on a fairly long-lived and large code-base, but I'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'm familiar with the history, been using the Internet since before the web) 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, but just the fact that it really feels like there'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.

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?

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 - where everything is in Python, and the GUI is drag'n'drop.

[lobster_johnson]

React is, in my opinion, a big step forward in reclaiming the front end as a mature UI environment.

I have also found that CSS becomes a lot more tolerable with CSS Modules, in combination with React, which allows you to write CSS that targets one component and only that component. By eschewing cascading, you can finally write modular, reusable CSS that avoids side effects and still allows fine-tuning (overriding) by the component user.

[captainbenises]

This post makes me sad. Javascript, CSS and HTML can all be used powerfully, performantly and in a managed way where anyone can come on board and contribute. Facebook, Google and Microsoft all use the web stack to run huge companies. To broadly paint this web stack that so many people poured countless hours into making, as 'impossible' to use is doing it a great disservice.

But hey man, that's just like your opinion.

[segmondy]

Languages don't scale. Systems scale. Without said, Javascript has never really been the language for programming in the large. But make no mistake about it, it's slowly getting there as is evident by huge applications, not just web but even desktop that are being built with it. It's not impossible to refactor. The issue from what I've seen is that people think it as if it's a class based language instead of the prototypical language that is.

[kenbellows]

Minor comment regarding CSS: Flexbox alone was never supposed to fix layout; the real magic is supposed to be Flexbox + CSS Grid. As I understand it, Flexbox is truly designed for use in one dimension to govern local dynamic behavior within a larger CSS Grid layout that structures the whole page. At the moment the problem is the lack of CSS Grid adoption by browsers (see http://caniuse.com/#feat=css-grid). I'm still hopeful that the state of CSS layouts will drastically improve once Grid and Flexbox are both sufficiently supported.

[jordanlev]

CSS is not impossible to manage if you keep things modular and avoid specificity issue (basically, use something like BEM and pretend the "C" in "CSS" doesn't exist).

re: HTML: layout and positioning is the domain of CSS, not HTML. HTML's purpose is to provide semantic structure to the content and non-semantic styling hooks (divs and classes) for CSS.

It's true that layout has sucked for a long time (more accurately, it hasn't really existed in CSS), but with the coming grid spec, it will finally get a lot better. Flexbox is great for solving certain problems, but wasn't intended to deal with overall page layout. (Basically, flexbox is for laying out one dimension -- a single row or column -- whereas the grid layout spec will handle two-dimensions.)

[veidelis]

We use TypeScript and at first it seems like a burden, but pays off after a while. We used to have a problem with CSS - every time we had to implement some new UI, we just ended writing stronger selectors to override the parts that felt would break if we refactored them. CSS modules solves that problem for us. It's nice that we are allowed to use flexbox. The biggest problems for us are that <video> events are not being dispatched properly or scaling problems when keyboard appears.

[myfonj]

> HTML - At the heart of it, the foundation is the layout engine and positioning

I'd oppose: HTML is particularly a Markup Language for (more or less) semantically structured static documents tied together with Hyper Text links (see the abbreviation?). It has with very limited (if any) amount of layout, positioning and visual hints incorporated; these things are supposed to be left for the CSS.

[mncolinlee]

These complaints are all valid and serious. I believe the solutions involve writing more readable code in languages that compile down to Javascript, CSS, and HTML.

There are thousands of languages that compile down to JS. https://github.com/jashkenas/coffeescript/wiki/List-of-langu...

There are several languages that compile to CSS, like COMPASS and SASS.

There are various document formats that freely convert to and from HTML, like Markdown and DocBook. However, HTML is probably the most readable of JS/CSS/HTML.

While you can write native JS/CSS/HTML, you're inviting unintended complexity to your project whether or not you remember sending the invitation. There's nothing wrong with that, but you should be aware which choices are best for your team and for the scope and requirements of your project.

[tengbretson]

> JavaScript - Dynamically typed, does not scale

What does this even mean? I see the phrase "does not scale" bandied about all the time. In what way is a language supposed to scale? It seems like its just the latest semi-technical hand-wavy way to disparage something.

[nameless912]

Blaming JavaScript's failure to be maintainable on being dynamically typed is a bit of a red herring in my opinion. Lots of dynamically typed (or, more accurately, duck-typed) languages have plenty of facility to make good, maintainable code, and JavaScript does too. The problem is that JavaScript has more warts than good parts, and the warts prove to be too easy a temptation for many average programmers.

[snicky]

While I agree with most of what you wrote, I also understand where it all came from. We have a handful of browsers which all implement w3c guidelines in their own way and there's no single de-facto standard of how one should write for web. Yet we write milions of different websites and they have to be properly displayed on at least a couple of popular browsers, no matter how bad they interpret the guidelines.

Yes JS is a major pain in the a and there are loads of various packages achieving the same things floating around, there's no agreement regarding which package manager to use and everybody uses different implementation or wrapper (es6, es7, typescript, flowscript, coffee), but if you look around you can find solutions that are actually really helpful to manage the mess. It helped me a lot when I started to write JS in a OOP fashion utilizing dependency injection and MVVM. The real trick is to realize which technology is really helpful and which is just bloat. I don't think this is much different from the backend programming.

In terms of CSS it's a whole world on its own and I keep repeating that managing it properly is well underestimated. It requires making lots of predictions about how you might extend your site in the future. Luckily, there is also plenty of great reusable boilerplates made by very smart people like bootstrap or materializecss. Bootstrap did change a lot how we write and think about our styles. Btw, leave classes for styling and use ids for js instead.

Finally, I don't agree with your opinion on HTML at all. It's super simple and you can build anything with it. I have learned the basics and built my "home page" when I was 12. These days kids are probably building sites before they even go to school. Also, as mentioned above you have to fit dozens of different browsers and hundreds of thousands of various devices. I find building UIs on iOS and Android not much easier, even though you build for a single system. Nonetheless I'm waiting to see how people could improve building UIs in the future, without falling into "everything looks and feels like wordpress" kinda world.

[andrei_says_]

I think it's important to acknowledge that today we're using CSS in ways that were hard if not impossible to imagine for the creators of the standard years ago.

The much higher complexity requires new ways of thinking and methodologies.

BEM for example is one such approach which helps with scaling.

[erlich]

It sounds like you are unfamiliar with what modern JS looks like.

> JavaScript - Dynamically typed, does not scale what so ever.

Flow has resolved this. It has good investment from Facebook, plenty of adoption, a flexible type system, and you can sprinkle it into existing code as you like.

Also try wallaby.js for instant test running.

> CSS - Also becomes impossible to manage.

See webpack's local css scope. https://github.com/webpack/css-loader.

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

Bootstrap or any million css libraries. Just have to wait for Flexbox and we are good.

[unclebucknasty]

Indeed. You only left out the proliferation of frameworks du jour, which promised to deliver us from this pain, yet somehow seemed to only amplify it with additional layers of pain.

[0xmohit]

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

Consider the _brighter_ side of it:

- the one who authored the code is irreplaceable

- employment generation: many more are needed to maintain (and possibly enhance) what one person might have written

[jawarner]

So instead, just use:

* TypeScript * Sass * A data-binding framework like Angular

Problems solved :)

[HeavyStorm]

Only, in my case, I don't think of it as high paying.

[zyngaro]

When I see something like visual studio code to cite the first that comes to mind I think that these claims are overstated.

[lucb1e]

> Same problem, read-only, it only gets bigger

I think that's write-only

[LBarret]

look at elmlang maybe ? it solves a few of these problems, but this is quite different from what we are used to.

[gaius]

The web was conceived for hypertext and doesn't do a bad job of it.

The actual problem is that people took something that was always intended for displaying (illustrated but mainly text) documents that happened to have clickable words that would display other documents, and tried to make it do desktop-style applications too. We've been hammering square pegs into round holes ever since.

And the infuriating thing is we had a great system for doing what HTML+JS+AJAX etc etc does now - it was called NEWS. But those who forget history are doomed to repeat it, first as tragedy and then as farce. Not sure which stage we're on now, maybe both.

[douche]

I think you mean write-only.

It doesn't help that the inclination to minify and bundle CSS and JS makes them somewhat impervious to organization. Sourcemaps are supposed to help with that, or so I've heard... they are another of those things that I've not seen work reliably.

[simonhamp]

When you build a better language, server platform, viewer application, development tools and ecosystem that can create, render, transmit and load dynamic user interfaces over the wire - even rapidly on limited bandwidth connections - please let me know ;)

I'm not saying it's the best thing ever, but we're not doing too badly all things considered.

The web is still young. Let's work together to make it what we want it to be - what it should be - instead of moaning about what it isn't.

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

[adrianratnapala]

Remember MS-DOS also succeeded because of its "strengths" in some very special, narrow sense. In the more ordinary sense, it succeeded in spite of its weakness, but Windows has slowly recovered from that and is now a good system.

The modern web is somewhat the the reverse: it is worse than its progenitor. HTML, HTTP and what would eventually be called ReST were all good ideas and succeeded because (a) they were a good way to put hyperlinked multimedia on the internet and (b) hyperlinked multimedia turned out to be the thing that masses of users wanted.

The subsequent effort to retrofit that and turn it into a zero-install software delivery platform is where all the insane hackery comes from; and the hacks that succeeded didn't have to be good. They are just what worked at the time with some combination of IE, Netscape and Flash.

[Scarbutt]

IMO the browser's strength is really 'zero-install distribution of applications', I don't think HTML/CSS/JS have anything to do with it.

Having said that, I think your argument its a straw-man, back-end web development is just a part (sometimes even unnecessary) of browser programming.

[mastazi]

> Making a neural net?

That's not as constrained as you might think[1] but yes, I get your main point and, as a back-end web developer, I agree.

[1] https://en.wikipedia.org/wiki/Comparison_of_deep_learning_so...

[bbcbasic]

JVM can be targeted from Scala or Frege too.

You argument boils down to transpiler availability.

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

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

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

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

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

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

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

[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... . This was an enabler for complexity to spiral out of control.

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

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

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

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

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

[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

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?

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

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