Here are my thoughts, but you won't like them. Stop with the frameworks. Learn Javascript. Learn CSS. Learn HTML. You'll find pretty quickly that what you need are libraries, not frameworks. Things like jQuery, underscore, etc...
>Stop with the frameworks. Learn Javascript. Learn CSS. Learn HTML.
That's good advice to someone that might be asking about using a framework. But to someone that has written a framework they probably have a pretty good understanding of Javascript already, and if they didn't it will have improved greatly by the time they are done.
The Stop with the frameworks idea still applies doesn't it?
I don't code in JS. Maybe a few lines once in a while when it pops up. It just seems like an MVC framework is the javascript equivalent of writing your first recursive factorial function.
A developer I worked with several companies ago told me the same type of thing about learning OO "Its not necessary just learn to code better".
The fact of the matter is large code bases need to be supported over time by diverse groups of people and frameworks help enforce standards that get people up to speed quickly.
That developer I knew, he has been chronically unemployed for the last 5 years because he lacks the skills to work as part of a team. Great coder though!
I second that. I have met a number of devs who are not idiots, have good analytical thinking, but refuse using frameworks, libraries, etc. The result is unmaintainable code base, which no one wants to maintain, and re-writing is too expensive so the business owner is, well, fucked.
The majority of the Web apps is CRUD + a bit of logic. It makes much more sense to use a framework because 1) most of the things are already there 2) easier to maintain for someone from outside 3) and, most importantly, very few developers have skills to create a nice, maintainable design, accompanied with a useful documentation.
Yes, in ideal world, maybe you should be able to stay framework-less (just made that word up) but the world isn't ideal. We have to sacrifice philosophical ideals for the business because that's what pays the living.
In rare cases, when the app is much more than a simple CRUD, it might make sense to ditch frameworks... But it's very, very rare.
Sorry, he's not a great coder. I think there is a big difference between saying "just learn to code better" and "use the right tool for the job" (which was the intent of my post).
I'll add an addendum to my post that frameworks can be the right tool for the job. But 99% of the time they're used the wrong way and for the wrong purpose.
Sounds great until you have a team of 5 developers maintaining at least a semi-huge code base over the course of some years. Some people leave, new join the team.
Then you really start appreciating frameworks if only for their conventions to structure the code. Top coders can write web apps with jQuery and underscore alone, but everyone else is better off following some conventions.
HTML, css, JS (jquery) have stable APIs, when new developers come they don't have to learn something new.
If your code degrade over time, sorry to tell you, a framework won't solve the problem.
If you have coders that don't care about maintainability of code correction, code organization in whatever technology, they won't care about what you wish.
As usual, they won't take the time to learn the frameworks, will diverge, and you are back to square one with no code that can be salvaged or reused. (at least with vanilla techs you may salvage stuffs)
I think you use frameworks to solve the wrong problems here: you are probably the problem by trying to ditch the lack of real engineering skills in IT (not the letter of engineering. The spirit: making things that are correctly built and are reliable over time... like a plane).
Well I think we'll just have to disagree here. I think you are patently wrong if you really believe you can keep up maintainability of a largish codebase by appealing to craftmanship in a real-world company.
This is all nice and well in academics and start-ups but some years down the road, your code is going to be a mess. Frameworks, especially opinionated frameworks are a tremendous help. Coding in jQuery or native JS without some prodding is at best an accident waiting to happen.
In my experience, the only reason the code is going to be a mess is because the company hired a bunch of junior developers and gave them "Architect" titles. I can show time and time again that with a team of seasoned engineers the code not only isn't a mess but in fact there is less code that does more, and does it more efficiently.
Actually, this is kind of the spirit of Mithril. It's really a tiny collection of standalone useful functions that also happen to work well together. Ironically, your examples of "libraries" are both quite big in the context of the "lean learner" mentality, and in comparison to Mithril.
That's similar to my viewpoint. Stop with all the frameworks - what new, powerful functionality will it provide your users that existing things can't do (ie JQuery, raw JS)?
Faster development, potentially less bugs, conventions, etc. All of that is highly dependent on what your projects needs but I can't imagine writing some of the Ember apps I've worked on in just plain jQuery while maintaining a clean and readable code base.
You eventually end up writing your own framework of sorts anyway when you take minimal path.
the point of a framework is speedy development. less lines of code for results. the tradeoff is often bloat, which one should (ideally) refactor out later. Angular can get overwhelmingly slow if you're not careful with your code, but gosh dang, you sure can whip an app up pretty fast
For most apps, I've found that slowness is not a problem with Angular. You can do some nasty things though if you're not careful though, definitely agree with that. If you have flaws elsewhere in your codebase, including the backend, it may be possible that in practice, the effects may trickle down to your frontend code with Angular - it has happened in an app I've worked on with a couple of other developers, in which flaws with the api performance caused us to implement some subpar workarounds that triggered many $digests & forced us to spend a day or two on just optimization.
Angular can be quite fast compared to jQuery in an app of substance. It is not constantly reading/writing to the DOM in most cases, which saves a lot on the performance front. It is also a smaller library than jQuery, and you're not naively applying global or complicated selectors. Plugins rewritten to be pure javascript + Angular also can have a much smaller footprint & be more powerful to boot, such as the Angular UI Bootstrap project (5 KB minified & gzipped as opposed to 15-35 KB? I forget Bootstrap's js size) & contains all of the power of Angular to modify your functionality with them & more.
I don't like rewriting boilerplate code for every new project-- as I see it, Angular is to jQuery what jQuery is to raw JS, just in terms of reimplementing basic functions for the nth time.
Of course, if a framework automates a ton of functionality, it'll naturally be inappropriate for certain projects. I wouldn't try to use Angular for an HTML 5 game, for example, though there's a good chance I wouldn't use jQuery either.
> I wouldn't try to use Angular for an HTML 5 game, for example, though there's a good chance I wouldn't use jQuery either.
I actually did use Angular for an HTML5 game last week as part of a demo for a conference. Admittedly it was a really simple game (tic tac toe), and it did use Polymer as well as angular, as sort of an experiment. But it worked pretty well, and only took about a day and a half to hack together, with realtime multiplayer and chat using socket.io.
Obviously you're going to run into things that Angular is not really ideal for, but we are trying to make it do what it does very, very well, so in the future it should be suitable for pretty much any mobile or desktop app.
---
This sounds like evangelism, which is not my intent, you're absolutely right about what you're saying, but it's true, sometimes a framework works (and saves a ton of time) that you'd otherwise spend hacking together something awful. Hopefully this mithril thing also saves people a ton of time without them having to worry about numerous other issues.
Ehh I know Javascript, and know it well, along with HTML+CSS. My experience is that a very light framework can not only help structure things in a more sane way, but can provide a set of tools that make a mindset easier.
After building/using Composer.js (http://lyonbros.github.io/composer.js/) extensively I inevitably end up reimplementing parts of it on projects that don't use it because it makes some things so easy.
That said, if you're learning javascript, stay away from frameworks at all costs.
That's sort of like the tone Microsoft took after releasing ie6. Landscapes change. Every single js framework in existence today will be unfit for purpose in 10 years. So we enhance the frameworks we have and try out new ones so in 10 years time we don't find ourselves stuck with tools that don't work anymore.
The problem is the shear volume of new frameworks. Writing your own framework has almost become a rite of passage for software developers. And I'm not knocking that. I did it myself. I learned a lot, the most important of which was that my framework was crap and that I didn't really need it at all.
Ehh. As a developer, I find the best way to understand a concept is to sometimes implement it from scratch. Sometimes your implementation may just be for your own edification on how the patten (doesn't) works, other times it can be useful for others.
