Comment by mrcwinn | Hacker News Reader

Comment by mrcwinn | Hacker News Reader

Parent Full thread

I really hope the JavaScript community (or especially a smaller universe within that, framework developers) would step back and focus on simplicity, small codebases, thoughtful patterns, tried and true methods.

The good news is the JS community is filled with young developers with a lot of enthusiasm and new ideas. The bad news is young developers tend not to have the advantage that comes with experience or a respect for the history of previous implementations.

I'm often horrified by some of the JavaScript I see - including very popular frameworks that developers "love" written by engineers people respect. The complexity is frightening, and every month there's some new word or phrase describing a programming concept I've simply never seen before.

Maybe some of it is necessary - an honest attempt to satisfy the needs of a browser client, rather than a server. But my gut tells me this over-complexity is the result of not yet finding the answer to a question, or having the burden of satisfying backwards compatibility to last week's crap idea.

A rich, vibrant ecosystem is great, but I would love to see a more stable, thoughtful one as well. I'd love to see a community as committed to maintaining things that work, as they are to creating new things. I'd love to see young developers put a premium on using what is proven, not just what is exciting.

In other words, it's up to all of us to be careful with our votes. In some societies, you "vote" in the marketplace with the money that you spend. In our world of engineering, we cast a vote every time we star a repo, create a new fork, issue a pull request, or make a GET request to pull down the library into our project. Take the time to honestly assess how good something is, and whether you think it'll still be around in 5 or 10 years. It's really important we take the time to craft wonderful software.

I fully agree.

That's one of the reasons when I'm a part of a team and I need to make a decision about a framework, I usually go with Backbone. It's source code consists of one file that can be understood for less than an hour.

Last non-sense in this complexity is the boom of JavaScript framework specific languages that pop up. Like ReactJS and recently Angular 2.0 is preparing their own language for using it's platform.

I completely agree about Backbone. Backbone is a very simple tool. You can do a lot of damage if you're not yet a very good developer (or a very good Backbone developer), but if you care about your craft and the design of your application, it's fantastic. In fact, having the flexibility to make decisions about your application, forces you to make good design decisions. That is the mark of a great developer.

With these other frameworks, which might be very large or very slow or very complicated, they enforce that design on you. For most projects, who cares? Use whatever is fun for you to use. Learn 'em all. But at a certain scale, it matters deeply what you hitch your wagon to.

As the person who has been resisting adding more magic to Backbone for several years ... it's awfully nice to hear this sort of thing. Cheers.

Hi, thanks for the great work on Backbone! Appreciate it.

How does Backbone relate to the points the original article makes? What are your comments?

I completely disagree about Backbone. Sure, what Backbone does can be understood in about an hour, but since it isn't very opinionated and since it doesn't do very much for you, you end up having to figure out every single codebase you step into. Yes, Ember is annoying when it isn't working. I once spend four days (!!) tracking down why something wasn't working when I was first learning Ember, but I can look at any Ember code base and understand it in under an hour whereas with Backbone and Angular I see people implementing their own (often broken) patterns and solutions.

I think your argument benefits my opinion. I'm using Backbone exactly for the reason that you state you've been.

I don't want to put a client ( I work as a freelancer ) in the position to look for someone that knows framework "A" or "B". Also I'm pretty sure "A" or "B" will soon be obsolete and the successor will need to change the whole codebase, instead of improving it.

I'm not talking about Ember, actually I'm also using it, but when it happens to go for scalable project I would prefer Backbone, because of team members learning curve and potential developers availability.

I think he's arguing that Backbone.js in itself is fine but since it doesn't do much you have to add plugins or write your own implementation of the missing parts.

The issue with that is that the learning curve is now higher because the chances that a developer knows those missing parts that you added or coded is increasingly small.

Btw, I'm a heavy Backbone.js user so I still think it's a better option compared to other MVC flavours but I do have the problem that a lot of things related to data binding and UI animations is custom built and have the issue described above.

5 or 10 years! Really? I don't want to be using the same frameworks for 5 or 10 months! I can't imagine 5 or 10 years! That's why I jump from job to job; so I don't ever have to be a lowlife maintenance developer.

/S

I think it's more of an honest attempt to satisfy the very low barrier to entry that's been created to web development. "Anyone can do it!" is now coming back to bite, hard. Not saying that everyone couldn't do it, but it has had some unintended side effects.

What I see, and this may or may not be the case, is that web development still gets a pretty bad rap among those doing other kinds of software engineering which lead to a lot of isolated development of tools/libraries/etc that didn't give much thought to the patterns of yore/other software crafts.

What are the other types of software engineering that you mention? I mean this sincerely, I've only ever worked in or around web development.

Systems development, game development, app development, scientific/data programming, etc. Some of these lie closer on the spectrum to web development than others but web seems to be the only one having these growing pains.

> web seems to be the only one having these growing pains.

Mostly because web development believes itself to be drastically different from every type of software in the past.

Of course, it isn't. It's bog-standard business programming piled on with loads of incidental complexity that happens to be 'open.'

The only thing different is everyone feels subject to Internet Time, and speed to ship is valued over everything, including vision, conceptual clarity, and correctness.

From my experience/observation, I believe this is what EmberJS is trying to do, combine best practices of the past with new learnings today. SmallTalk for example, heavily influences the framework, as does a number of historically successful frameworks. I am not arguing that Ember is perfect, but I believe what you state is part of their objective.

Reply on news.ycombinator.com