ES6 Modules & Webpack: To improve the Webpack and ES6 lessons, more specifically to add more consolidated information in the lesson content since these are crucial lessons; also to improve the sequence of information in said lessons.

[Advaitmenon1106]

Checks

• This is not a duplicate of an existing issue (please have a look through our open issues list to make sure)
• I have thoroughly read and understand The Odin Project Contributing Guide
• Would you like to work on this issue?

Describe your suggestion

Key concerns covered in this issue (a TLDR)

• Additional points of information need to be added to the Webpacks and ES6 lessons by the means of a revision in order to consolidate information in one single place.
• The sequence of said additional information, and the existing information, possibly needs to be revised in order for it to make more logical sense.
• Potentially: This can be done in a more organised manner if the sole reliance of the curriculum content on the Webpack documentation/disjoint articles on bundlers and webpacks is reduced- in other words, if the course stitches up the various sources of information on Webpacks to form its own lesson content on the same.

Elaboration of the issue

• Currently, the Webpack lessons are an amalgamation of several bits of information, with the following flow:-

-> npm information

-> webpacks (the webpack doc tutorial is here and asks us to create a bundle using just index.js)

-> es6 import and export (Odin introduces import-export here and using multiple JS files)

-> webpacks continues (talks about bundling functionality, etc using separate js files)

-> Move to webpack lesson for loaders etc

Part of the flow	Source of information
NPM	Lesson + "History of Javascript"
Why Bundlers	Odin + https://snipcart.com/blog/javascript-module-bundler
Webpack tutorial using 1 JS file	https://webpack.js.org/guides/getting-started/
About Src and Dist	Odin
ES6: import-export	Odin
Loaders	Webpack (next lesson) (Adds a reference to the Webpack documentation once again)

• The webpack documentation is process-oriented however, the rationale behind using a webpack project is lost in the process, and is only covered in the next section in the same Odin lesson (note another break in continuity, here).
• This problem can be fixed using a better thought-out sequence of information in the lesson.
• More information related to the so-called "dependency graph" built by Webpack can also be added using visual means and examples, in order to give a high-level overview of how Webpack works.
• Lastly, in the webpack lessons, the rationale behind not modifying the distribution folder and keeping the changes in the src folder should be elaborated slightly better to give learners an idea of why they should take the efforts of installing the HTML-Webpack-Plugin, rather than simply making it a part of the process algorithmically.

Path

Node / JS

Lesson Url

https://www.theodinproject.com/lessons/node-path-javascript-es6-modules

(Optional) Discord Name

Advait (A_v_it)

(Optional) Additional Comments

No response

[rlmoser99]

Thank you for taking the time to make an issue. Can someone from the @TheOdinProject/javascript team, please review this issue, as well as a closely related one:
#26977

[wise-king-sullyman]

@Advaitmenon1106 thanks for making this! I agree that there is some room for improvement here.

I might be just misunderstanding you a bit but can you expand a bit on your proposed solution? One specific question I have is are you suggesting just reworking the lesson or potentially splitting the content into different lessons?

[Advaitmenon1106]

@wise-king-sullyman Hello!

My suggestion, and the way I envision the new flow of information, might potentially require both:-

• [Reworking] So, from where I stand at the moment, I see the best way out of all possible confusion by reworking the lessons and making a self-contained lecture, just for webpacks (since the lessons are fundamentally important, but also confusing when you consider that the Webpack documentation only works on the technicalities, leaving out some of the rationale behind using it as a tool).

