Recently I discussed with colleagues why Ruby on Rails succeeded where no Python framework did. One hypothesis put forward was that there was 1 popular Ruby framework (Rails), but many popular Python frameworks.
I wonder if it will be the same for JavaScript front-end frameworks, with no one gaining the greatest mindshare.
Not necessarily make any claims about what's preferable (one framework to rule them all vs many competing options) - though I'm certainly curious about that as well for the front-end frameworks.
tl;dr - Python had no web frameworks built in or community favorite. Rails was a complete re-think of how to do web apps in the age of XML (acaffolding, convention over config, etc.) Every language since has now realized this and copied Rails. This is a good thing.
if you want a story while drinking coffee, read below...
I was a serious Python guy from 1996 til 2006. I still like and respect Python. Before Python, I was a wanna-be Smalltalk fan. (This is important towards the end)
Python always had a philosophy of 'batteries included'. This means that it will have libraries for just about everything you need as supported parts of the language. Contrast this with Perl where CPAN quality was very hit or miss. Then contrast this with Lua or Scheme. They had too many libraries and none were standard. Most of those were, again, not supported or not of production quality.
As a result of 'batteries included', Python was just a dream to work with. Everything was doable or easy and performant 'enough'. I could go on, but that still wouldn't do it justice. They had a great language design, great libraries, and portability. Python is still a great framework. They didn't have a good 'CPAN'. This was ok, since the built-ins were good. Outside of that, it was a bit of a mess.
However, over the years, it became obvious that Python had a huge flaw. They did not deal with HTTP or HTML well. People don't even talk about this anymore, but the promoted framework was 'Plone'. This framework was so complex and convoluted, that building a simple web app was just not possible. It is not spoken about anymore. New frameworks popped up as a result, and very few of those were much good. This was a huge problem. Most people had to build their own production system. I had to switch languages for a job in 2002, and I didn't deeply follow the web framework discussion in Python for quite some time. I can tell you this, though. There wasn't a single framework that popped up as the winner or as exciting.
I'm typically a conservative. When I see a new thing, my typical take away is "this has been done before, what did they not learn from prior art". For example, lets say someone creates a new OS. If they don't really understand Unix, they will get it wrong.
When the first Rails screen-cast came out, I took a look. There was a lot of buzz that was increasing. I go, 'what the heck, it is only 5 minutes and it is a video.'
What I saw was an excellent architecture for building web apps. This architecture was better than anything else out there by quite a wide margin. They supported modern HTML. Convention over configuration. ActiveRecord was truly a treasure. The default site actually looked relatively decent (vs. the typical programmer, zero whitespace, huge serif, Netscape circa 1998 site). They URL conventions looked good. This architecture was human friendly. These people understood what a modern app should look like.
I was sold. Just from that screencast.
I believe in using whatever language is needed, if the framework is excellent. I wanted to build excellent web apps, so I learned Ruby. Ruby was easy to learn, and it is as good as Python. Much to my surprise it was the first language to pull off having Smalltalk blocks! People didn't even notice this and now they really like it. Everytime I showed this to coworkers, they would go 'what is that? I don't understand'. When people eventually learn Rails, they would go.. "check out these block things. They
So, in summary, Python didn't have a web framework. Rails was an excellent design, compared to any languages framework. Rails is pretty much going to be here for quite some time.
BTW, at this point. Rails is not my first choice. I think it is too heavy and web architecture has shifted a lot. Still, it would be in my top 3 choices.
I, like most, hadn't even heard of Ruby before Rails. The two were synonymous - I remember having to explain to a number of people that should have know better that Ruby was a language and Rails was a framework.
I don't really know the history of Django but I'd wager it took a lot of inspiration from Rails.
Rails had that year's head-start on Django. By the time Django came along everyone was pretty deep into the development of Rails. I think it's mostly down to first mover advantage (it really did revolutionise web development).
In terms of frontend frameworks I have no idea what's going to happen.
Backbone definitely had the initial traction and it's nice and clean, but damn AngularJS makes development quick and easy. I've implemented things in the last couple of days in Angular that would have taken a week or more previously.
The Angular approach is unorthodox and seemingly inefficient but serves the developer well at the cost of CPU cycles.
Then again, I backed Prototype during the initial js lib battles and we know how that worked out.
First Django succeeded. i.e. Instagram and Pinterest. Second you guys have Sinatra. Quite often when I inspect a webpage of a notable site, I find Backbone in the mix. Agree or Disagree?
Or, Rails was well-marketed, had lots of 3rd party plugin components, and actually had database migrations (oh the pain of databases and models in early Django)
Javascript front-end framework are really new (3 years old) compare to web frameworks. The need is also quite different. There was a need for a Javascript framework and we can say that jQuery won the battle. We will have to wait few more years to see most of the web app running with a Javascript front-end framework, then you will maybe have a winner!
This looks like Twitter's version of Web Components?
You might have heard of it shadow DOM etc. Basically the idea is to be able to add GUI components eg <progressbar> that are as integrated as the native ones are.
Mozilla's X-Tags implementation seems closer to the goal though: http://www.x-tags.org/ IIRC it can do this because it's using Object.observable internally to detect DOM changes.
ie with X-tags you don't need the javascript definition part, just: <x-map data-key="39d2b66f0d5d49dbb52a5b7ad87aea9b"></x-map>.
Web Components is the storm that will wipe away all these frameworks: Backbone, Ember, Angular, Knockout, etc.
Unfortunately, we’ll have to stick around with them for the following couple of years, probably, as for now, most of the Web Components APIs are available only in Chrome Canary and Firefox dev builds. Monkey-patching (AKA “shimming”) to the rescue…
In my opinion, the more certain nowadays libs resemble the Web Components specs, the more clear the developers’ choice towards those libs should be.
I've played around with most of the JavaScript MV(whatever)'s and I'm just not sure about this.
"Flight is organized around the existing DOM model with functionality mapped directly to DOM nodes"
It seems the point of using backbone or which ever other framework (I'm partial to Angular so far), is to decouple from the DOM, so that if and when your markup changes, your JavaScript doesn't. This doesn't seem any better than well written jQuery.
It looks like the concerns are different between Backbone and Flight.
Flight is for building UI components, not client views. I think it might be akin to jquery widget plugins, but with more structure to make it easier and potentially more extensible (eg the mixins).
So yeah, in this case I think they were right to ride on DOM events.
agreed. the problem with these AMD frameworks is that the asynchronous nature and deeply nested callbacks are almost completely unnecessary because you end up concatenating/minifying the assets before production anyways. You end up with unreadable files. With synchronous CommonJS frameworks, most of this nesting is eliminated.
What I think is interesting to see, is that the patterns from Nicholas zakas' "scalable Javascript architecture" spreads into new frameworks.
Enforcing components w/o return values, communicating via pub/sub is also seen in aura.js and backbone marionette. I think this thinking will lead to more stable, easy to change js apps. Exciting!
This is a really great concept, that enables client applications on a different scale (and reduces their complexity very much). Thanks Twitter team!
A big advantage over web components (or angular, or others) is that this is much more lightweight, less polluted and has a better separation of concerns. (On the other hand, web components will be a great deal for browser-app shops developing for third parties).
Seeing as how Bootstrap fails at even the most elementary of tasks (using absolute instead of relative values for positioning, for example, screws everything up when the user's zoom is anything other than 100%, among many, many, many other flaws), anybody who uses this framework is a competitor I am... not worried about.
>When you create a component you don't get a handle to it. Consequently, components cannot be referenced by other components and cannot become properties of the global object tree. This is by design. Components do not engage each other directly; instead, they broadcast their actions as events which are subscribed to by other components.
This is a maintainability nightmare. I've gone down this route on hand rolled JS frameworks before and it leads to untold headaches. Sometimes a little coupling is the right solution. Many times it is better for components to have knowledge of their environment. In most applications (other than iGoogle maybe) one thing on a page depends on another. I feel it's far better to explicitly call out those dependencies by having a reference to the other components and directly invoking methods on them with known arguments of a known type.
Edit: Also, what kind of memory allocation implications are there with event subscriptions and no references to the components themselves?
I understand where you're going here:
pubsub communication can be both a blessing and a curse,
it can be hard to ensure a consistent usage, hard to debug when there's long chains than one place -> the other.
I think the sandboxing from aura.js is pretty interesting here, since you can always look up which widgets are allowed to talk, it makes it easier to narrow down the problem.
The real nightmare comes from the undiscoverability. The right tools can help you out. Unobtrusive JavaScript used to be a nightmare, for example, until Chrome added its 'Event Listeners' tab in the developer tools. Another being the 'Go To Implementation' instead of 'Go To Definition' when writing C# with code that uses interfaces.
Yes, you need coupling when debugging. But it need not be in the libraries and code you use.
Er...why is this broadcast model a maintainability nightmare compared to coupling components to their environment and to other components? I guess maybe it's too much abstraction for a website in which you know most components won't be reused...but then you wouldn't be Flight's intended audience.
How can anyone build a serious front-end without proper keyboard support? Every single one of these new-fangled web UI kits is missing this important feature and if you're going to do it at all, it really does need to be a core consideration.
This is my biggest complaint about most web apps and the number one reason that I think web apps are perceived to be less powerful. Give me a break web devs! (Or, should I say browser makers?) Let's get serious already!!
(Also if we're talking browser manufacturers, I'd really, really like to see a completely separate abstraction for apps than documents. C'mon man!! We've been inventing the same thing for 20 years, let's get it right for once :)
Because it will "just fit" with corresponding Bootstrap assets, I'm assuming... I don't know if it does that now, but I'm assuming both frameworks will eventually share the same conventions and opinions so that developers can use them in tandem without too many extra ateps
[+] [-] dmragone|13 years ago|reply
I wonder if it will be the same for JavaScript front-end frameworks, with no one gaining the greatest mindshare.
Not necessarily make any claims about what's preferable (one framework to rule them all vs many competing options) - though I'm certainly curious about that as well for the front-end frameworks.
[+] [-] drudru11|13 years ago|reply
tl;dr - Python had no web frameworks built in or community favorite. Rails was a complete re-think of how to do web apps in the age of XML (acaffolding, convention over config, etc.) Every language since has now realized this and copied Rails. This is a good thing.
if you want a story while drinking coffee, read below...
I was a serious Python guy from 1996 til 2006. I still like and respect Python. Before Python, I was a wanna-be Smalltalk fan. (This is important towards the end)
Python always had a philosophy of 'batteries included'. This means that it will have libraries for just about everything you need as supported parts of the language. Contrast this with Perl where CPAN quality was very hit or miss. Then contrast this with Lua or Scheme. They had too many libraries and none were standard. Most of those were, again, not supported or not of production quality.
As a result of 'batteries included', Python was just a dream to work with. Everything was doable or easy and performant 'enough'. I could go on, but that still wouldn't do it justice. They had a great language design, great libraries, and portability. Python is still a great framework. They didn't have a good 'CPAN'. This was ok, since the built-ins were good. Outside of that, it was a bit of a mess.
However, over the years, it became obvious that Python had a huge flaw. They did not deal with HTTP or HTML well. People don't even talk about this anymore, but the promoted framework was 'Plone'. This framework was so complex and convoluted, that building a simple web app was just not possible. It is not spoken about anymore. New frameworks popped up as a result, and very few of those were much good. This was a huge problem. Most people had to build their own production system. I had to switch languages for a job in 2002, and I didn't deeply follow the web framework discussion in Python for quite some time. I can tell you this, though. There wasn't a single framework that popped up as the winner or as exciting.
I'm typically a conservative. When I see a new thing, my typical take away is "this has been done before, what did they not learn from prior art". For example, lets say someone creates a new OS. If they don't really understand Unix, they will get it wrong.
When the first Rails screen-cast came out, I took a look. There was a lot of buzz that was increasing. I go, 'what the heck, it is only 5 minutes and it is a video.'
What I saw was an excellent architecture for building web apps. This architecture was better than anything else out there by quite a wide margin. They supported modern HTML. Convention over configuration. ActiveRecord was truly a treasure. The default site actually looked relatively decent (vs. the typical programmer, zero whitespace, huge serif, Netscape circa 1998 site). They URL conventions looked good. This architecture was human friendly. These people understood what a modern app should look like.
I was sold. Just from that screencast.
I believe in using whatever language is needed, if the framework is excellent. I wanted to build excellent web apps, so I learned Ruby. Ruby was easy to learn, and it is as good as Python. Much to my surprise it was the first language to pull off having Smalltalk blocks! People didn't even notice this and now they really like it. Everytime I showed this to coworkers, they would go 'what is that? I don't understand'. When people eventually learn Rails, they would go.. "check out these block things. They
So, in summary, Python didn't have a web framework. Rails was an excellent design, compared to any languages framework. Rails is pretty much going to be here for quite some time.
BTW, at this point. Rails is not my first choice. I think it is too heavy and web architecture has shifted a lot. Still, it would be in my top 3 choices.
[+] [-] d23|13 years ago|reply
[+] [-] lucian1900|13 years ago|reply
[+] [-] aidos|13 years ago|reply
I don't really know the history of Django but I'd wager it took a lot of inspiration from Rails.
Rails had that year's head-start on Django. By the time Django came along everyone was pretty deep into the development of Rails. I think it's mostly down to first mover advantage (it really did revolutionise web development).
In terms of frontend frameworks I have no idea what's going to happen.
Backbone definitely had the initial traction and it's nice and clean, but damn AngularJS makes development quick and easy. I've implemented things in the last couple of days in Angular that would have taken a week or more previously.
The Angular approach is unorthodox and seemingly inefficient but serves the developer well at the cost of CPU cycles.
Then again, I backed Prototype during the initial js lib battles and we know how that worked out.
[+] [-] mrharrison|13 years ago|reply
[+] [-] thedaniel|13 years ago|reply
[+] [-] vincentperes|13 years ago|reply
[+] [-] yesimahuman|13 years ago|reply
[+] [-] glymor|13 years ago|reply
You might have heard of it shadow DOM etc. Basically the idea is to be able to add GUI components eg <progressbar> that are as integrated as the native ones are.
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/... https://plus.google.com/103330502635338602217/posts
Mozilla's X-Tags implementation seems closer to the goal though: http://www.x-tags.org/ IIRC it can do this because it's using Object.observable internally to detect DOM changes.
ie with X-tags you don't need the javascript definition part, just: <x-map data-key="39d2b66f0d5d49dbb52a5b7ad87aea9b"></x-map>.
[+] [-] cristiantincu|13 years ago|reply
Unfortunately, we’ll have to stick around with them for the following couple of years, probably, as for now, most of the Web Components APIs are available only in Chrome Canary and Firefox dev builds. Monkey-patching (AKA “shimming”) to the rescue…
In my opinion, the more certain nowadays libs resemble the Web Components specs, the more clear the developers’ choice towards those libs should be.
[+] [-] scottrblock|13 years ago|reply
"Flight is organized around the existing DOM model with functionality mapped directly to DOM nodes"
It seems the point of using backbone or which ever other framework (I'm partial to Angular so far), is to decouple from the DOM, so that if and when your markup changes, your JavaScript doesn't. This doesn't seem any better than well written jQuery.
Am I missing something?
[+] [-] pfraze|13 years ago|reply
Flight is for building UI components, not client views. I think it might be akin to jquery widget plugins, but with more structure to make it easier and potentially more extensible (eg the mixins).
So yeah, in this case I think they were right to ride on DOM events.
[+] [-] vicapow|13 years ago|reply
http://github.com/component/component
[+] [-] jongleberry|13 years ago|reply
[+] [-] karl_nerd|13 years ago|reply
Enforcing components w/o return values, communicating via pub/sub is also seen in aura.js and backbone marionette. I think this thinking will lead to more stable, easy to change js apps. Exciting!
[+] [-] agilord|13 years ago|reply
A big advantage over web components (or angular, or others) is that this is much more lightweight, less polluted and has a better separation of concerns. (On the other hand, web components will be a great deal for browser-app shops developing for third parties).
[+] [-] weareconvo|13 years ago|reply
[+] [-] Kiro|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] benregenspan|13 years ago|reply
[+] [-] gummydude|13 years ago|reply
[+] [-] dos1|13 years ago|reply
This is a maintainability nightmare. I've gone down this route on hand rolled JS frameworks before and it leads to untold headaches. Sometimes a little coupling is the right solution. Many times it is better for components to have knowledge of their environment. In most applications (other than iGoogle maybe) one thing on a page depends on another. I feel it's far better to explicitly call out those dependencies by having a reference to the other components and directly invoking methods on them with known arguments of a known type.
Edit: Also, what kind of memory allocation implications are there with event subscriptions and no references to the components themselves?
[+] [-] karl_nerd|13 years ago|reply
I think the sandboxing from aura.js is pretty interesting here, since you can always look up which widgets are allowed to talk, it makes it easier to narrow down the problem.
[+] [-] joeyespo|13 years ago|reply
Yes, you need coupling when debugging. But it need not be in the libraries and code you use.
[+] [-] danso|13 years ago|reply
[+] [-] WayneDB|13 years ago|reply
This is my biggest complaint about most web apps and the number one reason that I think web apps are perceived to be less powerful. Give me a break web devs! (Or, should I say browser makers?) Let's get serious already!!
(Also if we're talking browser manufacturers, I'd really, really like to see a completely separate abstraction for apps than documents. C'mon man!! We've been inventing the same thing for 20 years, let's get it right for once :)
[+] [-] bvcqw|13 years ago|reply
[+] [-] jlogsdon|13 years ago|reply
[+] [-] hueyp|13 years ago|reply
I love Angular, but if you are rendering server side HTML (either as partials, or bootstrapping a page) it is currently lacking.
[+] [-] ww520|13 years ago|reply
[+] [-] bwilliams|13 years ago|reply
[+] [-] zachrose|13 years ago|reply
[+] [-] danso|13 years ago|reply
[+] [-] taligent|13 years ago|reply