Comment by phatbyte | Hacker News Reader

Comment by phatbyte | Hacker News Reader

Personally as a web developer I honestly wished this sort of tools started to get more and more traction. I'm getting a tad tired of using "dozens" of different languages and tools/frameworks to get a freaking website up and running by using good practices.

Quite frankly, I think web developers are, among all the IT people, the ones with more fragmented and disposable tools there is. If you look at a Mac developers, all they have is Xcode, that's it, one language, one framework to rule them all. Window developers have .NET. Game developers, they use one language/engine and that's it ! Not saying it's easier in anyway, just saying they don't worry about what tools to pick, they just do it, almost with just one language.

Web developers on the other hand have to work with a back-end and front-end language, deal with front-end JS mvc frameworks, maybe Coffescript instead ? CSS frameworks, or just use SASS ? cross-browsing issues and hacks, picking the right web server, database, VPN or CAP, on top of that you better have a task runner for all those "compiled" JS files and css, and a watcher so it compiles when you update a file..See where this is going ?

Plus web development tools are so volatile to change. Just look at Backbone for instance, last year it was the best thing for JS standalone apps. This year it's Ember... It's freaking insane IMO. So I really wish either OPA or something even more clever to come along and give us a little and let us just worry about building an app and not having to learn dozens of tools every year.

Having options is awesome, but needing to pick lots of options it's frustrating sometimes

The problem is less with the tools, and more with the people using the tools. When picking out a library/framework, you should look at how quickly it's evolving and how young it is. That's not specific to web technologies, that's universal. The just web makes it more prominent.

For example, Pylons/Pyramid, etc.: these frameworks are great and I was evaluating them vs Django a few years ago. Since then the projects have moved on and lots of stuff in them has changed. OTOH, Django code I wrote 4 years ago still functions today with some really minor modifications required to upgrade. No, it's not using class-based views since they weren't available back then, but (aside from a few critical things), I don't get any deprecation warnings.

In other words, when a library promises that it'll be quick to get started with it and that it will make you so much more productive, you are not done evaluating it. The equation is (initial savings - cost of future maintenance).

As far as I'm concerned, there isn't a great and stable UI framework for the frontend that exists today. Dojo is comprehensive but complicated, ExtJS is very nice but you cannot skin it, jQuery UI is unusable.

The other thing that makes this complicated is that JS UI kits need to evolve. There are probably only a handful of good ways to do networking code, but what a good webapp should look like changes constantly. As soon as you can package good design into a library it's no longer good design.

This is one of the reasons why I tend to stay on the lower end of the stack. There you can easily write stable, testable code and libraries tend to provide a stable interface or die quickly.

What you mention on the UI front is why I've been leaning more towards just using a nice base like bootstrap, and building from there. Once you are reliant on a full-featured toolkit, working on edge cases becomes much more complicated, not to mention maintenance and support. Things have been evolving fast since very early on... it's nowhere near as bad as the v4 browser days (IE4 & NN4, not HTML4)... Things will get more diverse, but I do think we will see at least some consolidation and reduction in popularity in the next 5 years, as many apps using the various frameworks start to retire.

Personally, I would like to see jQueryUI's widgets ported to use Bootstrap as a base theme. I think the interfaces for it are decent from the JS side, but the markup leaves little to be desired.

Agreed on the first part but who says you have to use this fashionable stuff? The web's underlying parts haven't changed in years so there's nothing wrong with just using, say, pure perl & JS, that is whatever gets the job done.

Of course with what you say, there is the <a href="http://xkcd.com/927/">obligatory XKCD reference</a>.

If you really want one toolkit to rule them, you could go with GWT, which is close... there are also up and coming frameworks using NodeJS, MongoDB etc... (like this one, Meteor, and Derby). It really depends... the problem is, "it's complicated"... You have frameworks with very few assumptions like Backbone, and you have frameworks with a LOT of assumptions... you have two-way binding or manual events.

The more "automagic" a framework is, the harder the edge cases get. For me, I've been leaning towards JS on the server, as you at least get rid of a lot of context switching. I know a lot of the guys coming from Ruby and Python tend to favor CoffeeScript, to be honest, other than writing configurations and tests, I don't like it as much.

The really funny thing is that E4X is already a standard, submitted by Mozilla years ago, that would act as an extension to the regexp parsing, and be a good fit for this. Unfortunately, the core V8 guys refuse to support it, and MS likely never would either. So we're stuck with string processing hacks, or abusing the DOM for these types of interactions.

I do like that Opa offers some more natural DB interactions... I think security implications get complicated as well, which is what makes me a bit fearful of these types of frameworks for any serious, public facing applications.

Opa has always treated security very carefully, as it was one of the original project goals. Strong static typing + the original native backend makes Opa one of the best candidates for secure web app. We're not vocal about this, but the company behind Opa has customers in the defense sector (in Europe, PRISM totally unrelated) for this reason.

By security, I mean user permissions... ex: User A can't edit records beloning to User B, but Manager C can see them both, and Admin D can see everything.

Many of these "Simple" frameworks that transparently pass stuff to the client-side forgo roles, accounts and ownership hierarchies.

In Opa, you have too mechanisms that combined provide probably a very high level of security in this sense too: 1) Algebraic constructs, so that the typing system checks properties like permissions automatically 2) Client "guards", aka protected values that can't be transmitted to the client, which Opa checks automatically.

The web isn't for you. If you want an authority figure telling you what tools to use, those platforms exist but it's not the way the web can or will ever be.

Not saying that. I just wished there wasn't so much fragmentation as there is.

> ... or will ever be.

You don't know that.

Reply on news.ycombinator.com