Giter Site home page Giter Site logo

Comments (21)

Phoscur avatar Phoscur commented on March 29, 2024

SourceMaps, how is that different to what you have implemented already for debugging?

I think you should keep improving in direction of your original goals.
While it should stay well modularised and pluggable into grunt, it could make it unneccessairy to use grunt at all.
Add optional linting with JSHint [possibly by refactoring to get interface for code manipulation on the way] and running tests. (Watch: lint and test only changed files/folders)

-Compression for production

Holy Grail: Hot code reload. Replace module objects at runtime.

from webpack.

sokra avatar sokra commented on March 29, 2024

Thanks for your feedback :)


For debugging javascript SourceMaps wouldn't be a big enhancment, but for compiled languages it would be really cool. Webpack could merge a loader-generated SourceMap with the SourceMap for the chunk and you could debug coffeescript source code, when bundled with webpack. That's cool, but maybe not so important...


Here is a jshint-loader.


Compression for production

Webpack minimizes javascript with uglify-js. (I want to upgrate to uglify-js 2...)
The css-loader minimizes css source.
The url-loader can inline files as DataUrl.
Missing is image compression in the file-loader.


Holy Grail: Hot code reload. Replace module objects at runtime.

hmmm... really cool, but really difficult, if not even impossible.

webpack-dev-server can automatically reload the page on bundle update.

from webpack.

Phoscur avatar Phoscur commented on March 29, 2024

Well, if you got all that, maybe it's time to advertise a little more, get more and better documentation, and focus on stability and bugfixes.

from webpack.

sokra avatar sokra commented on March 29, 2024

😄 I'm currently working on a new presentation to introduce webpack: http://webpack.github.com
but some stuff is still missing...

from webpack.

plievone avatar plievone commented on March 29, 2024

Hi, just some thoughts.. Keeping the core simple, perhaps modularizing webpack itself to multiple packages in a nodejs/unix way so that people are more easy with using parts of it in their projects. For example, how would you develop webpack so that framework authors such as https://github.com/socketstream/socketstream-0.4 would like to use webpack instead of developing and maintaining their own asset compiler?

Also important may be to look past the code modularisation to component modularisation (code, templates, styles, images, tests, even server responders). For example see TJ Holowaychuck's blog post and Justin Tulloss' presentation on Rdio's component organization both linked to in here componentjs/component#87

I would guess that for larger projects the build time will be important for developer productivity, so getting the dependencies from parsing code vs cached config could be an important distinction. Also language versions could compose asset bundles with differences such as strings baked in place, instead of only js-land translation functions.

With simple enough build tooling more complex feats become possible. Hotloading (non-general), for example, is possible with versioning in specifically modularized codebases (rdio can update their webapp components while the sound keeps on playing), and in general I would guess people use processes or servers (by utilizing service registries etc) to get the benefits of hotloading in specific domains without too fragmented side-effects.

from webpack.

sokra avatar sokra commented on March 29, 2024

Thanks for this great feedback too. I'll read/watch the stuff you linked tomorrow.


Modulizing webpack

Currently only some stuff is extracted into subpackages: resolving and require for node. As every "loader" is a separate package, these are good modulized.
What features do you think should be extracted into separate packages?


language versions

There is a i18n loader for webpack, but it's only working in js-land.
How would you imagine to use language versions with baked strings? i. e. $(".xyz").text(I18N_XYZ_TEXT);? Syntax for accessing language dependend stuff?

from webpack.

sokra avatar sokra commented on March 29, 2024

component modularisation

I've read TJ Holowaychuk's blog post on components. Like the idea of a "component" in the way to keep small independed modules with js and resources.

You can build modules with resources really easy with webpack:
There is no complex handling of non-js resources required.

require("./style.css");
var template = require("./template.jade");
// your js code...

Than it's just a require("module").

Or you could use component/component. You just have to build a "component-loader" for webpack to consume the "component.json".

There was a (hot) discussion about component/component vs. npm. I think webpack should not take a optinion towards this. You may even mix both, if you want.


hot-code replacement

If anybody want to write a framework with webpack, supporting hot-reloading, I would support him ;)

from webpack.

sokra avatar sokra commented on March 29, 2024

hot-code replacement

It's maybe possible to take care of this on module system level. I've created a separate issue for that.

from webpack.

sokra avatar sokra commented on March 29, 2024

@Phoscur @plievone I changed my optinion regarding hot code replacement. It's definitly possible and awsome on module level. I already have a working node.js implementation and will create a webpack solution soon. So you'll be able to use hot code replacement in the server and the client. 😄

from webpack.

miffels avatar miffels commented on March 29, 2024

In my opinion, a mocha loader would be great. Currently I am preferring grunt over webpack for just two reasons: You do not need to write a build.js but a simple configuration file (gruntfile), and it comes with support for mocha. If building my web project from node source and still running tests etc. on node was that easy, that'd be a huge plus for webpack and a dependency less for my projects.

from webpack.

sokra avatar sokra commented on March 29, 2024

@miffels I've hacked a small example how testing with webpack could be: webpack-tests-example. If there are more people interessted I could offer it as module.

from webpack.

sokra avatar sokra commented on March 29, 2024

@miffels https://github.com/webpack/mocha-loader (Only works with webpack 0.8 beta)

I will do some tests for not included loaders with it so it can be used as example.

# [email protected]
npm install webpack-dev-server -g
npm install mocha-loader
webpack-dev-server mocha!./tests.js
http://localhost:8080/
# It will do tests and run them again if you change a file

from webpack.

miffels avatar miffels commented on March 29, 2024

@sokra Sorry, I missed the update. I'll give it a shot, thank you very much!

from webpack.

sokra avatar sokra commented on March 29, 2024

@plievone Localization with strings baked in: https://github.com/webpack/webpack/tree/master/examples/i18n

from webpack.

jcw avatar jcw commented on March 29, 2024

+1 for supporting hot loading
+1 for supporting socketstream
+1 for supporting components

from webpack.

sokra avatar sokra commented on March 29, 2024

components is supported: #46 (comment)

from webpack.

sokra avatar sokra commented on March 29, 2024

socketstream support may be possible, but it's up to @owenb. You may write an issue there proposing it.

hot code replacement is on the roadmap...

from webpack.

jcw avatar jcw commented on March 29, 2024

Toll!!!

from webpack.

owenb avatar owenb commented on March 29, 2024

I'm keen to look into using webpack in SocketStream 0.4.

Right now I'm focussed on finishing the realtime/websocket server and client components. These will end up as separate modules, usable on their own regardless of which asset builder/module system you use in your app.

However, I still want to offer people a complete end-to-end solution and webpack may play a part in that. I have yet to fully investigate it, but already I see many good ideas.

I'll let you know when I get chance to play with it properly. Keep up the good work @sokra

from webpack.

sokra avatar sokra commented on March 29, 2024

Sounds good :)

Feel free to ask if you have any question or idea... 😄

from webpack.

sokra avatar sokra commented on March 29, 2024

old -> closed

from webpack.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.