I began on writing my proposals down into the GoogleDoc, but found that this would lead to moving the discussion into GoogleDocs. So I am posting them here on discuss instead:
JavaScript (General / API):
Set up a proper Neos API which developers can access, I think of one window global which can be accessed via a getter method f.e. window.getNeosService() or window.getNeosAPI()
- The global should hold a constant Object which can’t be modified(Non-Emumerable?)
- The global should also include a PubSub/EventEmiter whom which you can fire events to the internals to Neos (Deleting/Creating Elements, hiding the inspector etc. etc.)
- These EventNames should also be in the global object
- I am thinking of an EVENT_NAMES object which the internal Neos code, as well as 3rd-Party Components from other developers can use.
- Benefits:
- Less repetition
- 3rd-Party Components are bound to the same variable/string without copy/pasting things like event names from the documentation/wiki.
- Another part of the global, should be to make all abstracted components from the Neos-Core accessible to 3rd-Party code.
JavaScript (General / Globals):
At this brief moment we have at least 10 globals from the Neos Code, two internals (window.T3 and window.Typo3Neos) as well as a bunch of third party globals.
These should be removed ASAP since this is a huge Problem if somebody is using the same window.global and is modifying it (Anti-Pattern, but it’s possible and we should take care of that).
JavaScript (DOM):
It seems like the neos code is accessing data from the DOM. The DOM is not an interactive Data-Exchange API and thus writing/reading data from the DOM should be avoided. It should be an overall goal to reduce the dependency to the DOM.
- When possible, data should be in Collections/Models/youNameIt™
- I found several Modules/JS Methods which sadly depend on fixed DOM classes/IDs
- This is a general anti-pattern: Things like selectors should, if even needed, be pushed in from the outside, we should think about Properties/States for Components
Comment from @christopher:
The whole concept of semantic annotations driving the editing interface relies on this. There are certainly drawbacks of using the DOM, but we at least never had problems with consistency using this approach (which could easily happen when we provide the data through AJAX or embedded in one part of the document). (Christopher)
@christopher I think we should revisit each of the usages. For me, the DOM shouldn’t be used as a data-handling API. I could be totally wrong on this one, but it just seems like there is room for improvement here. I am mostly sure we can find a solution which is more performant, and reduces the friction which can be caused if anyone is modifying the DOM attributes of an element and accidently breaks the Neos backend trough this. (The same goes for window globals stated above.)
JavaScript (General / ES6 and ES7):
We should hook Babel into our Build-Process to allow ES6 and ES7 code. This way our Code is more future-friendly. We can also switch to native APIs/Methods as soon as these are in all major browsers.
So in the long run: Better maintainable code, less 3rd Party and more native APIs/Methods.
JavaScript (Frameworks):
I would also like to revive the discussion of using a big framework. We should consider removing libraries/frameworks from the Core whenever we can. Instead we should use smaller modules (From the NPM Eco-System) which perfectly fit our requirements.
If we miss something, we should write our own modules and publish them to NPM as well.
Benefits:
- Reduced dependency on one big monolith
- Faster changesets/releases
- Decoupled code
- in the long run, this will pay out (Less big releases / changesets / rewrites, Modules can be switched since the API surface for each Module should be as low as possible).
- This should allow better attraction for more joining Frontend-Dev’s, since we aren’t bound to a single Framework, and instead are enforcing small an encapsulated modules.
Disadvantages:
- The learning curve is steep
- The refactoring process is more time consuming
Comment from @christopher:
We need to invent a lot of proven solutions (e.g. how to provide fast DOM updates / re-rendering / data binding) ourselves. When we would drop any existing framework we end up building our own. It needs a lot of continuously active people to support that amount of additional maintenance. (Christopher)
@christopher This is indeed not meant to replace existing logics, but more an enforcing of using smaller Modules, whom do one thing good, and not try to do 1000 things semi-great. There are a lot of existing DOM-Rendering Libraries, which solved the issues we all had. So we should use them of course! Ember also has a standalone version of their rendering logic (Will paste in the link ASAP).
JavaScript (Task-Runner):
Maybe we should switch from Grunt to Gulp. We could integrate a more modular/leaner build task, Gulp is known for being fast and I could provide a Gulp-Task-Application which creates standarized tasks on the fly from a passed in Config object. We should also consider switching to Node-Sass (Faster than RubySass and more or less on the same level regarding the language specification). This also comes in pair with Autoprefixer. It’s a tool that automatically writes the vendor prefixes we need, based on a standarized Browser-Array f.e.:
browserList: ['last 2 versions', 'ie9']