31–40 of 142 posts
How does this stack up versus something like riot.js? http://riotjs.com/
Earlier quoted context omitted.
Well for one 'class Foo extends Bar' will work without any further code to make inheritance work in the way you'd expect, including use of super() etc. Whereas your second example is using non-trivial framework code, that some framework author has to write. See Backbone's extend() for a clear example of what is required [0]. That's work that every framework author is potentially going to implement differently, needle…
The question is whether that ~15 lines of code, written once, is worth the substantial increase in the surface area of the language, especially when overlapping so much with the existing prototypal inheritance mechanism. The choice to use Java/C++-style inheritance is a design pattern that doesn't necessarily reflect the only (or even the best) way to accomplish things.
[deleted]
But for sites that are more like applications people are thinking about the components that make up those applications. These components are self contained and reused so it makes sense to have everything in the same small file.
We don't need smaller frameworks, we need more modular frameworks. If the framework is modular you can take what you need, and replace the parts you don't like. I'm using mercury [0] in my current frontend project for this purpose. Most of the features of React, none of the commitment. Every single component is interchangeable; the core repository is simply an index.js requiring other modules, which can be depended o…
Earlier quoted context omitted.
Well for one 'class Foo extends Bar' will work without any further code to make inheritance work in the way you'd expect, including use of super() etc. Whereas your second example is using non-trivial framework code, that some framework author has to write. See Backbone's extend() for a clear example of what is required [0]. That's work that every framework author is potentially going to implement differently, needle…
The question is whether that ~15 lines of code, written once, is worth the substantial increase in the surface area of the language, especially when overlapping so much with the existing prototypal inheritance mechanism. The choice to use Java/C++-style inheritance is a design pattern that doesn't necessarily reflect the only (or even the best) way to accomplish things.
function Foo() {
}
Foo.prototype = Object.create(Parent.prototype);
....
We don't need smaller frameworks, we need more modular frameworks. If the framework is modular you can take what you need, and replace the parts you don't like. I'm using mercury [0] in my current frontend project for this purpose. Most of the features of React, none of the commitment. Every single component is interchangeable; the core repository is simply an index.js requiring other modules, which can be depended o…
We don't need smaller frameworks, we need more modular frameworks. If the framework is modular you can take what you need, and replace the parts you don't like. I'm using mercury [0] in my current frontend project for this purpose. Most of the features of React, none of the commitment. Every single component is interchangeable; the core repository is simply an index.js requiring other modules, which can be depended o…
Mercury fans always say this but I'm never seen anyone swap out random libraries it uses, like dom-delegator. Stuff is still made to be used together, you could swap out dom-delegator if your version had the exact same API, but then what would be the point.
Decomposing your code into modules is step one. Making the interface between your modules generic enough to easily replace is the next problem, but if your code is a monolithic blob in the first place that's not going to be possible.
My main issue with modularity in JavaScript is the lack of strict typing, because you won't know if your interface fits correctly until runtime - which is why I've been looking into TypeScript and Elm recently.
Earlier quoted context omitted.
The question is whether that ~15 lines of code, written once, is worth the substantial increase in the surface area of the language, especially when overlapping so much with the existing prototypal inheritance mechanism. The choice to use Java/C++-style inheritance is a design pattern that doesn't necessarily reflect the only (or even the best) way to accomplish things.
ES6 classes do not use Java/C++ style inheritance, they are still the same as writing: function Foo() { } Foo.prototype = Object.create(Parent.prototype); .... It's just sugar, nothing more.
Yeah, there's already a company called Preact. =] preact.com