I don't know, I think this "use what's out there" mentality gets out of hand at times, and at least makes me kind of depressed. For sure, I think you should use whatever is available if the only reasons you want to roll your own tooling basically comes down to syntax or "but it feels nicer" kind of arguments – that's like reinventing screwdrivers because the handle of one gave you a blister that one time when you were using it wrong.
But if you have different ideas about how to structure things, come up with new abstractions that you find solve the problems at hand better than any of the abstractions available to you, then by all means do roll your own. We don't need more clones, but we do need fresh thinking and ideas that don't follow the pack. That's how we progress, by challenging the status quo.
Apologies for the incoherent rant, I hope the point gets across anyway.
> But if you have different ideas about how to structure things, come up with new abstractions that you find solve the problems at hand better than any of the abstractions available to you, then by all means do roll your own. We don't need more clones, but we do need fresh thinking and ideas that don't follow the pack.
My view on this is that generally if you haven't extensively used at least a couple of existing frameworks, it seems unlikely you'll do anything than re-invent existing stuff (at best) in a slightly different fashion. But otherwise I definitely agree the "use whats out there" gets way out of hand -- but for me this is mostly for relatively straight forward stuff.
My view on this is that generally if you haven't extensively used at least a couple of existing frameworks, it seems unlikely you'll do anything than re-invent existing stuff (at best) in a slightly different fashion.
If your background is mainly in modern JS development, that’s probably true. I don’t think it holds more widely, though. Modern JS lives a little bit in its own world, and the state of the art in that world is sometimes decades behind the wider programming industry.
With the interest in things like React and Flux there has been a lot of discussion in the JS community recently about unidirectional data flow. However, the same sort of separation of input interactions from output rendering goes back to at least the 1970s and 1980s when ideas like MVC were being developed.
Similarly, React and similar libraries get a lot of attention for the declarative way you can specify rendering and the relatively efficient way they update the DOM, but again we’ve had declarative UI libraries on the desktop for decades, and anyone who was doing graphics programming in the last millennium will be all too familiar with doing batched updates.
It’s not much of a stretch to think that someone with a background building UIs in some of these other contexts might have different ideas to the current JS community about the architecture they want for their UI code, nor that some of those different ideas might be better for some projects than the mainstream today.
I'm curious what peoples reaction would be to a framework/library that borrowed from Smalltalk's principles.
With the current lineup of frameworks, there's a lot of effort made to remove state from the system in order to make it understandable and performant (which is reminiscent of how people talked about Haskel a few years ago).
Yet with Smalltalk the entire language and tool base embraced the existence of state and gave you a lot of tooling to help make it manageable.
To me, the main problem with frameworks such as Backbone/Angular 1 is that state was bidirectional and that anyone could attach event listeners on anything so your webpage was a network of state flow with none of that being transactional, nor guaranteeing that the system would come into a consistent/valid state.
React is great with their unidirectional approach for rendering, but when a deeply embedded component makes a state change for itself it may logically have to effect the entire system. The current practice is to have top-down handling with Dispatchers/Stores (Flux), or pure reducers (Redux).
Another approach would be to compartmentalize each component so actions can automatically bubble upwards where they are handled by whomever in the VirtualDOM tree can take up the task. This would do away with global dispatch, and make it easier to mix and match components. I think this approach has merit.
I appreciate the angle and definitely agree. This is really what I think of in general -- when I imagine a new (e.g.) javascript ui framework, I"m hoping that the creator has experience not just in other JS frameworks, but many other UI frameworks. At my last job (for instance) the UI team was grouped together (rather then web ui into the web team), and I always loved comparing architecture for similar components with Windows, Android, etc., and especially the "embedded" guys.
But if you have different ideas about how to structure things, come up with new abstractions that you find solve the problems at hand better than any of the abstractions available to you, then by all means do roll your own. We don't need more clones, but we do need fresh thinking and ideas that don't follow the pack. That's how we progress, by challenging the status quo.
Apologies for the incoherent rant, I hope the point gets across anyway.