Comment by vladimir-y | Hacker News Reader

Comment by vladimir-y | Hacker News Reader

Parent Full thread

You can see on the 21-24 minutes the bad idea of implicit imports which is being presented as a great idea:

- 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.

There's really no magic with implicit imports. The imports are resolved at compile-time and fully resolved imports are used in the compiled code. I see developers making mistakes with explicit imports all the time (using the wrong path or forgetting to change the variable name or moving a component to a new directory and forgetting to update all relative paths).

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.

> use Webpack's aliases

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.

> You are contradicting yourself there. There is really no difference in clarity between an automatic path resolver and using aliases.

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.

> No difference?

If you are using aliases you are not using explicit imports.

    import something from 'something';

Where does 'something' come from? No idea unless you peek at the webpack configuration file.

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?

> If you are using aliases you are not using explicit imports.

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.

Reply on news.ycombinator.com