(Self-contained implies that we might need to consolidate necessary information into Odin's lesson(s) on webpacks and then direct them to the documentation for the technical stuff like setting it up, etc).

• [Splitting] Moreover, I feel like the flow of the lesson can be better improved by first introducing the import-export statements as a part of the ES6 modules, and maybe as a bonus, also cover the issues behind importing and exporting it without a bundler, using a basic code demonstration, perhaps.

And then the concept of a bundler, and Webpack, can be introduced as a part of the following lesson(s), which essentially conforms with Odin's way of building the learning curve for both the concept of modularity using separate files (which is used for the very first time by learners in that series of lectures), and Webpack as an improvement to manually using import-export statements.

But again, I might stand corrected and there might be a more efficient solution to this that I am overlooking.

Edit, and an addendum (and this was a topic of discussion on discord as well; kindly refer to https://discord.com/channels/505093832157691914/707225752608964628/1187791676224327790 for the beginning of the whole conversation on the ES6 and Webpack lessons) : Maybe explain the basic gist of a dependency graph, in the process, to make it easy to understand how Webpack works, in a visual form?

[wise-king-sullyman]

Sorry I'm still not sure I'm quite understanding your proposal.

Is the core of it removing all webpack/bundling content from the ES6 modules lesson, then reworking the webpack lesson to house that content and expand more on the why behind things?

[Advaitmenon1106]

@wise-king-sullyman Yes

[MaoShizhong]

I personally agree with the ideas behind this. I've always found it a little odd how in the ESM lesson, ESM isn't introduced until the very end and more of the lesson is spent on package managers and introducing bundlers. Even then, it also feels a little strange introducing Webpack before the Webpack lesson.

It makes sense to me from a flow-perspective that ESM is introduced first, which might also make it easier to briefly mention the differences between ESM and CJS (since later when it comes to Node stuff e.g. comp sci section), people unaware of ESM/CJS within Node can encounter some very confusing (even if simple) issues should they decide to start using ESM.
Then perhaps after ESM is introduced in isolation, the webpack lesson(s) can introduce bundlers and webpack itself with in-house stuff separately. To me that makes a little more sense in terms of the order of topics, but also might help the learner focus on each topic separately, as I don't think you necessarily need to be aware of bundling to understand how ESM works (and the benefits of modules e.g. answering things like situations where IIFEs used to be necessary for scope but how ESM might solve those scenarios). Afterwards, they can then learn about combining multiple modules into fewer/one for production.

[wise-king-sullyman]

@Advaitmenon1106 Alright then yeah I'm on board with your proposal!

@MaoShizhong I agree with your comments as well.

One thing I wonder about is if it would make sense to split the webpack stuff into two lessons, maybe flanking the restaurant page project, where the first hits the more basic aspects needed to do restaurant page and the second dives into more advanced things like how dependency graphs work, source maps, the content from assignment 5 of the webpack lesson, and the content discussed in #26977. Not that all of that needs to be done as part of this issue. I'd love to hear your alls thoughts on that.

Also, since there's a lot of overlap between this issue and some of the things proposed by @MaoShizhong I think there will need to be some coordination here. If you all want I can handle that, propose an order of operations for everything and try to divvy up the work (there's quite a bit here), or if you'd prefer to just sort things out between yourselves I'm fine with that as well, just let me know.

[MaoShizhong]

I quite like the idea of revisiting webpack with a little more detail straight after Restaurant Page but if that's to be done, we'd definitely need to discuss exactly what goes before and after.

I'm personally not too fussed with exactly which way we proceed. Since @Advaitmenon1106 was the one who first raised this, I'm very much happy for them to take the lead how they wish. I definitely have ideas and can advise alongside.

One of the biggest things IMHO is the need for more in-house teaching on the subject. Frankly, many of the external resources/tutorials inc. the webpack website's tutorials are not very helpful given the context of this part of the curriculum and what it's trying to teach.
Many of those resources either are aimed at people who know about bundlers and their features, and just need to know how Webpack does things, or will have one or two things in them that are not relevant to this part of the curriculum. Stuff like multiple entry points, code splitting and runtime chunks, serving files from dist/ and developing within dist (strikes me as so incredibly strange how a lot of tutorials/docs demonstrate this).

This has led to many problems from learners setting unnecessary (and often problematic) config options or structuring their projects in a counterproductive way simply because the resources showed that at some point but hardly explained it outside of an easily missable/poorly worded side note, that'd only make more immediate sense if you already knew about how that concept works). Stuff like the output management tutorial using multiple entry points, or the webpack dev server tutorial randomly deciding it needs to do that too and thus also include runtime chunk optimisation (which can sometimes cause issues when no code splitting is used) with only a small side note box underneath saying that config was only included due to code splitting multiple bundles on a single html page.

[Advaitmenon1106]

I agree with what @MaoShizhong said. In-House content might be needed for a topic as crucial as this.

@wise-king-sullyman You read my mind! The idea of flanking the restaurant page project is what I had in my vision as well.

If you give us the go-ahead, I would like to start this initiative by chalking out a new game-plan for Webpacks using the entire discussion and share it on the Discord channel (with the inputs of whoever is interested in contributing their ideas), and then run it by you all, so that we are all onboard with the flow. I might need some time for this because I wish to be thorough in addressing all of the concerns that have been raised on the help channels on Discord as well (the webpack related doubts and ES6 related doubts).

Does this sound okay?

[MaoShizhong]

I like the sound of that! Feel free to throw any questions/brainstorm my way but happy to work with your vision of this :)

