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.
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.
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.
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).
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.
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?
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.
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.
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.
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.
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.
>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.
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?
> 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.
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.
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?
> 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).
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.
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.
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...
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 `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.
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.
If you're looking for alternatives to Webpack, please also check out JSPM (a good short description might be "preprocessing system + package manager + systemjs"):
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.
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.
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
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.
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.
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.
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.
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.
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'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.
It's a response to the React patent drama. After "everyone" decided they were going to give up on Macbook Pros last year, there was a swell of posts about switching to Linux. Ditto for whenever there's an AWS or Github outage, etc.
Depends on what community you are part of. Vue received a lot of hype within the PHP community (especially the Laravel community) shortly after it launched. I want to say early 2015 is when it started there.
Yeah I think that is a concern for many people around building an app with React and friends. I've heard people complaining on this issue multiple times at work.
mainly its the react fatigue, thats finally tipping them over the edge to try something better. vue seems to have come in at the right time for that. and given the momentum, its possible that vue may supercede react at some point if this keeps up.
I'm getting pretty jaded with the JS ecosystem as a whole. I don't want to have to learn new (effectively throwaway) technologies every few months because, fundamentally, I'm interested in building valuable products, not in learning technologies as an end in itself. Or, in other words, I have better and more interesting things to do.
Also, this endless churning is not how you develop expertise. The way things are at the moment you've just about learned to work with the quirks of one framework and then you have to pick up another one.
It's completely ridiculous, especially when in a lot of cases the benefits of one technology over another similar technology are pretty marginal.
I mean, come on: can you honestly say that Brunch is a quantum leap on from WebPack (or vice versa), or that WebPack is a quantum leap over Gulp (or, again, vice versa)? I don't think so.
By contrast, you become an expert by sticking with things and developing deep understanding. I've therefore reached the point where I'm only interested in the browser APIs and JS libs that are proven, battle-tested, and have stable APIs. I don't want to waste time rewriting code that was working and is now broken just because the previous API version offended the aesthetic sensibilities of some capricious maintainer.
(Sorry, I do tend to get quite grouchy about this stuff.)
These frameworks are not that different from each other. I went from Angular to Vue in an afternoon. Sure, I don't know the internals of Vue, but after working in it for a few days, I'd say I'm fairly competent and spend most of my time building the actual product.
> The way things are at the moment you've just about learned to work with the quirks of one framework and then you have to pick up another one.
Frameworks shouldn't really have quirks, they should ideally just work with a standard API. Of course, it's never that easy, but we're converging on that with custom elements. This is like switching from MySQL to Postgres. It's 90% the same, the edge cases you can figure out and migrate, and you don't really care about how it's implemented.
It's not like you're trying to learn a new keyboard layout.
Webpack is absolutely a quantum leap over Gulp which is just a task runner. Webpack is an asset processing pipeline that completely changes how one approaches js development. Also, webpack's developer tools like webpack-dev-middleware and webpack-hot-middleware are amazing tools that don't have comparable equivalents when you consider their integration into webpack in general.
There's still a lot of work out there for Angular 1.X. If you want to wait for a larger paradigm shift in front end development, I don't think you need to worry.
Also incremental improvements are a thing in lots of fields. Science and math make small amounts of progress, build to a critical mass of new theory, and then a new field or concept can be born.
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.
https://github.com/ericclemmons/terse-webpack
It seems to have presets for sane defaults on the roadmap.
For an eslint-style plugin system I'd recommend webpack-blocks.
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.
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.
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 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.
In return I got a faster build, 20% lighter output and a lot more information (webpack shows size, etc)
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?
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.
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.
- 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.
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.
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.
Incidentally, Office 365 SharePoint is built on React.
https://about.gitlab.com/2016/10/20/why-we-chose-vue/
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.
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.
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.
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.
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?
You didn't ask a question, you jumped to a (wildly inaccurate) conclusion.
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.
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.
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?
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).
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.
It uses webpack with alot of code splitting so instead of 1 big bundle its many small bundles which should help loading times alot.
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.
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.
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.
Wasn't long ago that auto reload on file change was a fancy feature...
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.
Edit: FYI, Laravel not required.
1. https://github.com/JeffreyWay/laravel-mix/tree/master/docs#r...
My `brunch-config.js` is about 30 lines long and everything works as I'd expect.
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'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.
https://rollupjs.org/
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
> 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
Really it can do everything and that's why its so daunting for developers.
https://github.com/vuejs/vueify
https://github.com/vuejs/rollup-plugin-vue
https://github.com/vuejs/vue-cli https://github.com/vuejs-templates
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.
Webpack... not so much. I've spent days fighting with webpack over nonsense.
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.
Whatever React gave, npm and Babel took right back.
Also, this endless churning is not how you develop expertise. The way things are at the moment you've just about learned to work with the quirks of one framework and then you have to pick up another one.
It's completely ridiculous, especially when in a lot of cases the benefits of one technology over another similar technology are pretty marginal.
I mean, come on: can you honestly say that Brunch is a quantum leap on from WebPack (or vice versa), or that WebPack is a quantum leap over Gulp (or, again, vice versa)? I don't think so.
By contrast, you become an expert by sticking with things and developing deep understanding. I've therefore reached the point where I'm only interested in the browser APIs and JS libs that are proven, battle-tested, and have stable APIs. I don't want to waste time rewriting code that was working and is now broken just because the previous API version offended the aesthetic sensibilities of some capricious maintainer.
(Sorry, I do tend to get quite grouchy about this stuff.)
> The way things are at the moment you've just about learned to work with the quirks of one framework and then you have to pick up another one.
Frameworks shouldn't really have quirks, they should ideally just work with a standard API. Of course, it's never that easy, but we're converging on that with custom elements. This is like switching from MySQL to Postgres. It's 90% the same, the edge cases you can figure out and migrate, and you don't really care about how it's implemented.
It's not like you're trying to learn a new keyboard layout.
Webpack is absolutely a quantum leap over Gulp which is just a task runner. Webpack is an asset processing pipeline that completely changes how one approaches js development. Also, webpack's developer tools like webpack-dev-middleware and webpack-hot-middleware are amazing tools that don't have comparable equivalents when you consider their integration into webpack in general.
Also incremental improvements are a thing in lots of fields. Science and math make small amounts of progress, build to a critical mass of new theory, and then a new field or concept can be born.