Vue.js and Brunch: Webpack Alternative(vuejsdevelopers.com)
vuejsdevelopers.com
Vue.js and Brunch: Webpack Alternative
https://vuejsdevelopers.com/2017/08/20/vue-js-brunch/?jsdojo_id=reddit_vpb
112 comments
Great ideas. It seems like this sort of 'sane defaults' functionality could easily be added to future versions of webpack, and that might really help with adoption... rather than this community endlessly switching tool chains.
I'm surprised we haven't seen config packages for webpack take off along the lines of the configs in the ESLint community. There's nothing stopping anyone from publishing an extensible base config.
I was under the impression that was the idea behind the new webpack cli (though I haven't tried it).
The main issue is generally that there isn't much of a consensus on toolchain. Are you using vanilla ES6 or TypeScript? If the former, are you sticking to the standard or using class properties and object spread? Are you also adding non-stage3 crap like bind operator and decorators?
For CSS, are you using styled components or Sass? Maybe you're using PostCSS? If so, with which plugins?
Are you doing codesplitting? If so, how? Are you using a DLL plugin for your vendor stuff? Oh, and how would you like to handle far future caching?
For a trivial app there probably can be a default, but unlike something like ESLint, any app that plans on living more than a little bit needs to answer all these questions and the answer is not obvious.
Generally you could stick with some defaults that represent a majority opinion, but right now its so close to 50/50, it's hard. Still could be done though.
The main issue is generally that there isn't much of a consensus on toolchain. Are you using vanilla ES6 or TypeScript? If the former, are you sticking to the standard or using class properties and object spread? Are you also adding non-stage3 crap like bind operator and decorators?
For CSS, are you using styled components or Sass? Maybe you're using PostCSS? If so, with which plugins?
Are you doing codesplitting? If so, how? Are you using a DLL plugin for your vendor stuff? Oh, and how would you like to handle far future caching?
For a trivial app there probably can be a default, but unlike something like ESLint, any app that plans on living more than a little bit needs to answer all these questions and the answer is not obvious.
Generally you could stick with some defaults that represent a majority opinion, but right now its so close to 50/50, it's hard. Still could be done though.
There IS an abstraction on top of Webpack called "terse webpack":
https://github.com/ericclemmons/terse-webpack
It seems to have presets for sane defaults on the roadmap.
https://github.com/ericclemmons/terse-webpack
It seems to have presets for sane defaults on the roadmap.
I'm redoing that whole stack, as it was a prototype to get buy-in to "fix" the Webpack API for most cases.
For an eslint-style plugin system I'd recommend webpack-blocks.
For an eslint-style plugin system I'd recommend webpack-blocks.
I know this will get downvoted, but here I go anyway: Please stop reinventing the wheels. Just stick to one library/framework whatever crap they are. Why? Because your new shiny wheel will be as crap as the old one very soon.
I am myself refusing learning new tools in javascript. I think I have spent enough time learning enough of them. I have a selected set of them, and I turn down projects which fall out of that set. Less money, but better mental health.
I am myself refusing learning new tools in javascript. I think I have spent enough time learning enough of them. I have a selected set of them, and I turn down projects which fall out of that set. Less money, but better mental health.
one thing i learned to accept with the web is just how fast a trend can change in this industry. after i invested time in knockout, then came angular. then once i invest in angular, then came react. then after investing time in react, then came vuejs. it seems to either be a systematic cycle of people wanting to always try new things or that the tools are infact getting better and better.
and once a group of pack starts going off in one direction, its just a matter of time before everyone is on it. for better or worse, it seems hard to stop this type of movement.
im not sure why this is tbh, because mastering your tools is a big part of becoming a 10x developer, where you are actually productively creating and not just looking up docs half the time.
perhaps this type of fad may be mainly driven by beginning or jr devs who are still undecided on what they want to learn and just go with what seems to be the next cool thing to learn.
but then again without this type of change, we might as well all be still coding in perl. it really sucks to throw away what you invested in for a year or more but its just something you have to accept as a dev and move on these days as a javascript developer.
and once a group of pack starts going off in one direction, its just a matter of time before everyone is on it. for better or worse, it seems hard to stop this type of movement.
im not sure why this is tbh, because mastering your tools is a big part of becoming a 10x developer, where you are actually productively creating and not just looking up docs half the time.
perhaps this type of fad may be mainly driven by beginning or jr devs who are still undecided on what they want to learn and just go with what seems to be the next cool thing to learn.
but then again without this type of change, we might as well all be still coding in perl. it really sucks to throw away what you invested in for a year or more but its just something you have to accept as a dev and move on these days as a javascript developer.
the FE world used to be anemic in term of options. Then came Ajax, stronger web standards and eventually ES6, HTML5, etc.
So that was a period of transition where finally all of the stuff the rest of world had was within our reach. But since we were starting (almost) from scratch, we had a chance to make it better. However, to do that, we had to experiment (and fail a lot).
Thats where you saw all these tools as people iterated on it. It slowed down a lot now, and a lot of concepts bubbled up on top and we're down to only a couple of mainstream options (there's a lot of more obscure ones, but that's true in JVM/backend land too, and that's been around for a while).
So that was a period of transition where finally all of the stuff the rest of world had was within our reach. But since we were starting (almost) from scratch, we had a chance to make it better. However, to do that, we had to experiment (and fail a lot).
Thats where you saw all these tools as people iterated on it. It slowed down a lot now, and a lot of concepts bubbled up on top and we're down to only a couple of mainstream options (there's a lot of more obscure ones, but that's true in JVM/backend land too, and that's been around for a while).
I loved Brunch back a few years ago. But I wasn't happy with how plugins worked, or their "all files get included in your bundle even if you never required them".
So I built my own build system on top of Gulp, and added a set of tasks using browserify for web apps (https://github.com/BraveNewWorldDev/parched-example-app). It's heavily "convention over configuration", like "npm install parched-babel" is all you need to get Babel integrated.
I'm still using it in production on websites, Cordova apps, and Electron apps, but I'd still recommend webpack nowadays since that's where the community is.
So I built my own build system on top of Gulp, and added a set of tasks using browserify for web apps (https://github.com/BraveNewWorldDev/parched-example-app). It's heavily "convention over configuration", like "npm install parched-babel" is all you need to get Babel integrated.
I'm still using it in production on websites, Cordova apps, and Electron apps, but I'd still recommend webpack nowadays since that's where the community is.
Oh boy I just finished moving my old gulp+browserify(+sass+postcss) config to webpack. It was a bunch of custom nonsense.
In return I got a faster build, 20% lighter output and a lot more information (webpack shows size, etc)
In return I got a faster build, 20% lighter output and a lot more information (webpack shows size, etc)
Do you guys use any public websites that are based Vue, React or alike?
Everytime I search for sites that use frameworks like Vue or React, I came up with mostly empty hands. Except for example pages or pages by coders for coders. Or pages that "use" one of the frameworks but seem to make no use at all of the functionality.
When I ask around people usually tell me "Well, at my company we make a dashboard for another company and it's based on ..."
Any popular public sites (Aka no login needed to access it. So Facebook doesn't count.) for non-coders out there that use these frameworks?
Everytime I search for sites that use frameworks like Vue or React, I came up with mostly empty hands. Except for example pages or pages by coders for coders. Or pages that "use" one of the frameworks but seem to make no use at all of the functionality.
When I ask around people usually tell me "Well, at my company we make a dashboard for another company and it's based on ..."
Any popular public sites (Aka no login needed to access it. So Facebook doesn't count.) for non-coders out there that use these frameworks?
We're using React on NFL.com's new home page and Vue on https://nextgenstats.nfl.com/ (two different teams). AirBnB is mostly React too.
Interesting. What would you say are the main advantages over simply passing the data through a server side rendering library?
Not the grandparent, but it makes things a lot easier.
Basically, think of something as trivial as form validation. You need to do it both client and server-side regardless, but client side you might have additional complexity, like "if paying by credit card, show those fields, and if paying by PayPal, redirect." This means that your server might need to be aware of these branches of state that might happen, and it means complexity.
On the other hand, if you keep UI state to the UI layer on the client, the server side becomes super simple: you have an API that says something like "here are the shipping and billing details using a credit card. Charge it" or "shipping and billing details + PayPal token. Charge it." There is no "if we are rendering a PayPal processing error, re-render the entire state of the page, preserving all the checkboxes and showing the right bits of the DOM." It's just pure business logic.
Something like Vue is also much better geared at doing a UI than a server-side rendered template. It's dynamic by nature, and directly affects the DOM. The state is kept in such a way that it pertains to the UI. If you are processing something like a request to /orders?filter=recent&order=amount&page=3, you have to re-parse the state from the URL and then get the results every time. Vue/VueX will keep the state in a convenient fashion and the URL can be instructed to reflect it. No need to write custom code to interpret it.
Simple CRUD stuff is super easy with Vue + VueX + Bootstrap + Django. That's been my stack and I like it. Complicated stuff if much faster to develop using this than to try to use something like Django templates + jQuery.
Basically, think of something as trivial as form validation. You need to do it both client and server-side regardless, but client side you might have additional complexity, like "if paying by credit card, show those fields, and if paying by PayPal, redirect." This means that your server might need to be aware of these branches of state that might happen, and it means complexity.
On the other hand, if you keep UI state to the UI layer on the client, the server side becomes super simple: you have an API that says something like "here are the shipping and billing details using a credit card. Charge it" or "shipping and billing details + PayPal token. Charge it." There is no "if we are rendering a PayPal processing error, re-render the entire state of the page, preserving all the checkboxes and showing the right bits of the DOM." It's just pure business logic.
Something like Vue is also much better geared at doing a UI than a server-side rendered template. It's dynamic by nature, and directly affects the DOM. The state is kept in such a way that it pertains to the UI. If you are processing something like a request to /orders?filter=recent&order=amount&page=3, you have to re-parse the state from the URL and then get the results every time. Vue/VueX will keep the state in a convenient fashion and the URL can be instructed to reflect it. No need to write custom code to interpret it.
Simple CRUD stuff is super easy with Vue + VueX + Bootstrap + Django. That's been my stack and I like it. Complicated stuff if much faster to develop using this than to try to use something like Django templates + jQuery.
Well, these are the general arguments for these frameworks. But how do they apply to the linked page? I used it for a while and did not come across a Credit Card vs Paypal form.
The linked page simply talks about Using a simpler compilation toolchain than the Vue standard one (Webpack), at the cost of it supporting fewer features. It's sort of like the argument of using clang vs GCC: it assumes you already are using C for your project, just talking about which compiler. Actually a better example would be autotools vs CMake.
In my opinion, client-side rendering is here as a justification for the unfortunate splitting of the Fullstack developer into Frontend/Backend roles.
Frontend developer used to be a designer who also knew HTML/CSS but the problem with that is that in order to do CSS well, you need to be a programmer. Especially if you're trying to achieve effects that work best as a mix of JS/CSS. Unfortunately, when it comes to design, UX and UI, most developers are lazy and refuse to learn the basics of it. So in order to prevent PMs from assigning them design-related tasks, the role of Frontend developer was born.
And once there was a separate role, it only made sense to isolate the Frontend developers' environment from the backend developers' so that they could stop stepping on each others toes.
Essentially, the whole Single Page Application architecture is because there is a class of developers who imagine that it's sensible to completely ignore design considerations and who built a moat around their responsibilities in the form of an unnecessary abstraction. Now rather than our views having direct access to our databases, we need a separate API endpoint for every single database call and since we can't trust client code, we need to authorize/authenticate every single little action rather than being able to blindly trust the code that's being run like we used to.
Frontend developer used to be a designer who also knew HTML/CSS but the problem with that is that in order to do CSS well, you need to be a programmer. Especially if you're trying to achieve effects that work best as a mix of JS/CSS. Unfortunately, when it comes to design, UX and UI, most developers are lazy and refuse to learn the basics of it. So in order to prevent PMs from assigning them design-related tasks, the role of Frontend developer was born.
And once there was a separate role, it only made sense to isolate the Frontend developers' environment from the backend developers' so that they could stop stepping on each others toes.
Essentially, the whole Single Page Application architecture is because there is a class of developers who imagine that it's sensible to completely ignore design considerations and who built a moat around their responsibilities in the form of an unnecessary abstraction. Now rather than our views having direct access to our databases, we need a separate API endpoint for every single database call and since we can't trust client code, we need to authorize/authenticate every single little action rather than being able to blindly trust the code that's being run like we used to.
Boy I don't mess the days of dealing with SQL queries inside of PHP "view" files. Reminiscing aside, you can build server-side applications in both Vue and React.
I'm not advocating for SQL in views. MVC and ORM are great. As is free auth and form generation from database models. I haven't seen a framework that gives me everything that Django or Laravel does for free.
You are _completely_ missing the point of frontend applications, here's a few to get you started:
- Ease of creating complex user flows.
- Decentralization of application work: app runs on client, less CPU cycles for my server!
- Separation of concerns: API does one thing, client application does another, there is a bright red line between the two.
- Ease of creating complex user flows.
- Decentralization of application work: app runs on client, less CPU cycles for my server!
- Separation of concerns: API does one thing, client application does another, there is a bright red line between the two.
You can build complex user flows with JavaScript on top of server rendered views. Ajax works great with server side rendering, see Pjax https://github.com/defunkt/jquery-pjax or Intercooler http://intercoolerjs.org/
The server is rendering JSON anyway, more or less just as expensive to serve HTML. Besides, the bottleneck is usually database access.
It's a false separation and forces you to expose far more than necessary. It's nice to have my full database available on every page render without needing to define explicit endpoints.
I also like having forms generated from database models.
The server is rendering JSON anyway, more or less just as expensive to serve HTML. Besides, the bottleneck is usually database access.
It's a false separation and forces you to expose far more than necessary. It's nice to have my full database available on every page render without needing to define explicit endpoints.
I also like having forms generated from database models.
Just install the React Developer Tool extension on chrome:
https://chrome.google.com/webstore/detail/react-developer-to...
It will light up whenever you are navigating a page built w/ React. Plus, you can dig around and see how they structured it.
Some times you get funny surprises, like how the Microsoft node js page was using React, but they had deployed a Development build instead of a Production build.
It will light up whenever you are navigating a page built w/ React. Plus, you can dig around and see how they structured it.
Some times you get funny surprises, like how the Microsoft node js page was using React, but they had deployed a Development build instead of a Production build.
Isn't it Slack that deploys a Dev build because "it's easier to debug people's problems this way"?
... Microsoft keep doing that. They've deployed development builds to Office 365 production.
Incidentally, Office 365 SharePoint is built on React.
Incidentally, Office 365 SharePoint is built on React.
For Vue, you can use the Vue Devtools extension to do the same. If they deploy in production mode you won't see any details though.
We use Vue at GitLab. You can see why we chose Vue as written by our front-end lead.
https://about.gitlab.com/2016/10/20/why-we-chose-vue/
https://about.gitlab.com/2016/10/20/why-we-chose-vue/
>A simple, but practical example we're using in production: on a GitLab Issue, the issue's state is displayed as either closed or open. That simple value can change often and needs to be represented in several views. With JQuery, we had about 30 or so lines of code to propagate those changes, and those lines involved multiple classes and querying the DOM by hand.
Yep, been there. That type of jQuery gobbledygook has resulted in more bugs than I'd like to admit slipping past my team.
Vue has been an absolute life saver.
Yep, been there. That type of jQuery gobbledygook has resulted in more bugs than I'd like to admit slipping past my team.
Vue has been an absolute life saver.
Is there any plan to do a follow up post to this?
I'd love to see what work flows or examples you guys are using to progressively upgrade pieces of the application to use Vue.
For example, it would be really great to see a blog post with a before and after for a feature that you've converted from jQuery to Vue.
I'd love to see what work flows or examples you guys are using to progressively upgrade pieces of the application to use Vue.
For example, it would be really great to see a blog post with a before and after for a feature that you've converted from jQuery to Vue.
This was the followup post our front-end lead wrote:
https://about.gitlab.com/2017/02/06/vue-big-plan/
I don't think it's exactly what you were asking for, but I'll pass this suggestion along to our front-end lead that wrote these two posts.
https://about.gitlab.com/2017/02/06/vue-big-plan/
I don't think it's exactly what you were asking for, but I'll pass this suggestion along to our front-end lead that wrote these two posts.
Netflix.com is built using React, including the non-authenticated experience (sign up, sign in, title pages, etc)
At issuu we do a lot of React work. Our document viewer and document page are built with it: https://issuu.com/mintymagazine/docs/minty_magazine_issue_10.... Our search page also uses React for everything: https://issuu.com/search?language=all&q=fashion&sortby=date&....
I built my (super simple) budgeting app with the vue-pwa template with vue-cli. https://budgetme.surge.sh
Disregard the extremely bootstrap-esque css. I threw it together in a matter of hours to just experiment with Vue.
Not popular at all, as far as I know, but then I don't even have analytics on it to even know if it is popular or not.
Disregard the extremely bootstrap-esque css. I threw it together in a matter of hours to just experiment with Vue.
Not popular at all, as far as I know, but then I don't even have analytics on it to even know if it is popular or not.
Here's a project I'm working on that uses react: https://edabit.com
Thanks!
Tried it a bit and thought: "Hmm.. it's probably react that causes all these spinning "loaders" everytime I click somewhere. Wouldn't it be better without?". How do you see that?
EDIT: Ups, why the downvotes? With spinning "loaders" I mean the "loading" animation the website shows. The spinning circle. Anything bad about this question?
Tried it a bit and thought: "Hmm.. it's probably react that causes all these spinning "loaders" everytime I click somewhere. Wouldn't it be better without?". How do you see that?
EDIT: Ups, why the downvotes? With spinning "loaders" I mean the "loading" animation the website shows. The spinning circle. Anything bad about this question?
> Anything bad about this question?
You didn't ask a question, you jumped to a (wildly inaccurate) conclusion.
You didn't ask a question, you jumped to a (wildly inaccurate) conclusion.
In which sense inaccurate? If the server would just send a rendered page, why would a loading animation be needed?
> it's probably react that causes all these spinning "loaders" everytime I click somewhere
Statistically speaking it's _probably_ jQuery or pure JavaScript. These loading spinners have been around to make site loading more attractive for a long time, predating React, Vue, Ember, even Backbone. I have tons of clients on Wordpress that love this kind of thing even if all it does is make their site load without a flash of unstyled content (FOUC).
> If the server would just send a rendered page
React is primarily a client-side framework, but it's possible to render it on the server using Node. However, a lot of sites still use React to enhance an existing frontend, and therefore do not port their entire server to Node to render with React.
> why would a loading animation be needed?
Alright so lets assume you've server-rendered with React, do you still need a loading animation? Maybe. All these sites you click on that have loading spinners are all server-rendered pages too, but that doesn't stop people from throwing jQuery plugins at it to make their sites look fancy and prevent a FOUC. It's more a question of how many images the site wants to display above the fold. If there's a bunch of images, your site will not load fast and you can choose between letting users see a gappy page gradually get filled in or sit and look at a spinner for 1.5s.
EDIT: not to mention all the advertising trackers these sites have enabled. This makes your image-loading all the more laggy.
Statistically speaking it's _probably_ jQuery or pure JavaScript. These loading spinners have been around to make site loading more attractive for a long time, predating React, Vue, Ember, even Backbone. I have tons of clients on Wordpress that love this kind of thing even if all it does is make their site load without a flash of unstyled content (FOUC).
> If the server would just send a rendered page
React is primarily a client-side framework, but it's possible to render it on the server using Node. However, a lot of sites still use React to enhance an existing frontend, and therefore do not port their entire server to Node to render with React.
> why would a loading animation be needed?
Alright so lets assume you've server-rendered with React, do you still need a loading animation? Maybe. All these sites you click on that have loading spinners are all server-rendered pages too, but that doesn't stop people from throwing jQuery plugins at it to make their sites look fancy and prevent a FOUC. It's more a question of how many images the site wants to display above the fold. If there's a bunch of images, your site will not load fast and you can choose between letting users see a gappy page gradually get filled in or sit and look at a spinner for 1.5s.
EDIT: not to mention all the advertising trackers these sites have enabled. This makes your image-loading all the more laggy.
The loading spinners happen when data is being fetched from the database. The app itself is downloaded upon initial load and anything from the database will trigger a loading spinner as it's being fetched.
Just thought I'd share my experience with this, since I had a similar problem.
Spinners make it look like the app is taking ages to load data, even if it's not. If you delay showing the spinner until around a second of loading, it makes things feel a lot faster.
The user doesn't need to always know when the app is loading data until there's a significant pause and they need to know stuff is happening.
Spinners make it look like the app is taking ages to load data, even if it's not. If you delay showing the spinner until around a second of loading, it makes things feel a lot faster.
The user doesn't need to always know when the app is loading data until there's a significant pause and they need to know stuff is happening.
Yup, I got that. But couldn't a bit of text be loaded instantly instead?
Is the time the spinners run determined by the time the server needs to deliver the data? Would they go away when you put the site behind a CDN that delivers the data faster?
Is the time the spinners run determined by the time the server needs to deliver the data? Would they go away when you put the site behind a CDN that delivers the data faster?
> But couldn't a bit of text be loaded instantly instead?
Yep. You could code your website in such a way to use a mix of serverside rendering and ajax components. This has always been true. Consider something like a server-rendered blog post that has a client-rendered Disqus widget.
> Is the time the spinners run determined by the time the server needs to deliver the data?
Basically. But you can also render your react app or vue on the server and then have client side rendering take over once the page is loaded. This is perhaps the ideal case but it's more complicated and takes some work to set up (I haven't actually done it).
> Is the time the spinners run determined by the time the server needs to deliver the data?
Basically. But you can also render your react app or vue on the server and then have client side rendering take over once the page is loaded. This is perhaps the ideal case but it's more complicated and takes some work to set up (I haven't actually done it).
lol what kind of websites do you make? internationaloilandgas.com? drbronvillesfootcream.com?
I built my side project with Vue: https://wherecaniwatchmy.team
Client side rendering saved my bacon when it went mini-viral a few weeks ago. My little home server probably would have keeled over and died had it been rendering all the pages, but just serving static files is a piece of cake.
Client side rendering saved my bacon when it went mini-viral a few weeks ago. My little home server probably would have keeled over and died had it been rendering all the pages, but just serving static files is a piece of cake.
How do you do SEO?
My new headless CMS uses Vue: https://www.headless.rest
It uses webpack with alot of code splitting so instead of 1 big bundle its many small bundles which should help loading times alot.
It uses webpack with alot of code splitting so instead of 1 big bundle its many small bundles which should help loading times alot.
Uses all features of Vue, including SSR, async-loaded components, etc.: https://pricehipster.com
Man, this is so slow that I am typing this comment while the page is loading...
Now it loaded. It says:
Connection timed out
The initial connection between Cloudflare's network and the origin web server timed out. As a result, the web page can not be displayed.
Now it loaded. It says:
Connection timed out
The initial connection between Cloudflare's network and the origin web server timed out. As a result, the web page can not be displayed.
That's odd because this website is lightning fast. Perhaps there was a network issue?
It may be slower for you if you're on the other side of the world, but you shouldn't be able to do much more than switch tabs during the load even if that is the case.
It may be slower for you if you're on the other side of the world, but you shouldn't be able to do much more than switch tabs during the load even if that is the case.
https://mobile.twitter.com/ uses React, Redux, and React Router.
https://youpic.com/ (press explore) uses React and Redux.
New york times uses React: https://www.nytimes.com/
https://www.thestar.com/ uses React
react / react router for 100% of https://constructionjobs.com
Airbnb uses React extensively FWIW
Quizlet uses react.
Brunch has a good "vs Webpack" section in their docs: http://brunch.io/docs/why-brunch#brunch-vs-webpack
Some of the big table stakes features that Brunch is missing are code splitting and handling of binary assets (allowing things like image inlining). It also doesn't have true hot module reloading, which is a pretty useful dev feature.
Some of the big table stakes features that Brunch is missing are code splitting and handling of binary assets (allowing things like image inlining). It also doesn't have true hot module reloading, which is a pretty useful dev feature.
I can't live without hot module reloading anymore.. With my Vue projects (no idea if React does it like this too) I can update my code and it only reloads either CSS, JS or HTML and it completely maintains state. Textfields maintain their content while I edit their CSS, just great.
Wasn't long ago that auto reload on file change was a fancy feature...
Wasn't long ago that auto reload on file change was a fancy feature...
Code splitting seems like a major feature to miss out on. I assume/hope it will come to Brunch sooner rather than later.
I looked into Vue + Webpack vs Vue + Brunch on my last project. I ended up with Brunch because the requirements are fairly basic and Brunch are easier to grok. Had the requirements be a little bit more complex, I could have easily gone for Webpack.
IMO, there are a few key things lacking with the Vue + Brunch combo:
- The `vue-brunch` plugin seems to be no longer in active development? (https://github.com/theocodes/vue-brunch)
- The `sass-loader` plugin allows me to use Sass dialect in SFC-style Vue (Single File Component). I'm using plain CSS with Vue + Brunch SFC as I cannot find a Brunch plugin offering similar functionality.
- There are some Brunch idiosyncracies. For one, the processing pipeline is executed as per `package.json` (dev)Dependencies ordering. I spent quite a bit of time before figuring this out.
IMO, there are a few key things lacking with the Vue + Brunch combo:
- The `vue-brunch` plugin seems to be no longer in active development? (https://github.com/theocodes/vue-brunch)
- The `sass-loader` plugin allows me to use Sass dialect in SFC-style Vue (Single File Component). I'm using plain CSS with Vue + Brunch SFC as I cannot find a Brunch plugin offering similar functionality.
- There are some Brunch idiosyncracies. For one, the processing pipeline is executed as per `package.json` (dev)Dependencies ordering. I spent quite a bit of time before figuring this out.
I really love using Laravel Mix [1], which is a wrapper around webpack. I know nothing about webpack, because mix makes it easy to just get going on my actual project instead of futzing about with configuration.
Edit: FYI, Laravel not required.
1. https://github.com/JeffreyWay/laravel-mix/tree/master/docs#r...
Edit: FYI, Laravel not required.
1. https://github.com/JeffreyWay/laravel-mix/tree/master/docs#r...
Agreed - Laravel Mix makes it absurdly easy to get started with Webpack, while still getting a lot of power out of it. And you can use it in anything: a mostly server-side app (like a typical Laravel project, where Mix originated), a complex SPA, or even a WordPress theme (which I found myself doing over the weekend).
Years ago when Phoenix was adding JS support I lobbied Chris McCord to go with Webpack. He took a lengthy look at the setup/configuration process for all of the popular build tools and ended up choosing Brunch. For most tasks it is a great choice, and an excellent default for a "batteries included" web framework.
I've been writing a Brunch/Vue.js app for the last few months and, for a relative newcomer to JavaScript frameworks, Brunch was far easier to get up and running with than Webpack. I spent a couple of days failing to get things working the way I wanted with Webpack and after discovering Brunch I was productive within half an hour.
My `brunch-config.js` is about 30 lines long and everything works as I'd expect.
My `brunch-config.js` is about 30 lines long and everything works as I'd expect.
If you're looking for alternatives to Webpack, please also check out JSPM (a good short description might be "preprocessing system + package manager + systemjs"):
https://jspm.io/
It takes a little more to get it to work with vue (the plugin that makes .vue files work is older and unsupported nowadays), but I use it just fine, with my template, styling and component files separated (I wrote a little thing: https://gitlab.com/mrman/systemjs-plugin-vue-template-compil...)
If you dislike how complex webpack is, you'll like JSPM -- here's the video that got me hooked (it's pretty old but still valid): https://www.youtube.com/watch?v=iukBMY4apvI
https://jspm.io/
It takes a little more to get it to work with vue (the plugin that makes .vue files work is older and unsupported nowadays), but I use it just fine, with my template, styling and component files separated (I wrote a little thing: https://gitlab.com/mrman/systemjs-plugin-vue-template-compil...)
If you dislike how complex webpack is, you'll like JSPM -- here's the video that got me hooked (it's pretty old but still valid): https://www.youtube.com/watch?v=iukBMY4apvI
We used JSPM in production for a year and a half. We had to switch back to Webpack because JSPM's bundles (even with HTTP2 enabled) were slowing down our time to first render drastically. About an extra 2 seconds on 3g mobile compared to the same site with webpack.
We're an edge case though, for most sites JSPM will work fine, and if it's currently working for you don't switch over. Switching over was a pain so I don't recommend switching unless you absolutely have to. I would not recommend using it for new projects though.
We're an edge case though, for most sites JSPM will work fine, and if it's currently working for you don't switch over. Switching over was a pain so I don't recommend switching unless you absolutely have to. I would not recommend using it for new projects though.
Rollup looks pretty good too. It's on my list to play with.
https://rollupjs.org/
https://rollupjs.org/
Rollup and webpack serve two somewhat different purposes: https://medium.com/webpack/webpack-and-rollup-the-same-but-d...
Rollup looks like the future - one big plus is the output looks nearly hand crafted compared to the unreadable mess webpack shits out.
This does look nice but we can solve the configuration difficulty of Webpack without switching tools. Webpack should be the standard we all get behind until there is a tool that offers significant improvements, not just being easier to use.
We are using an internal NPM package for common Webpack settings similar to the JetBrains library [1]. With that setup, our Webpack configs are much easier to use. There are other libraries like webpack-config [2] that give you a fluent api and allow common configs to be extended.
[1] https://github.com/JetBrains/ring-ui [2] https://www.npmjs.com/package/webpack-config
We are using an internal NPM package for common Webpack settings similar to the JetBrains library [1]. With that setup, our Webpack configs are much easier to use. There are other libraries like webpack-config [2] that give you a fluent api and allow common configs to be extended.
[1] https://github.com/JetBrains/ring-ui [2] https://www.npmjs.com/package/webpack-config
How can you use this for any real production apps over webpack when it doesn't even support code splitting. This is nice for bootstrapping projects, or using just a little JS on certain pages. Otherwise I don't see how you could use it in an all JS app
in the first paragraph the author addresses this directly. The author suggests this may be suitable for smaller projects
> Webpack is a crucial tool for building sophisticated, highly optimized web applications, and is encouraged by many influential web developers.
However, for newer developers, or those working on less ambitious projects, Webpack mostly occurs as a barrier
> Webpack is a crucial tool for building sophisticated, highly optimized web applications, and is encouraged by many influential web developers.
However, for newer developers, or those working on less ambitious projects, Webpack mostly occurs as a barrier
Do we still need Webpack when all connections can use HTTP/2 and TLS thanks to LetsEncrypt ?
Webpack does much more than just put all your stuff in 1 bundle. It minifies, it does code splitting (only load what you need, HTTP2 is even a benefit here), tree shaking (remove unsued CSS), it can change your import paths for your convienence and so much more.
Really it can do everything and that's why its so daunting for developers.
Really it can do everything and that's why its so daunting for developers.
You need webpack to actually use a Vue component (template + script + CSS).
You can use Browserify or Rollup too.
https://github.com/vuejs/vueify
https://github.com/vuejs/rollup-plugin-vue
https://github.com/vuejs/vueify
https://github.com/vuejs/rollup-plugin-vue
Yes, I meant that the OP comment missed a large chunk of webpack use cases, such as compilation of components.
Damn, I see that as unnecessary tight coupling, but a lot of our current technologies have survived that way.
I thought the vue-cli(https://github.com/vuejs/vue-cli) tool did a pretty good job of creating sane webpack configurations by asking just a few basic questions.
For those new to Vue, Vue-CLI + templates have all the webpack configuration set up already for you. This makes setting up a Vue project very quick and simple.
https://github.com/vuejs/vue-cli https://github.com/vuejs-templates
https://github.com/vuejs/vue-cli https://github.com/vuejs-templates
Similar to Brunch but more opinionated is Jus. http://jus.js.org/
I really enjoyed using it, but alas I wanted a different Markdown loader (theirs is based off Github markdown, which doesn't support footnotes), so I switched to Metalsmith. But Jus and Brunch and the like are great options.
[deleted]
not sure if i did something wrong, but i cloned the app and ran the build and there's over 7500 lines of boilerplate included before the 'main.js' import in public/app.js. what is going on?
How long can we keep adding to the tower of javascript shitware before it falls over? Honestly I thought it would have fallen over a long time ago.
Just looking at long chains of mystery-meat that npm imports, and the time it takes Babel to compile the simplest of projects make me just want to say the hell with it all and do everything as GET/POST.
Just looking at long chains of mystery-meat that npm imports, and the time it takes Babel to compile the simplest of projects make me just want to say the hell with it all and do everything as GET/POST.
I wonder the same thing myself. Occasionally I look into these frameworks to see if they really add anything to the development of complex web applications vs. the amount of work they take to integrate them and it always heavily seems like a waste of time.
VueJS absolutely adds to the development of complex applications, and takes almost no time to set up.
Webpack... not so much. I've spent days fighting with webpack over nonsense.
Webpack... not so much. I've spent days fighting with webpack over nonsense.
I tried Vue because someone said the Chinese like it since they can use it without npm (great firewall & such), but everyone including Evan You stresses webpack and npm!
I've been successfully rolling it as an SPA without node/npm/webpack so far, but I'm wondering when the other boot is about to drop.
I've been successfully rolling it as an SPA without node/npm/webpack so far, but I'm wondering when the other boot is about to drop.
So why don't you do everything as GET/POST?
Because I was dumb enough to try React when enough people said "Oh, this changes everything!"
Whatever React gave, npm and Babel took right back.
Whatever React gave, npm and Babel took right back.
I'm not sure how trying things makes a person dumb. Either way, that doesn't answer the question of what is stopping you from using the tools you prefer rather than the ones you despise.
I still have to maintain the product, unless I want to go full CADT and re-do it in something else.
GET/POST? Haven't you heard of GraphQL?! ;P
[deleted]
Webpack is a new Grunt, if we talking about configuration.
tkubacki(4)