[wise-king-sullyman]

I agree with @MaoShizhong as well, thanks for laying out those thoughts Mao!

@Advaitmenon1106 go for it 🚀

[github-actions]

This issue is stale because it has had no activity for the last 30 days.

[wise-king-sullyman]

@Advaitmenon1106 is this still something you are/would like to work on?

No rush if so, just touching base.

[Advaitmenon1106]

@wise-king-sullyman Sorry about the delays, I got sidetracked by uni related stuff

Yes, I'm still interested in working on it. The G-docs file link is in a thread on discord, which I'll continue to edit. Mao has also given their suggestions on the same. Docs + thread: https://discord.com/channels/505093832157691914/707225752608964628/1203902952826208296

I also have a small codebase for demonstrating why ES6 is required, which I'll send in sometime. All of your feedback will be greatly appreciated on the materials.

[wise-king-sullyman]

Absolutely no worries or rush, we're all volunteers here 🙂

[github-actions]

This issue is stale because it has had no activity for the last 30 days.

[wise-king-sullyman]

@Advaitmenon1106 still no rush, just trying to confirm once more if this is still something you're interested in doing.

[Advaitmenon1106]

@wise-king-sullyman You have a point, I've been rather inactive in doing it because of my university's hectic schedule.

I have some things ready, however, I'd like it if someone else prefers to take the lead, since my time constraints are only delaying things unnecessarily

[Advaitmenon1106]

Having said that, I'd prefer to play an active role in helping out behind the scenes, but I'd like the lead to be given to someone more knowledgible than I am, since Mao raised some points which made me doubt my existing knowledge about webpacks/JS in general lol, so I'll get to learn better under someone more learned than I am @wise-king-sullyman

Again, I sincerely apologise for this delay.

[MaoShizhong]

That's perfectly fine @Advaitmenon1106 - there really is no rush, particularly given the scale of the work to be done. And especially because of that scale, it's fine to find it real difficult/realise your original approach may not work out the way you thought. Your uni studies and other IRL things 100% take priority here.

I would be perfectly happy to take a leading role for this, and actively involve you in the process to refine it all as a co-author. I had done a bit of work on this section previously, and also had my own thoughts about restructuring but because of the scale it'd involve, just had more important things to focus on (from way before joining the maintainer team). But now, I'm definitely more able to work on this to a greater degree.

So since I was already taking more of a backseat role, I think it probably makes most sense in this scenario to just flip the roles and still work together on this.

[Advaitmenon1106]

That sounds great @MaoShizhong

Thank you very much for your help!

[MaoShizhong]

We can both be assigned simultaneously \o/

[github-actions]

This issue is stale because it has had no activity for the last 30 days.