Here's a great introduction to Marko by its main dev:
- Explicit import is a much better idea than the Marko's folder structure based implicit import thing. Explicit import makes the code base more maintainable, reduces the side effects probability and "magic" stuff.
- "Counter" there is not a "word" as author says, but the component's file name. So it's not the word that you can misspell, but the file/module, that will not be imported in case of file name misspelling. Import by file name is not repeating, it's the explicit module importing by the file name, not by a some word - no DRY ideas violation here.
- Author says on 21:51 that "imports is kind of terrible" due to the relative path. There is no issue with the relative path - use Webpack's aliases. He says imports (explicit relative imports in that case) makes code more fragile...
- I like Vue's idea of separation computed/methods/data blocks more than mixing all together. It for example helps the green devs to better understand the framework's lifecycle/internals and separation of concern ideas.
I stopped watching the video after the 24 minute.
You are contradicting yourself there. There is really no difference in clarity between an automatic path resolver and using aliases.
> I like Vue's idea of separation computed/methods/data blocks more than mixing all together
It's really a matter of taste.
No difference? In case of explicit importing you get the "import" thing in the sources code and it's a huge difference in comparison of not having it there.
> It's really a matter of taste.
Not really, but a matter of separation of concern and good design. Besides Vue is a reactive thing, and such structure I guess makes it easy to apply reactivity observers where they are needed in a more explicit way.
If you are using aliases you are not using explicit imports.
import something from 'something';
You don't even know if the module is actually called 'something'.
> Not really, but a matter of separation of concern and good design.
Then I'm guessing you consider all OOP languages badly designed since none of them have properties for 'methods', 'getters' (computed), etc. Yes?
You are as you have the "import" code line in the code sources. If you get rid of that code line, you make it happen implicitly and this is the case of undesirable "magic" happening.
> No idea unless you peek at the webpack configuration file.
Some IDEs do support automatic Webpack's aliases resolving, so you can navigate to the module by ctrl+click.
> Then I'm guessing you consider all OOP languages badly designed since none of them have properties for 'methods', 'getters' (computed), etc. Yes?
Don't be silly, we are talking about JS that has a room for adding some structure as it's being too flexible by default.
Anyway thanks for the Youtube link, it helped me to realize that I'm not going to use this Marko thing.
Webpack aliases are a Webpack-only feature that I would consider a bad practice since it relies on globally configured aliases. Implicit imports in Marko are resolved relative to the template file (not global). Marko can be used server-side under Node.js with no need for a JavaScript bundler.
> I like Vue's idea of separation computed/methods/data blocks more than mixing all together. It for example helps the green devs to better understand the framework's lifecycle/internals and separation of concern ideas.
I see separation of computed/methods/data as unnecessary boilerplate. Methods are just functions on the component definition. On a related note, In Marko there's no need for "computed" properties and there is no need for a "data" block.