1 and 2 can leverage much of the existing interface code.
3 and 4 probably entail rewriting most of the interface from scratch. Leveraging existing code means a smoother upgrade from charred-black and a lot less work in the short term. But the existing interface is convoluted and difficult to manage for me and making changes to it takes more time and effort, and might not match the (new) model well.
1 means lacking features (including many making the code more modular and flexible), no fixes for bugs/security exploits, less documentation and community support. But we can use the interface entirely as is and has the most stability in the short-mid term
2 and 3 provide a suite of very useful tooling and lots of support and documentation. 2 even comes with an incremental migration strategy. But we remain dependent on frameworks, with all their bloat, dependencies, complexities and more.
4 requires the most extensive rewrite, but most direct control (and mapping to whatever my mental model ends up being) and cleanest start. Recreating the charred UI style would take effort. But the biggest problem of all lies in model binding.
Charred at its core is a model binding tool. The vast majority of its logic is just that. Model binding involves at least a robust event publish/subscribe mechanism, DOM maniuplation, and general state management. The complexity increases much faster than model complexity and the charred model is fairly large and complex.
Frameworks exist to solve that problem and leave the user code focused on semantics.
They also provide a lot of ready to use interface components and behaviours. While I somewhat relish the challenge of writing that from scratch, it would likely be more brittle and error-prone.
Thoughts?
[AngularJS is dead dead.](https://blog.angular.io/discontinued-long-term-support-for-angularjs-cc066b82e65a)
A few options I can see:
1. Continue to use AngularJS (and a version older than the last one at that)
2. Upgrade to [Angular](https://angular.io/)
3. Pick a new framework
4. Don't use a framework at all
1 and 2 can leverage much of the existing interface code.
3 and 4 probably entail rewriting most of the interface from scratch. Leveraging existing code means a smoother upgrade from charred-black and a lot less work in the short term. But the existing interface is convoluted and difficult to manage for me and making changes to it takes more time and effort, and might not match the (new) model well.
1 means lacking features (including many making the code more modular and flexible), no fixes for bugs/security exploits, less documentation and community support. But we can use the interface entirely as is and has the most stability in the short-mid term
2 and 3 provide a suite of very useful tooling and lots of support and documentation. 2 even comes with [an incremental migration strategy](https://angular.io/guide/upgrade). But we remain dependent on frameworks, with all their bloat, dependencies, complexities and more.
4 requires the most extensive rewrite, but most direct control (and mapping to whatever my mental model ends up being) and cleanest start. Recreating the charred UI style would take effort. But the biggest problem of all lies in model binding.
Charred at its core is a model binding tool. The vast majority of its logic is just that. Model binding involves at least a robust event publish/subscribe mechanism, DOM maniuplation, and general state management. The complexity increases much faster than model complexity and the charred model is fairly large and complex.
Frameworks exist to solve that problem and leave the user code focused on semantics.
They also provide a lot of ready to use interface components and behaviours. While I somewhat relish the challenge of writing that from scratch, it would likely be more brittle and error-prone.
Thoughts?
Will apply changes to existing interface while that remains feasible. If and when that is no longer the case, will probably use something lightweight like rivets for an interface rewrite.
Will apply changes to existing interface while that remains feasible. If and when that is no longer the case, will probably use something lightweight like [rivets](http://rivetsjs.com/) for an interface rewrite.
AngularJS is dead dead.
A few options I can see:
1 and 2 can leverage much of the existing interface code.
3 and 4 probably entail rewriting most of the interface from scratch. Leveraging existing code means a smoother upgrade from charred-black and a lot less work in the short term. But the existing interface is convoluted and difficult to manage for me and making changes to it takes more time and effort, and might not match the (new) model well.
1 means lacking features (including many making the code more modular and flexible), no fixes for bugs/security exploits, less documentation and community support. But we can use the interface entirely as is and has the most stability in the short-mid term
2 and 3 provide a suite of very useful tooling and lots of support and documentation. 2 even comes with an incremental migration strategy. But we remain dependent on frameworks, with all their bloat, dependencies, complexities and more.
4 requires the most extensive rewrite, but most direct control (and mapping to whatever my mental model ends up being) and cleanest start. Recreating the charred UI style would take effort. But the biggest problem of all lies in model binding.
Charred at its core is a model binding tool. The vast majority of its logic is just that. Model binding involves at least a robust event publish/subscribe mechanism, DOM maniuplation, and general state management. The complexity increases much faster than model complexity and the charred model is fairly large and complex.
Frameworks exist to solve that problem and leave the user code focused on semantics.
They also provide a lot of ready to use interface components and behaviours. While I somewhat relish the challenge of writing that from scratch, it would likely be more brittle and error-prone.
Thoughts?
@silverwizard
I uh, do not like Frameworks, but have no
Will apply changes to existing interface while that remains feasible. If and when that is no longer the case, will probably use something lightweight like rivets for an interface rewrite.