(Not saying that this is bad -- just a random rant)
On a related topic, I talk about complexity walls (the idea of code that outgrows a framework's zone of comfort) here ( http://lhorie.github.io/mithril-blog/decreasing-cognitive-lo... ) and there are slides for a presentation I gave a while back that talks about the design decisions that went into Mithril to reduce learning curves. (here: http://lhorie.github.io/mithril-presentation-oct-js-tech-nig... )
--After doing some reading it looks like it replaces some of knockout and sammy but I'd lose data binding and dependency tracking of knockout.
Dependency tracking can refer to two things: tracking changes for the purpose of updating the DOM (which Mithril does handle, albeit in a different way), or computed properties (which I personally think are not a good idea, but that you could do w/ an observable library from microjs)
Hopefully, in time, more people will realise the "zen" of mithril's minimal approach. In the meantime, interested readers can check out lichess.org, which recently rewrote its impressive UI using mithril.
Mithril is an awesome framework. A breath of fresh air really.
return m("html", [
m("body", [
m("input"),
m("button", "Add"),
m("table", [
m("tr", [
m("td", [
m("input[type=checkbox]")
]),
m("td", "task description"),
])
])
])
return <html>
<body>
<input>
<button>Add</button>
<table>
<tbody>
<tr>
<td><input type="checkbox"/></td>
<td>task description</td>
</tr>
</tbody>
</table>
</body>
</html>
m "body",
m "input"
m "button", "Add"
m "table",
m "tr",
m "td",
m "input[type=checkbox]"
m "td", "task description"Now I'm considering going back and giving it another try. It takes more time to get up and running with GWT, sure, but the stuff you do write with it is written in... well... a real language with types and good tooling and real design patterns. The result is an application you can maintain and build upon for a long period of time rather than a heap of web cruft that collapses quickly under its own weight.
I know it's not sexy, but I've had the same experience you've had with "sexy." I'm becoming generally disillusioned with weakly typed and even dynamically typed languages -- they're fast to write but hard to maintain over long periods of time.
But comparing a functional scripting language with a object-oriented statically-typed pre-compiled language, arguing one is better than the other, does not make sense to me.
You can easily revert the situation and say that static typing is a weakness of java, and it's poor fucntional (until before v8) capability is a drawback and a strong point for Javascript.
I'm not into the JS world so I can't say anything about the tooling, but yes, Java's tooling and ecosystem is an extremely strong point.
My complaint is about dismissing Javascript as not a "real language" while it's got A LOT going for it.
EDIT: I also worked with GWT (GXT from ExtJs, actually) in 2011-2012, and it was really nice. I miss it.
GWT can output to ExtJS, to <insert next HTML5/JS framework>, to <future platform>. And barring minor changes, your code stays the same.
Now that is worth the investment.
We ran into some GWT compilation issues mainly due to code size a couple of times with some browsers, like Safari, that left us dead in the water until Google released an update.
The second project used vanilla GWT and we were very happy with how performant it was. But we avoided lots of GWT features which seem over-engineered and complicated. We used JSON overlay types instead of RPC calls (which made our compilation / or dev mode much faster - I forget honestly). We avoided MVP, because I never met anyone who actually fully understood MVP with GWT. Instead, we had a very simple MVC structure that worked great for us (but lacked unit tests..). We avoided most of the CSS features because the complexity/value wasn't favorable for us.
Moved on to a JS project afterwards and it was a breath of fresh air.
On the one hand I wish that the docs for these projects could speak to those concerns, but on the other hand I'm not even sure how they would do that successfully. When something is this young it just takes time to figure out how it's going to survive and be maintained.
I remember the days of using prototype.js over jquery. If only someone could have saved me the time.
Ask yourself: at the time you used prototype.js, did it save time on the project?
If you answered Yes, then it was never a waste of time. Knowing prototype.js AND jQuery makes you a better developer: you learned the hard way that abusing prototypes can lead to hard-to-understand code. That can only be a good thing!
Community support makes such a big difference, and now that I'm further down the line I'm averse to having to basically make a bet up front.
There was plenty of criticism from the JS world when Prototype came out, and the main issue everyone had was how Prototype attempted to shoehorn classical OOP into JavaScript (hence, the abuse of prototypes and fake class inheritance), which is a mistake amateur JS developers make to this day. jQuery has at least made it so using the most popular DOM abstraction framework didn't also mean you were running less-than-ideal code inherently, but developers still manage to mess this one up.
I think it's because when you learn how to program, you only learn the classical style, so you're not ready for the pitfalls of prototypal inheritance. So a lot of developers go through the "phase" of attempting to retro-fit their own ideas of how programming should work into a language that is designed in a totally different way, inevitably lead to problems, and have "the revelation" of understanding the prototypal inheritance idea. It's kind-of like a growing pain, which is why I'm really happy JS is being taught more heavily in schools and especially to entry-level programmers. Unlike Java, JavaScript is more accessible (just pop open the REPL in any browser) and its results are easier to observe. While it's not a great tool to teach people the concepts of OOP, I think it's very useful to teach kids at a young age that there isn't just one way to do things. They're different enough to screw developers up on a day-to-day basis, but not different enough that spending a few weeks with the language isn't enough to grasp its power.
As others have said, you really didn't waste your time there. If anything, it was simply a matter of JS developers collectively and simultaneously going through the same growing pains and eventual realizations about how the language works.
While it's not a great tool to teach people the concepts of OOP...
You could do much worse than JS as a teaching language. In fact, I'd say that it was only through practical application in JS that I fully appreciated the concepts extolled by Smalltalk, Self, and Lisp. Had I worked in a Java environment I may not have had those insights until much later.
Most programmers are good enough that with a good refactoring culture, they can evolve the equivalent of an in-house framework. Although, for some reason, I gather that programmers are scared of in-house "frameworks". I think that attitude is short-sighted since the app you build on top of the framework will end up being more complex than the framework itself.
I wouldn't dismiss using an established framework as "short-sighted". It's a tradeoff: the more complex and unique your problems are, the more it makes sense to roll your own.
Although I am a bit afraid that people overestimate the costs of rolling your own code, or "re-inventing the wheel". In most cases you aren't reinventing the wheel, because there are well documented bodies of reference for the design of almost any wheel you could need. Building (writing) a wheel (code) from scratch against a spec is much, much less complicated than inventing it.
Likewise: assembling your own set of design patterns and writing code from scratch is not "re-inventing", and is a lot easier than we give it credit for.
I don't have enough experience in different types of environments to say which approach is most suitable in most cases, but I'll definitely say that using an existing framework is the safer path (you have a community to lean back on), and is also advantageous for hiring. So I think you're correct when you say that many developers are afraid of rolling their own frameworks, but I think there are good reasons for that, especially for quickly-growing startups.
One hard lesson I learned is that you can't bet on a front end framework having the same mindshare for very long. The churn can get pretty crazy, and in my mind this nudges the needle a bit towards rolling your own for long term projects. Especially if you can offload the complex parts of the arch to the lower-churn backend world.
Of course, everyone thinks their problems are complex and unique.
You don't have to roll your own framework. You could always just use the micro-libraries that are ubiquitous in JS and pick an architecture that best fits your application. shrug to each their own. :)
shrug Personally, I don't see it that way. Frameworks are more generalized and reusable. They tend to be so large because they have to take into account a wider degree of problems. Applications with custom architectures and some external libraries are very specific and not typically reusable. Maybe it's just a matter of degrees.
So a framework has that "convention over configuration" flavor, while libraries are explicit. You actually have to load the application.hbs file manually with a handlebars parser. Then you use another library for the router, etc.
I can't imagine the spaghetti that would result from not using any framework (even a tiny handmade one) and just throwing a bunch of libraries together.
If a framework doesn't do something implicitly it's just a large library. If it's a set of conventions not backed by baked-in logic, it's a style guide.
A framework must CALL YOU. It usually gives you a piece of code that loads itself and lets you customize what it does by passing your code/configs to it. Then you tell it to run with what you gave it. The parts of the framework that you call yourself are actually "plug-ins" or basically framework-specific libraries.
If the framework never calls your code and you only call into the framework, that's always just a library. I would argue that actually it's easier to conflate a very full-featured library with a microframework because both really kind of call your code (especially when it's in the form of closures or a DSL).
You would never accidentally call a framework a library, though, because it's obvious that it's handling things for you. It's running everything behind the scenes and you just kind of advise it to do the things you want.
I really like this description. I've been trying to come up with a better description of what a framework is and isn't and I kept falling short. This one works well. Thanks! :)
It is interesting times for sure.