Ask HN: Why web frameworks are becoming so complex?

33 points by mr_nobody 10 years ago | 42 comments

A little about me: I am web-developer with almost 10 years of experience. I've spent lots of time in my life learning about design patterns, frameworks, and going through hundreds of programming blogs. I work mostly with quite big business apps (crm's, intranets) but also big frontend websites.

Since I started working as developer I can see that every year majority of leading frameworks (at least in PHP, Javascript, Ruby...) for web applications are becoming more and more complex. Instead of writing code in programing language we move into xml/yaml direction and hundreds of weird config files. Each frameworks use different syntax for config, often different templating languages, few layers of abstraction with a lot of magic behind the scene, Dependency Injections, ORM'S, CRUD generators with supposed to make our life easier actually are painful to use...

Even small website often requires hundreds of megabytes of dependencies. Sometimes one application can have 2 different build systems e.g. (ant, grunt) and few dependency managers...

Micro/nano services trend looks optimistic, but I am not sure if it's not double-edged sword, and instead of using complex frameworks developer will be forced to use complex communication system to orchestrate communication between them.

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

cnp 10 years ago |

The answer is simple: Web Applications are becoming Applications in the traditional sense of the word -- and Applications have always been complex. Now we're just moving that complexity on to the web.

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

gjolund 10 years ago | |

Webpack + React + Flux solves so many problems so elegantly.

They have done a phenomenal job of abstracting away complexity behind stable apis.

krapp 10 years ago |

>Instead of writing code in programing language we move into xml/yaml direction and hundreds of weird config files.

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.

bbcbasic 10 years ago | |

The problem with JS is not that is it aesthetically ugly, but the lack of a decent type system. The fact you can add whatever data you like to any object, and the object itself could be the data or a promise to return the data, and you cannot verify that the caller and callee are compatiable at compile time is asking for so much trouble. Let alone the nasty implicit type casting, two types of null value, truthy values etc. It is a real mess for the programmer who likes to reason about their code.

gjolund 10 years ago | | |

It is really difficult to explain the benefits of static analysis and type safety to people who only work in dynamically typed languages.

The JS community is just now being introduced to compilers, and there is significant push back and lots of people crying for "simpler age". I think it will be a while (if ever) until languages like closurescript, scalajs, & typescript start seeing widespread adoption outside of their fiefdoms (google, fb, microsoft).

If you are interested in a typesafe universal js ( or isomorphic js, whatever we are calling it now ) proof of concept you can check out this project using scalajs and scala-js react.

http://ochrons.github.io/scalajs-spa-tutorial/index.html

lewisl9029 10 years ago |

Innovation always leads to change. The fact that framework complexity has been increasing is only incidental.

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.

ghuntley 10 years ago | |

    > The web community pioneered UI development paradigms involving
    > functional programming techniques and immutable data

Ugh, No. https://raw.githubusercontent.com/papers-we-love/papers-we-l... and https://www.youtube.com/watch?v=Agu6jipKfYw

lewisl9029 10 years ago | | |

I'm honestly not aware of any UI development platform that makes heavy use of functional techniques and immutable data outside of the web. Sure, papers have been written about the idea, but where else has it been used in practice?

RE: the video. I'm almost certain you know this, but Elm is a part of the web community.

lollipop25 10 years ago |

> web applications are becoming more and more complex

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.

doobiaus 10 years ago |

We've come full circle and have just pulled our stack back from a complex framework (Durandal, akin to Angular) to a simple architecture centred around knockout.js, and everyone is happier for it. The code is cleaner and debugging is a world apart.

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.

px1999 10 years ago |

The theory is that a DSL should be better than whatever generalised programming language you're using. SQL is a good example - ORMs tend to fuck up querying databases (ie pulling back unnecessary data) almost as much as they fix. SQL, a language designed for querying relational data, is (unsurprisingly) pretty good at doing what you need efficiently.

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.

kup0 10 years ago |

It's annoyingly bad at this point. You know it's gotten bad whenever new frameworks are coming out where being "minimal" is a feature.

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.

ufmace 10 years ago |

