A simple webpack starter without a framework(github.com)
github.com
A simple webpack starter without a framework
https://github.com/SinanMtl/webpack-simple-starter
50 comments
I wouldn't say it's "simple" and "without framework". It comes with jQuery, bootstrap, popper.js, and for some reason it has a lot of dependencies including "express" which is only for servers.
Express (and probably others) are for the build system. It's used to serve the development mode application locally during development.
That's (part of the reason) why they are installed under devDependencies.
That's (part of the reason) why they are installed under devDependencies.
I see, it has a "dev-server.js". Why is that not a package? We have super simple functionality like "left pad" but not complex dev servers as a package? What if it breaks? Do I need to update the template?
There are dev server packages for webpack (https://webpack.github.io/docs/webpack-dev-server.html). I can't tell you why it's not used in this specific project.
It should be noted that those are the "old and busted" docs. https://webpack.js.org/configuration/dev-server/#devserver is the place to visit these days.
my bad, i make that mistake all the time. doesn't help that searching for webpack documentation always turns up the bad results first!
Thanks for the correction.
Thanks for the correction.
[deleted]
They do have packages for that, several, but they all don't work in all cases.
Some tend to be fairly custom, so they do it themselves. Ours for example serves several apps in the same repo, with both HTTPS and HTTP, including some hot reload middleware and integration with our CDN for some live assets in development.
As for "why we have left-pad but not this", anyone can make a package. If you want to make a `uselessjs` package that does literally nothing, you can.
Some tend to be fairly custom, so they do it themselves. Ours for example serves several apps in the same repo, with both HTTPS and HTTP, including some hot reload middleware and integration with our CDN for some live assets in development.
As for "why we have left-pad but not this", anyone can make a package. If you want to make a `uselessjs` package that does literally nothing, you can.
For those not familiar with NPM or package.json specs, the "devDependencies" are generally intended for development only and are not included when you do a standard `npm install` or add it as a dependency of your own project. This starter actually has 5 dependencies: bootstrap, jquery, lodash, object.observe, and popper.js
At the very least, one might say that those dependencies lock one into a quite particular style of coding... not a "framework" but not far from one.
Like I said in README. Bootstrap and depended javascript frameworks like jquery. Also, express.js is using to only development process. You can see dependencies in project.json. I meant "without frameworks" Vue, Angular and React-like frameworks.
I'm the primary maintainer for webpack-dev-server, and I was curious around the choice to roll your own dev-server.js, versus using webpack-dev-server. If there were shortcomings or things lacking, perhaps we can use that info to improve the module.
No, I have not used the webpack-dev-server before, but I will try. Thank you :)
Not sure if you're aware, but the vue-webpack template actually switched over to webpack-dev-server just last week
https://github.com/vuejs-templates/webpack/releases/tag/1.2....
https://github.com/vuejs-templates/webpack/releases/tag/1.2....
I'm looked at previous version. So I'm not awared.
Interesting thanks.
Is there an example in there of how you'd go about to create a basic bundle with the css/js frameworks, and then create additional bundles which depend on the first one, but do not include it?
It's an issue I need to solve now in a legacy app which already had a bundle for one area of the site, and another for another area. I need the same in Webpack, but I don't know how to declare the dependency on a common "root" bundle in webpack.
Is there an example in there of how you'd go about to create a basic bundle with the css/js frameworks, and then create additional bundles which depend on the first one, but do not include it?
It's an issue I need to solve now in a legacy app which already had a bundle for one area of the site, and another for another area. I need the same in Webpack, but I don't know how to declare the dependency on a common "root" bundle in webpack.
I built a similar starter kit that inludes both Webpack and Rollup. https://github.com/asteridux/asteridux it's definitely much simpler and bare-bones so it might not be for everyone.
Why does it have both webpack and rollup? Can't they both be configured to do the same thing? Why the duplication?
Yes they can. I can't speak for the offer, but I've used both in some testing/research environments.
It's worth noting that they way Webpack will parse classes with any "standard" build process will corrupt WebComponents custom element constructors. Rollup performs well here.
Of course maybe there's a more enlightened method to work with Webpack and WebComponents, but I don't know it.
So I have included both in one of my project-init scripts to run back-and-forth tests and see which performs better for the feature at hand. It's then pretty easy to remove one as a dependency once decided.
It's worth noting that they way Webpack will parse classes with any "standard" build process will corrupt WebComponents custom element constructors. Rollup performs well here.
Of course maybe there's a more enlightened method to work with Webpack and WebComponents, but I don't know it.
So I have included both in one of my project-init scripts to run back-and-forth tests and see which performs better for the feature at hand. It's then pretty easy to remove one as a dependency once decided.
They both have different use-cases. Webpack makes more sense on the front-end for bundling web apps but it sucks for bundling libraries.
so you can choose which one you want. I use both. Webpack is great for front-end apps. Rollup is way better for bundling libraries.
Just use jquery. In a few years jquery will be rediscovered and praised all over again.
There's a lot of jquery code out there that's basically lines and lines of for loops to maintain a state machine. Stuff that all these nice frameworks handle for you in a clean, bug-free way.
Almost every day of the year,
jQuery's an amazing tool at the low level, but there are some higher-layer stuff we can easily apply to manage state.
Almost every day of the year,
<div id='business-class' ng-class="{selected:seatType=='business'}">
Business Class
</div>
$('#seat_type').on('change', function(){
if(this.value == 'business'){
$('#business-class').addClass('selected');
} else {
$('#business-class').removeClass('selected');
}
});
jQuery's an amazing tool at the low level, but there are some higher-layer stuff we can easily apply to manage state.
Your Angular example appears to be an incomplete example, the jQuery one is more complete, so is this a valid comparison? When using jQuery you can still embed logic inside templates using something like https://github.com/wisercoder/uibuilder which is really tiny.
$('#business-class').toglleClass('selected', this.value === 'business');
this is indeed a cleaner example.
I think if you are diligent about your layout, you can separate out your DOM operations from your logic operations (think Flux) and end up with nice and simple code like this.
Personally I like the "rails" given to me in Angular/React (especially given I know how to circumvent them). I also am more productive in them. But I bet a lot of skilled programmers can go far with just simple tools like jQuery.
At least for me, having a paradigm enforced is useful, especially on larger projects with multiple stakeholders.
I think if you are diligent about your layout, you can separate out your DOM operations from your logic operations (think Flux) and end up with nice and simple code like this.
Personally I like the "rails" given to me in Angular/React (especially given I know how to circumvent them). I also am more productive in them. But I bet a lot of skilled programmers can go far with just simple tools like jQuery.
At least for me, having a paradigm enforced is useful, especially on larger projects with multiple stakeholders.
Don't. Please. I don't want to maintain your state spaghetti.
Or if you don't have state to manage, but a few small interactions, just use the plain browser API.
Back in the day jQuery was useful to maintain developer sanity across all the different browser API implementations and their quirks but, nowadays, it's mostly an unnecessary dependency. Even AJAX, which jQuery simplified immensely, has been superseded by fetch.
90% of jQuery code out there is querySelectorAll and fetch.
Or if you don't have state to manage, but a few small interactions, just use the plain browser API.
Back in the day jQuery was useful to maintain developer sanity across all the different browser API implementations and their quirks but, nowadays, it's mostly an unnecessary dependency. Even AJAX, which jQuery simplified immensely, has been superseded by fetch.
90% of jQuery code out there is querySelectorAll and fetch.
Not all frontend code needs state management in fact most could benefit feom having he state managed externally = websockets.
Plain javascript is ideal. If for semi-unsimple form validation you need to reach for a full featured framework and create a reusable component that will only be used once, stop. jQuery can simplify the experience.
Plain javascript is ideal. If for semi-unsimple form validation you need to reach for a full featured framework and create a reusable component that will only be used once, stop. jQuery can simplify the experience.
I didn't make it clear: I meant UI state, not application state. DOM manipulation is inherently stateful, and there is no way websockets are going to help with it.
Now your state can live in up to three places: DOM, JS and backend. It's even easier to desync UI state unless you rebuild the page from scratch (sending complete HTML as in old-school AJAX... or using React and the likes to make it fast enough to apply a diff of DOM changes).
I agree you don't need a framework for simple frontend code like form validation but:
> jQuery can simplify the experience.
How so? I'll quote my other reply:
> jQuery brings nothing to the table in 2017. I'm willing to be proved wrong. Is there anything that jQuery vastly simplifies?
(Compared to vanilla JS + CSS)
Now your state can live in up to three places: DOM, JS and backend. It's even easier to desync UI state unless you rebuild the page from scratch (sending complete HTML as in old-school AJAX... or using React and the likes to make it fast enough to apply a diff of DOM changes).
I agree you don't need a framework for simple frontend code like form validation but:
> jQuery can simplify the experience.
How so? I'll quote my other reply:
> jQuery brings nothing to the table in 2017. I'm willing to be proved wrong. Is there anything that jQuery vastly simplifies?
(Compared to vanilla JS + CSS)
> Don't. Please. I don't want to maintain your state spaghetti.
I fail to understand how not using jQuery prevents anyone from writing spaghetti code.
I've seen plenty of spaghetti code written with "framework du jour", Angular and React included.
I fail to understand how not using jQuery prevents anyone from writing spaghetti code.
I've seen plenty of spaghetti code written with "framework du jour", Angular and React included.
> state spaghetti
State is particularly hard to manage using jQuery because, unlike frameworks, it has no builtin way to deal with it.
The disconnect between DOM and JS state is what makes frontend programming a pain to deal with. This led to ad-hoc bug-ridden "state machines" (i.e. spaghetti global variables all over the place) that broke at the very first unexpected interaction.
If you're using a proper state machine (or your program is simple enough to not need them) you're better off just using the regular browser API.
jQuery brings nothing to the table in 2017. I'm willing to be proved wrong. Is there anything that jQuery vastly simplifies?
State is particularly hard to manage using jQuery because, unlike frameworks, it has no builtin way to deal with it.
The disconnect between DOM and JS state is what makes frontend programming a pain to deal with. This led to ad-hoc bug-ridden "state machines" (i.e. spaghetti global variables all over the place) that broke at the very first unexpected interaction.
If you're using a proper state machine (or your program is simple enough to not need them) you're better off just using the regular browser API.
jQuery brings nothing to the table in 2017. I'm willing to be proved wrong. Is there anything that jQuery vastly simplifies?
Even though your opinion seems unpopular here but I agree with you. If you're a one or two person team then jQuery, Angular 1 and PHP is all that you need to launch a SaaS site super quickly.
I'm not sure how you're agreeing with them since you threw in a framework, Angular 1.
Sorry, I guess you're right that I don't fully agree after all, because creating a site without Angular 1 (or Vue) would be certainly a nightmare for me too.
Agreed.
For some reason people in these threads think there's a battle between jQuery/vanillaJS vs a framework when the real distinction is the complexity of the application you're building.
Yes, when your needs are simple enough, you don't need anything. For some reason people get upvoted on HN/Reddit when they point this out.
For some reason people in these threads think there's a battle between jQuery/vanillaJS vs a framework when the real distinction is the complexity of the application you're building.
Yes, when your needs are simple enough, you don't need anything. For some reason people get upvoted on HN/Reddit when they point this out.
As (currently) a full time web developer I am very confident this will not happen. Feel free to call me out in the future if I am proven wrong.
$, _, backbone what more do you need? :D
A gun to kill myself.
What? was the grunt, gulp and pack not enough yet?
ps. I use closure-compiler and some py scripts... I hope ur running!
ps. I use closure-compiler and some py scripts... I hope ur running!
Whiskey
Marionette.js?
Thanks for the headsup.
I will look into backbone.radio but mn being 50k loc makes it hard for me to consume.
I will look into backbone.radio but mn being 50k loc makes it hard for me to consume.
Yeah, if you _are_ still using Backbone, then Marionette is a must-have. I can also recommend Ampersand.State as a vastly improved version of Backbone.Model, and Epoxy.js for data binding.
That said, an even better answer is to start using React for your views instead. I wrote a post about how we started adding React and Redux into our existing Backbone codebase, incrementally: http://blog.isquaredsoftware.com/2017/07/react-redux-backbon... .
That said, an even better answer is to start using React for your views instead. I wrote a post about how we started adding React and Redux into our existing Backbone codebase, incrementally: http://blog.isquaredsoftware.com/2017/07/react-redux-backbon... .
unfortunately I can not see any benefit for me to spend time with react or redux. When the libraries I'm interested in uses $(slickgrid).
Maybe when I have resources free to spend time learning new stuff.
But for now my mvp backbone $/ui/slickgrid connexion flask app is doing its job. And personally I like Javascript 1.5 more. Run that through closure-compiler and I have a lean js app.
gulping the cool aid was the last straw that broke the camel(damn missed perl) back. I'm happy if I can drive everything from py.
Maybe when I have resources free to spend time learning new stuff.
But for now my mvp backbone $/ui/slickgrid connexion flask app is doing its job. And personally I like Javascript 1.5 more. Run that through closure-compiler and I have a lean js app.
gulping the cool aid was the last straw that broke the camel(damn missed perl) back. I'm happy if I can drive everything from py.
Thanks. Even if I don't use this directly there is a lot to learn from this project, like one thing I just learnt right now is how to create a vendor.js file without explicitly specifying it in an array.
To be frank I don't consider your approach "simple"; just look at the number of build and configuration files you got or the number of dependencies in package.json.
IMHO a good starting point is one that you add to. Not one that you subtract from.