Live data from Hacker News

Ask HN: Why web frameworks are becoming so complex?

news.ycombinator.com

41–44 of 44 posts

Re: Ask HN: Why web frameworks are becoming so complex?

#41

Earlier quoted context omitted.

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.

Notable examples on the desktop: GitHub for Mac (ReactiveCocca) and GitHub for Windows (ReactiveUI) - https://www.youtube.com/watch?v=1XNATGjqM6U and https://www.youtube.com/watch?v=HPyKHxy7X0w and http://web.archive.org/web/20120714082000/http://www.reactiv... (True Elm is part of the web-community, just saying React was not the first mover but I agree it will certainly be most likely the one that makes FRP cross th…

I appreciate your resources, namely the video by the creator of Elm, https://www.youtube.com/watch?v=Agu6jipKfYw.

However, I agree with above poster. I remember developing my first windows app by doing a main event loop. It's been that way for a long time. Only recently are we doing more asychronous callback / bound type mechanisms of reaction. And still not as strong as the FLP stuff mentioned in the video. Not as much functional stuff, just functional paradigms.

I personally really like the perfection of static input/output transformation graphs. But yeah..it's not been that way for a while and I agree with OP, the web being so event/input/signal based, has spurred the movement for better ways of reactive programming.

Re: Ask HN: Why web frameworks are becoming so complex?

#42
post #32

Earlier quoted context omitted.

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 value…

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 the…

It depends what you are doing. If you have 10 lines of JS then probably no need for an abstraction. However if you have 1000s of lines of client code, then using a purescript or similar can be very beneficial to maintainability and provability of the code.

But there is a learning curve and unlike Haskell where you just know have to know the language, you have to know both the JS quirks and the compiler's quirks too. It is a leaky abstraction. This is the problem I have with a lot of the compile-to-android frameworks vs. just putting with with Java.

Re: Ask HN: Why web frameworks are becoming so complex?

#43
post #35

Earlier quoted context omitted.

I was with you initially, but this seems hostile in a way that's honestly kind of confusing. The argument, as I understand it, isn't something like "websites are too complex now," it's that "web-app programming is becoming more complex without corresponding returns on functionality or UX." Your example, though it's buried under a bunch of stuff calling people dumbasses, makes an interesting point: You're right, there…

If I seemed hostile, it is because I am dealing with this exact topic on almost a per contract basis, and it is becoming exhausting. However I don't recall calling anyone a dumbass. Here are some ( sanitized ) examples from my current project that exemplify the danger of allowing this line of thinking among your contractors: 1. Completely unmanaged client dependencies on a per page basis ( negligible code, infinite h…

We initially may have seemed to have different ideas of "simplicity", because I certainly agree that if using a framework works for a site, and allows you to re-use code to avoid extra lines (like the extra CSS, jQuery, etc. you mention) then that is the best way to go.

When I said simple, maybe I meant "efficient" instead. I just see a lot of misuse of frameworks where all of the code is thrown in and then barely customized to make it work, and all the extra unused cruft is left in. Basically pages are loading a bunch of stuff that is never actually used...

So I think maybe we were speaking past each other a bit, because I generally agree with you.

The initial post at first seemed a bit hostile, but some of that I think we're inferring- because we're reading our own tone into the text. Also, as you said, it's something you constantly deal with, so I'm sure it's a big point of frustration for you.

When frameworks work to allow you to clean up a codebase or prevent it from becoming the mess you describe, then they definitely make sense. When they cause bloat for no good reason- that's when I have a problem with them.

I guess it all comes down to developer use/misuse of them, not the frameworks themselves, in most cases.

Re: Ask HN: Why web frameworks are becoming so complex?

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

Post reply on HN