Ask HN: Why web frameworks are becoming so complex?

But that said, the Webpack + React + Flux model is the simplest kind of programming I've done in a very long while.

Blame this partially on the weird phenomenon of programmers refusing to touch languages they consider aesthetically ugly. Javascript? CSS? Ick. Much better to pile on a build system to compile those languages from another language that looks kind of Ruby. HTML? Ew - no significant whitespace. Let's generate HTML from something that looks and acts like Python.

But, snark aside, I think it's a good thing if a framework can be agnostic about the kind of configuration syntax it uses, although that in and of itself implies some minimal complexity. Whatever choices the developers make about this, of course, amount to personal preference. Heck, I prefer INI files for configuration.

>Even small website often requires hundreds of megabytes of dependencies

That depends on the language and framework you're using. And how small you consider a "small" website.

Unfortunately (in my opinion, with which I know others will disagree) frameworks tend to want to do too much, and as such tend to bloat into vast, overly complex attempts at reinventing the wheel, the chassis, the transmission, the bumpers and deciding what kind of air freshener you should want hanging from the mirror. I would prefer a framework not have a templating library or ORM or code generators baked in at all. Those should be implementation specific decisions. Rather, a framework should manage dependencies, routing, global config, responses, have some hooks to allow extensibility - the basics. If I want more, I can pick libraries for that.

In fact, I think we're starting to see a trend in the other direction. Angular 1 was a massive mess of complexity, but Angular 2, React-based frameworks, and various other frameworks coming out these days tend to be much simpler.

Believe it or not, the web has been the platform where most of the innovation in UI development paradigms has been taking place in the past few years. And I don't just mean in terms of the sheer number of new things coming out.

The web community pioneered UI development paradigms involving functional programming techniques and immutable data, and have brought its benefits to other platforms (through React Native). I personally would never want to go back to the old way of building UIs. And I suspect I'll feel the same way about client-centric data fetching when I get to try out Relay/GraphQL, Falcor, Om Next, etc in production.

If constant change is the price we have to pay for innovation at such a relentless pace, I personally welcome it with open arms.

The way I see it, it's becoming complex the more you learn. For instance, the first time one learns a programming language, one learns the language and steers clear of frameworks. The deeper you go, you learn tricks and stuff "which this library does" or "this framework does". Eventually you get exposed to the stuff that does more stuff in less work, away from the programming and more on configuring.

> Even small website often requires hundreds of megabytes of dependencies.

You wouldn't want to write those from scratch.

> Sometimes one application can have 2 different build systems

One tends to use the build system in the language nearest to the platform. I still have yet to see a person write Grunt on a Java project or Maven on a JS project.

> Micro/nano services trend looks optimistic, but I am not sure if it's not double-edged sword

It is double edged. More control but you need to set configurations, set conventions. Do it wrong, and it's easily spaghetti.

> In few years instead of writing code are we going to write configs files?

For all that configuration, your are configuring something. That something is written by someone. So while you're configuring here, someone is programming somewhere.

Backend wise I've taken a liking to Express because it hides nothing. I prefer it over Rails or ASP.NET MVC, where there is so much magic. I would switch if I could but we have too much legacy code.

In practice, a lot of frameworks are made by people (who are just people, and don't 100% know what they're doing at the outset). I'd say that if you're spending too much time in configuration, you're not using the right frameworks.

No, in a few years those frameworks will be forgotten. From the terms that you've used, it sounds as though you're coming from the Java world, which has an inexplicable love of config files - if that's the case, it might be a bit longer than a few years, but they'll eventually figure out that config files aren't a good representation for options.

Though the layers of magic and abstraction will continue to increase and grow, at least until simple LOB usecases can be achieved in a couple of lines at most.

Page loads are very large on some sites now, where they don't have to be. Though, advertising can be blamed for a lot of that. There's just a lot of extra cruft out there now, without much added to the user experience, in fact, it often detracts from it.

What happened to using only what is necessary? Why throw so much unused stuff behind a site, and especially, why load anything you're not using? Why complicate things?

Maybe I'm nostalgic for static pages or something, but I miss the days where things were simple in terms of page loads and efficient design, and I think a technologically-advanced but focused (avoiding excessiveness) approach is best going forward.

This philosophical approach is one reason I like the Hacker News site itself. It accomplishes its task well, and is almost solely text and minimal css. It's running on some stuff built underneath (as dynamic pages require), but it seems pretty minimal in general. It needs nothing extra.

You might want to give Ruby Sinatra a whirl. I just helped a friend build a starter site in it. The Hello World for it is 1 file with 4 lines of Ruby, no config files at all. Save that 1 file, run it, and you have a live website.

What I think really makes it cool is that there is a decent amount of sophistication to it, but you only see it when you need it. It doesn't force any particular way of doing things onto you. It's also kind of a cousin of Rails, so if your needs get to that level, you should be able to switch over pretty easily and make use of the enormous ecosystem of gems.

I think express.js on Node has kind of the same idea, might be worth a look also.

I think complex web frameworks are developed by expert coders to make their lives easier, supposedly. With little concern for other less-expert developers. But it just turns out to be so complex because they are trying to DRY the shit out of everything.

You don't need a license to release a framework, and a framework doesn't have to be sensical to be adopted.

If you learn the fundamentals of the things you're working with, particularly HTTP, web browsers, the web in general, and your chosen programming languages, things will become much more clear.

In my experience, the widely-used ones tend to be fairly sane for the most part, and can often be used without having to delve too much into the complexity unless you need to - which I think is the important bit

"I don't want to have to learn new stuff."

GTFO of this industry then.