I get where you're coming from - when the initial project for the framework you're working with has so much stuff that you don't understand or need yet, it feels like a huge burden to do the simplest thing in it.

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.

_w3e8 10 years ago | |

"It doesn't force any particular way of doing things onto you."

Might as well be

"Your app is spaghetti 1 year after you leave the company."

ufmace 10 years ago | | |

There's some truth to that. I think it's all about knowing the right tools for the job. If you spend several dev-years on a Sinatra app, then you probably will have a unmaintainable mess unless you have some good architects enforcing a sensible structure on it.

Sticking with Ruby for examples, if you want to put up a quickie site with 4 routes and no DB, then it seems kinda silly to pull in Rails and deal with all of the complexity and expectations. Throw up a Sinatra site and be done with it.

On the other hand, if you're getting more demand for it and now you want more logic and analytics and a DB after all and some user accounts etc, then you should know when it's time to move over to Rails.

msie 10 years ago |

I went to a simple website developed probably in the 90's with a simplistic comment board that let anyone submit a comment and specify their name. It was one of the best web experiences I had this week. Loaded up quickly and didn't have any useless animation. Did its job of letting users communicate with each other. No complex web framework needed.

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.

chipsy 10 years ago | |

When I realized that exposing configuration options is not DRY I was able to break away from most frameworks. Within the scope of your own project it's faster to change code, and once you do that you can start to customize it further.

mr_nobody 10 years ago | |

That's the point, these days it's even to start without IDE supporting code completion because of tons of vendors.

pags 10 years ago |

This sort of "complexity" (DI, ORM, extensive configuration) has existed for a long time, particularly in the Java webapp space.

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.

mr_nobody 10 years ago | |

It's not that these things are not clear for me, I build many successful applications using these technologies. Also in the past I was really happy using them, but lately I started to realise that it's usually just increase the time we need to spend building applications. I can't see what really I get in return. Especially debugging this kind of application is also hard, as we can not just set breakpoints in yml file.

rev_bird 10 years ago | | |

> I started to realise that it's usually just increase the time we need to spend building applications.

This might be because I'm not building anything that's going to blow the doors off of the internet, but I've found having at least a casual familiarity with a few frameworks (Django is the first that pops into my head, though you may be talking about .JS stuff) has made prototyping, at least, far simpler. Building a basic Python CRUD app from scratch, depending on what you're trying to do, could take, I'd guess, two weeks to get something* up and running. With Django, you could absolutely have your basic front-end and admin interface done in a day.

Once you get into the tricky bits (or just bumping against the edges of the Django database abstraction layer), yeah, I can see how it's annoying -- is that more what you're talking about with the "we can not just set breakpoints in yml file" bit? That setting up models by hand is more predictable than letting the framework do it?

noobermin 10 years ago | | |

I think an important part of this question is who is making you use such frameworks in the first place?

tremols 10 years ago |

Writing config files or filling some template classes instead of actual programming is pretty much the purpose of a framework. As a senior developer it may be your responsability to filter the hype from the real stuff as you can influence which technologies should be used in your projects. Fortunately there is a parallel universe of people developing wonderful libraries that you can combine and use as you wish.

lewiseason 10 years ago |

Arguably it's because websites (or more to the point web applications) are becoming more complex

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

Oras 10 years ago |

Complicated frameworks are pain in the ass, I fully understand but there is a value in following some "market standard" frameworks as they make the team speaks the same language and will make it easier to bring developers in at any time without long learning curve.

gjolund 10 years ago | |

Pick frameworks that solve problems you actually have and understand.

Your gripe isn't about the tooling, but developers ability to learn.

segmondy 10 years ago |

Because every new framework is trying to outdo all the previous frameworks, and they figure that by adding one, two or more feature is the key. You don't have to consume all the new stuff. You can always choose to stay lean.

gjolund 10 years ago |

I feel like most of the conversations around this topic boil down to:

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

GTFO of this industry then.

Gigablah 10 years ago | |

Yep, especially when they put no effort into understanding the design decisions behind different frameworks and glibly dismiss new ones as "hype" and "jerking off".

gjolund 10 years ago | | |

"Building blogs with wordpress is easy, so building facebook should be easy too."