DEV Community

Cover image for I hate front-end build processes
Kasey Speakman
Kasey Speakman

Posted on

I hate front-end build processes

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)

Collapse
 
kayis profile image
K

After doing mobile apps for a year I found web front-end build processes pretty straight forward '_'

Collapse
 
danielw profile image
Daniel Waller (he/him)

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

Collapse
 
kayis profile image
K

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.

Thread Thread
 
danielw profile image
Daniel Waller (he/him)

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

Collapse
 
kspeakman profile image
Kasey Speakman

Ah, I haven't had the pleasure of doing native mobile apps yet.

Collapse
 
blouzada profile image
Bruno Louzada

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.

Collapse
 
rhymes profile image
rhymes

Webpack's tooling is currently the only thing that starts my Mac's fan :-(

Collapse
 
andrewgrinko_95 profile image
Andrew

So true. Running a webpack dev server with incremental rebuilds seems to be very CPU intensive.

Collapse
 
kspeakman profile image
Kasey Speakman

Haha! ๐Ÿ”ฅ๐Ÿ”ฅ๐Ÿ”ฅ

Collapse
 
sergiodxa profile image
Sergio Daniel Xalambrรญ

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.

Collapse
 
kspeakman profile image
Kasey Speakman • Edited

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.

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 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.

Collapse
 
sergiodxa profile image
Sergio Daniel Xalambrรญ

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 ๐Ÿค”

Thread Thread
 
kspeakman profile image
Kasey Speakman • Edited

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. :-)

Thread Thread
 
gillchristian profile image
Christian Gill

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.

Collapse
 
letsbsocial1 profile image
Maria Campbell

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!

Collapse
 
kspeakman profile image
Kasey Speakman • Edited

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.

Collapse
 
letsbsocial1 profile image
Maria Campbell

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!

Collapse
 
_collinrea profile image
Collin Rea

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.

Collapse
 
kspeakman profile image
Kasey Speakman

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.

Collapse
 
_collinrea profile image
Collin Rea

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?

Thread Thread
 
kspeakman profile image
Kasey Speakman

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.

Collapse
 
grahamcox82 profile image
Graham Cox

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.

Collapse
 
clickclickonsal profile image
Sal Hernandez

If you're building a React application I highly suggest create-react-app ๐Ÿ˜„

Collapse
 
selfagency profile image
Daniel Sieradski

Codekit is a great alternative to hand coded front end build processes.