I've been developing web apps for many years. Back when I started, Javascript was too limited to build a full app. Instead web apps were entirely server rendered, maybe with some JS sprinkles for mouse-overs (before CSS :hover existed) and other minor effects.
As the balance has shifted toward browser-based front-ends, I have transitioned too and been happy for it. However, one thing irritates me about them: the build process. You see, with managed languages on the server (and .NET in particular), the build process was not a thing I had to worry about.
When doing server-side web apps with Visual Studio (WebForms, MVC), I never had to setup any build process. It was setup and maintained mostly automatically for you under the covers through the GUI solution explorer, which doubled as a file manager. This has negatives, but generally works well. When I was a junior dev I was not even aware of the build configuration/processes, because it just worked so I didn't have to know. (CI tools also used the project files to build and run tests.) Edit: removed extraneous details.
The first "modern" front-end project I did, I setup a build script with gulp to bundle and minify JS/CSS. I went from builds not even being a thought in my head to having to code the entire build process myself. I got it to work, but I was incredulous that it was worth the effort and abandoned it. For a while, I got by on VS plugins which would minify or bundle automatically on save.
Fast forward to today. I have created a bunch of front-end apps using webpack to build. I find a starter project that is close to what I want, then spend some time tweaking it to suit my needs. I've had to do this for most new projects... either because I learn new things or webpack version upgrades or template stops being maintained. It still feels like a waste of time and brain cells to futz with. Especially because my needs are simple: compile to js / css, bundle and minify, link in an index page. Yet I have to deal with the intricacies of webpack and a handful of loaders and plugins to accomplish this. And I still haven't figured out some things related to building multiple (Elm) apps which share common code.
There has got to be a better way. So what am I missing? Is there a tool I can use to make build setups easier? It could be a VS Code extension or different build program (i.e. not webpack) or whatever. Does anyone else have awareness or even care that front-end builds are a pain compared to what else is out there?
Top comments (24)
After doing mobile apps for a year I found web front-end build processes pretty straight forward '_'
Interesting ๐ค
For me it has been the exact opposite experience.
To be fair I tried to go from Android native to react-native with iOS and Android support and not really web front-end
I came from web to react-native.
While I found CRNA/Expo much simpler than the usual web stuff, plain RN with Xcode+fastlane much more complex.
Oh yeah I can definitely see that! Best parts about RN are imo Expo and Storybook.
Getting the setup right between yarn, gradle and whatever XCode uses drove me insane ๐ especially when you depend on multiple packages with native components that all require different Android support library, gradle, and react-native versions.
So yeah I'll definitely concede that the web front-end build process is straight forward compared to react-native's process right now
Ah, I haven't had the pleasure of doing native mobile apps yet.
I hate it too, I currently using Gulp with a ton of gulp scripts, dependencies, we bought an admin template with this build process and can't maintain the code, everything is so difficult for example include source maps, build app for automated tests etc.
Webpack's tooling is currently the only thing that starts my Mac's fan :-(
So true. Running a webpack dev server with incremental rebuilds seems to be very CPU intensive.
Haha! ๐ฅ๐ฅ๐ฅ
I used to think that setup a Webpack config for React project was terrible but I use Next.js or Create React App (without eject to avoid config), for the second you can even use CodeSandbox which is an online editor for CRA, Vue.js, Svelte and Preact and you don't need to configure anything, you create a project and start coding, it will the build for you and you can connect it to GitHub.
There're always ways to avoid that, Angular CLI AFAIK is similar to this idea of not requiring to configure anything, Vue CLI and Nuxt.js (a clon of Next.js for Vue projects) has the same. Also Parcel is an alternative to WebPack with zero configuration.
A lot of tools and frameworks are starting to do this so you don't need to configure anything, except if you want to, but if you're used to let the IDE handle the build for you then you can let a CLI do it as well and avoid configs.
And remember, nobody force you to use moderns frontend frameworks to build an app, you can continue to use .NET, Django, Rails, etc. and make a webapp mostly server side with a sprinkles of JS code for interactivity.
I think this space would be easier if I was using React, since there tons of tooling available for it. However, I use Elm and have no plans to switch. Thanks for the link to Parcel. I found an Elm plugin for it, so I'll investigate that further.
I want to use modern browser-based front ends. (Especially in the .NET space, I have a bitter taste in my mouth from the server-side UI techs.) Having to tinker with the build process has just been the cost of doing business so far. Because this area of dev is so young, mature tooling did not have time to be created yet. But I figured we might have reached the point now where some standardized build processes have been identified and more automated tooling has begun to spring up. So I asked. :)
Thanks again.
Yeah, the community is starting to create more and more tools for non-config builds more based on a convention over configuration philosophy but with the possibility to config a lot if you want, which is awesome if you know what you're doing and want to.
If you're doing many projects (I think that because of your post) using these tools and avoiding config is the best in my opinion, just let you limit by the tool and try to avoid special requirements (if you don't need to of course), because the great about this super configurable tools like Webpack is that in a big long term project you only need to configure it one time, but for a freelance dev or agency where develop many projects is just a waste of time, there is where tools like Parcel or the many frameworks CLIs shine.
BTW, I'm sure Elm has a CLI to avoid any config ๐ค
Elm has command line tools to build/debug/install-packages, but it does not handle bundling or minifying assets.
P.S. Based on your Create React App recommendation, I googled and found Create Elm App. I will have to give that a try too. :-)
Create Elm App is awesome. Worked really well for me.
I think Jest and Create React App really raised the bar on tooling and no config.
It takes a little while to become familiar with webpack and how it relates to es6+ and workflow task automators such as gulp or grunt (my fav is gulp), but it works like a charm once you get it down. Webpack NOW has really great documentation, and it's also a matter of learning through much practical application. Stick with it, it's worth it!
My apprehension is that today's thing is webpack. I learn it inside and out. Then tomorrow it will be something else and the investment is wasted. I guess I am stingy in my tooling investment because they come and go so frequently, especially on the front-end.
Edit: I guess the point I'm dancing around is that Webpack feels too fiddly to be the ultimate solution to front-end builds, so I'm reticent to invest too much into it.
That (fortunately or unfortunately) is the nature of the beast. I personally like that things DO change and that we get to learn new things. Wouldn't it be very boring if we were using the same tools in the same way (just simplifying) every day? The only investment is time, but that kind of investment is usually good. Yes, you should pick and choose wisely. Just determine what your end goals in choosing are. Once you get one thing down, however, it becomes a bit easier to learn new things each time around. Hope this helps!
I totally agree with you!
I've been interested in Elm for some time, and every time I come back to try it out I really enjoy playing around, until I have to actually set up the build/tools/config etc.
I did just try Create Elm App and that definitely helps, but the whole thing with Webpack et al, seems way too brittle. I end up wanting to go back to just learning language syntax or writing little algorithms.
I dunno, maybe Front end, in general, isn't for me.
The techs and popular frameworks are changing so fast in browser land that tooling hasnโt had time to solidify. So everybody stitches together their own custom build process despite the heroic efforts of folks like Parcel and Create Elm App. I lasted approximately 2 hrs with CEA before ejecting and customizing.
Still, Iโd rather be doing web front end than desktop or native front end. Mainly because of Elm... I donโt ever want to have to learn another UI frameworkโs weird abstractions.
But yeah, server side is good too. I like writing APIs.
Yeah I really enjoy Elm, but its sparked my interest in learning Haskell, and the reason I didn't jump into that before was because is less easy to create a web UI front end... however now I don't know if that is really a set back for me haha.
Do you have a boilerplate you like to start with for Elm apps to get you going now? Or do you still mainly try to copy a new one for each new project?
I was using a starter template, but the author since stopped maintaining it. The most recent thing I used was Create Elm App. Big win with that is that it sets up debugging for you. So you can see the state of the model after each message and go back to examine a previous state. I knew it was out there, but I had never used it before.
I did have to modify CEA builds to turn off things I didn't want. For instance, this app will be internal and requires a live API, so it does not make sense to use a service worker / PWA. (I can see the caching resulting in support calls.) There's no configuration to turn it off, so I had to eject and change some build scripts. (I made notes because Future Me will forget what exactly to do.)
I will probably continue to use CEA going forward because it does so many thing right.
I used to hate them too. I used to carefully craft them in far too much time to do what was needed and nothing more.
My latest project uses Create React App, and is powered from Maven using the Maven Frontend Plugin. The backend is a Kotlin project. This works fantastically well. I literally issue "mvn install" and a few minutes later I have the frontend and backend built, all tests executed, and artifacts that are ready to go onto deployment servers.
I actually even build Docker containers for them, but right now only for end to end testing purposes.
If you're building a React application I highly suggest create-react-app ๐
Codekit is a great alternative to hand coded front end build processes.