Snowpack: Build a web application without a bundler
snowpack.dev
snowpack.dev
These tools aren't the simplest things, but so is everything, everywhere. Complexity needs to exist somewhere, and using an abstraction to hide them is something natural. Do people think we shouldn't use compilers because we 'can' write binary ELF files directly? Same goes to JS.
Here's two excellent articles that go over the history and use cases behind the JS tooling ecosystem:
http://tinselcity.net/whys/packers
https://www.swyx.io/writing/jobs-of-js-build-tools
As a counter-point, there's also valid reasons why a lot of the JS tooling ecosystem is painful to work with:
https://increment.com/development/the-melting-pot-of-javascr...
https://www.swyx.io/writing/js-tooling/
For myself personally, I'm quite happy with the React ecosystem. For the kinds of "desktop-app-in-a-browser" apps I work on, it's fantastic.
(Caveat: I'm a Redux maintainer, so I'm also a bit biased here.)
Death to complexity on the frontend for complexity's sake.
> I wound up using ASP.NET Core Razor Pages (templated pages) and it's been a breath of fresh air - I haven't enjoyed myself this much writing web software in ages because I can get stuff done in very short order.
Okay, so I've never worked in Angular, so I can't really speak (maybe there are Angular killer features that justifies using Angular?), but... If it looks like it'll be simpler in ASP.NET pages, go for it!
Everybody likes lighter pages, if your app is simple * doesn't need to be a heavy Angular SPA, you shouldn't be using them.
I hardly belong anywhere, it sometimes seems.
Either way, I can confirm to OP's findings with Angular. I worked on an Angular project not too long ago and every time I hit Command-S I had to wait 10 seconds before the page would refresh. Manually refreshing wasn't an option, of course, because it was busy compiling. I tried to explain to my client that those 10 seconds were quickly adding up considering what my billable rate was but they didn't seem to mind. It was from Google and that's all they needed to know.
We have a large desktop application that hosts tabs of other react applications and provides windowing features, all built in Electron, that is written in React. we can edit a component within an app and save it and have the UI update with the same state and the new component change in under a second. react native fast refresh is even better because it’s understanding of life cycles and hooks is better but hot reloading within a react app is extremely performant for us. I wonder why you’re having to wait so long?
So for us Java developers it was great. I don't know about Angular 2 and beyond, but I'm sure it has its place.
(I wanted to paste it, but it's too long = 2500 lines)
This attitude is already hurting everyone, and it's only going to get worse. But it's a different thing than the complexity problem.
If I want to dig into "how my angular app works", I can't, because I cannot browse 2500 npm packages on github to find out what they are doing. Even answering the question "does my app actually require this dependency" is completely impractical.
Part of the reason I love Go is because there's no magic. I can look at the definition of a std lib function and it's right there, in plain code, and makes sense.
But despite Go being simpler than Rails (for this reason), I'm not sure that any given Go project is simpler than any given Rails project. The moving parts are more obscure, definitely, but I'm not sure there are more of them or that they're providing more complexity.
Death to remaining in the dark ages for nostalgia's sake.
A lot of my issue with the Javascript-heavy present of "modern" SPA websites is that they have to recreate native browser functionality, which is inevitably slower and worse.
Way too many websites could have the same functionality, in a simpler form, with better performance with a more "traditional" stack. You can even have your API separated front-end and back-end via server-side rendering (by which I mean old-style server-side rendering).
The modern zeitgeist is mostly hype, fad, and novelty.
Our frontend Angular test runs take 25 minutes to run less than 2,000 unit (not integration) tests. That's just nonsense. I don't blame Angular so much as I blame the JS ecosystem. For comparison our backend unit test runs (ASP.NET Core) take 3 minutes to run 6,000 tests.
You can argue we're doing something wrong, but as a company with a a thousand or so devs - reaching out to the most experienced frontend devs we have, their answer is: you've got too many tests, split up your SPA into smaller SPAs. Great, more complexity and dependency management hell.
I can't wait for Rust/WASM to eat Javascript alive. I'm considering writing my next frontend project in Rust.
If a combination of back-end processing with some vanilla javascript, or jquery will get you to market for your first 100-1000 users (which, we know it will because that used to be the only way we could do things, on much less powerful hardware no less) then I say go with that. In the mean time you can work with the stakeholders to put together a strategy for scaling up as demand increases.
I just finished working in the public sector and it's absolutely terrible for this. We had a microservice based event-driven architecture, all on AWS, load balancers everywhere. It was so complicated not a single person knew the entire architecture.
Current number of users: 65
Expected maximum number of users ever: 8000
It's incrediy subjective obviously, but in my 25 years of web dev (full stack) rendering speed has been the number one gripe from users. I've spent thousands of hours optimizing web things. The biggest impact on user perception of speed was the move to Web 2.0 eg JS apps that fetch data with 'ajax' and update the DOM.
If my experience is anything to go by users absolutely prefer client side rendered apps (with SSR, hydration, caching, memoization, optimal data structuring, etc, etc).
No doubt a huge amount of client side JS is garbage, and users would be better served by a server rendered website than a bad client side rendered app, but they'd be even better off still with a good client side rendered site.
This provides fast page loads, with the ability to load additional data without reloading the whole page.
I've written and maintained several jQuery applications and if I'm being honest, I much prefer it over all the tooling we have today. jQuery isn't perfect because nothing is of course, but with a little discipline I never really had any trouble maintaining a jQuery application. In my opinion, all the tooling we have today does is obfuscates me away from my code and actually makes it harder to maintain.
I find that a strange attitude. Complex systems are by definition harder to reason about, and therefore guaranteed to contain more bugs given the same amount of mental effort.
Sometimes complexity is unavoidable, but in general I find myself attracted to simpler systems, and consider that a sign of good engineering rather than the other way around.
> That's what people are complaining about here and they have a right to. It's not the idea that's flawed, it's the ridiculously over complex, constantly breaking implementations like the ones above and most similar tools.
Well, the complexity is because webpack/gulp/grunt are do-everything tools. There are lots of features to assist everyone, and usually if you have some obscure requirements, webpack has an solution.
Yeah, webpack is complex - IMO one shouldn't use webpack just to bundle up JS files. There are opinionated tools like Parcel or CRA(which automatically configures webpack under-the-hood), and those will fit 90% of the users. Only the left 10% which existing opinionated solutions cannot accommodate can fiddle with the webpack config directly.
> Not too mention the low quality of such tools and npm itself requiring one to now be an expert on not only the build chain, but npm and yarn before even starting any project.
Well, do you really think JS has low-quality tools? I really don't see them as low-quality... And you should know npm/yarn before starting a JS project; it's like knowing gcc/clang before starting a C project, or knowing cargo before starting a Rust project.
> The complaints are more than valid when there are tools that do the same job without the unnecessary complexity.
(Assuming you're talking about npm/yarn) If you can do the same job without all the dependencies, you don't have to know package managers. If you want to, you should know the package managers.
As far as webpack, I understand that it's a jack of all trades. But if even trying to replicate a simple bundling config takes many days, then it's a perfect example of a tool that's not only overly complex, but one that doesn't do its own core job well.
Do people struggle a lot with cross-browser issues these days? It isn't like it was back in the day, when basic stuff like the box model worked wildly differently in IE. And almost everyone's on a rolling-release, auto-updated browser, so you don't have to worry about testing on old versions; even big websites like Stack Overflow only support the last couple releases of the most popular browsers: https://meta.stackexchange.com/questions/56161/which-browser...
I still test on multiple browsers, and every once in a while I'll need to fix a bug that only shows up in one browser. But JavaScript frameworks and build tooling don't really help with that, do they? (Am I missing out?)
People will browse your app from ancient mobile phones. Weird smart TVs. play consoles. Chinese browsers you've never heard of but come bundled with some we-something, they will browse your app from PoS, from a DJI smart RC, from a fridge. And from IE6.
And you know what's the best way to mitigate all that mental load? You just start upfront with a framework that was already battle-tested on all these weird browsers.
There are way too many small bugs and incompatibilities like these, and way, way too many browser versions still seeing use by at least a small percentage of users, to worry about them individually, unless you want that to eat up all your time.
So your choice is between "be okay with a broken experience for some users", or "use build tools to compile to a common-ancestor target of near-universally-supported CSS and JS".
I've worked on web pages that use what seems to be a pretty standard Webpack/Babel/PostCSS/etc setup, and they still ran into some issues where layout or behavior was different between browsers. Either because they used a CSS property value or JavaScript API (or API parameter/option) that wasn't available everywhere, or because of more subtle disagreements between browsers about things like where an inline element's containing block is.
Part of the work has to be on the developer. There are certain properties that will screw up positioning when used with flex elements in IE, for example, and knowing what those are and how to avoid those combinations is part of the cost of skillfully using flexbox. The compiler can't always do the work, but we should let it do as much as it can.
1. the most of JS tooling stemming from browser compatibility issues does not mean that the issues still need to exist at the point that the tooling was established - it can take a while for established stuff to be moved out.
2. I think for most sites it isn't a problem, but for me the last 3 years has been work on big SPAs that need to generally also handle IE9 (degrade gracefully). And there is always stuff going on.
Safari never fails to make you question why, and Firefox and Chrome still have enough differences to catch you off-guard from time to time.
Anyone who's had to maintain one of these projects long term without a massive team or inherited an older codebase understands that there are serious churn / depenency hell / code rot and complexity issues here and layering more and more abstractions on top to try and dig ourselves out of the hole we're in might not be working anymore.
anecdotally I got out of JS / frontend mid last year after many many years in it and felt at the time that I was burnt out and had lost my passion for development. Maybe it was just too long for me in one area.
I would argue that it's an absurdly overblown issue. The "costs" are a clear net gain which is why these tools are all but ubiquitous. Developer hype only goes so far, these tools are a proven success across every major tech company with a front-end presence. All this supposed complexity is a holistic improvement over the past, especially because all the same libraries and techniques from 20 years ago and everything in between work exactly the same way today.
> Anyone who's had to maintain one of these projects long term without a massive team or inherited an older codebase understands that there are serious churn / depenency hell / code rot and complexity issues here and layering more and more abstractions on top to try and dig ourselves out of the hole we're in might not be working anymore.
Sounds like literally every piece of corporate software I've worked on that's older than 10 years. 10 year old php app? 15 year old c++ app? 15 year old vb6 app? 15 year old c app? Those are all examples of previous nightmares I have experienced and none of them were any easier to handle than a shitty angular mess. At least the browser is incredibly resilient with regard to failure states... try debugging intermittent crashes in a legacy c++ app preserved in a tacky lacquer of clever templating voodoo; nothing in js land even comes close to my time in the c++ insane asylum.
The problem however is that JS is a perfectly fine programming language by now. Think about it, why are we still stuck with Webpack et al? It's because of inconsistent or missing support for modules / imports, or because of a risk that a JS feature you use does not work on a certain browser. And there's JSX of course.
JS is not assembly.
No. An insanely complex Eclipse based Java product I maintained had hundreds of dependencies (including transitive), from a handful of vendors (> 20). Apparently, an simple JS app[0] can have 40000 packages (from hundreds of vendors).
This is insane.
[0] https://stackoverflow.com/questions/55416657/why-do-i-have-4...
Not really, and not even something that pertains to "really old" browsers.
As a somewhat recent example, in order to implement "SameSite=None" properly, one has to ensure it's _not_ sent to browsers (including recent Safaris and Chromes) which implement it badly. See also: https://www.chromium.org/updates/same-site/incompatible-clie...
- Auto-browser reloading.
- Minification and compiling all JS/CSS into single files.
- Partials for Header/Footer/Menus.
- CSS/JS files versioning (the browser-caching issue).
Sure you can build a static website without all these niceties. But these are a one time investment (gulp+webpack) that you can re-use for your future websites and work.
Yes but designing the right abstraction is an artform, and I suppose that these tools haven't yet found it.
But now this tooling is out of hand. I threw up my hands and found sanity again in simplicity (my username namesake).
* Django
* jquery
* intercoolerjs (https://intercoolerjs.org)
* plain old docker
Now I deploy apps with no more than 100 lines of JS.
Again, not prescriptive, just my own journey.
Putting together your own light-weight system isnt hard if you are familiar with the problems these tools solve, but unless you have a site so simple that it shouldn't use react anyway, you'll want the power and features that these tools can provide (automatic source splitting for lazy-loading code on route changes, sane management of language files for internationalization, extensive linting rules for even non-js things like accessibility features in html / jsx, automatic image optimizatuon, etc).
This complexity is out of hand. The worst is we now use yet more solutions (for example server-side rendering, which now needs its own Node server and it's yet another thing to deploy in addition to your main backend) just to try and dig ourselves out of the hole we dug in the first place. Imagine if we suddenly decided concrete isn't cool anymore and everyone should use duct tape. Given its obvious shortcomings we now waste time trying to make tape work, going as far as making concrete-reinforced duct tape and calling it the best new thing of the day... instead of just using the "uncool" concrete in the first place.
This guy has a point, for 90% of projects, you don't need React (those who tell you otherwise are trying to justify their career and position because from my experience most React/Vue front-end positions at companies are pointless and just add unneeded complexity).
War story time: a client was building a complex financial product (includes real-time automated trading, etc). The backend was finished but we couldn't test it because despit several months months the React front-end still wasn't ready and days were wasted on basic things like a signup form, displaying the 2FA QR code, user onboarding wizard, etc. Let that sink in for a minute: we could successfully decide when to make transactions worth millions of dollars automatically, but dug a hole so deep on the front-end that we couldn't do basic things that even the first iteration of HTML forms could do just fine 20 years ago. The powers that be didn't want to lose face so they still kept at using that trainwreck of a front-end instead of ripping the whole thing out and rebuilding it using HTML forms in a matter of hours. I didn't stick around to see if they ever finished the project.
Let's take the example of London Underground's Wi-Fi. It's only available at platforms, not while the train is travelling between stations. When the train arrives into the station it will stay there around 10 seconds. 5 seconds of those are wasted by the phone finding the network and authenticating to it, which means you've already got only 5 seconds before the train goes away and the connection drops off. During those 5 seconds you have lots of apps in the background (push, e-mail sync, background app refresh, etc) that are all fighting for around 1Mbps of bandwidth.
There's also the issue of failing gracefully. If CSS or image loading fails the browser will still display the bare HTML and the user will still have their content in a consumable format. If JS fails to load in an SPA the page is unusable and often shows just a blank screen. If SPA-initiated requests fail it's up to the developer to handle the exception and offer the user a way to retry instead of just giving up and waiting for a page reload.
Broken images and incorrectly loaded CSS can also break pages and make them unusuable so where do we draw the line?
I do get your point but on the other hand many sites are using JS frameworks for good reason and 5kb is absolutely nothing to improve the user experience. You really can't complain about the size of a 5kb javascript file in this day and age otherwise let's just revert back to HTML 2 or 3 to cater for all edge cases.
Google's logo, one word, 4 colors, is 14kb.
To have a library that gives you a better foundation to build a website on be 5 (actually 3) kb? In what universe is that a bad thing?
> This complexity is out of hand. The worst is we now use yet more solutions (server-side rendering, which now needs its own Node server and it's yet another thing to deploy) just to try and dig ourselves out of the hole we dug in the first place.
No, someone had a project that required SSR and for reasons important to their project wanted to build out that functionality in node. You don't have to use it just because it's out there if you find you don't have compelling reasons to apply it to your project.
Just because it doesn't fit your project doesn't mean it's useless for everyone else. Your 90% of projects aren't other people's 90% of projects.
Websites were SSR'd by default back in the day, the backend (with PHP or whatever you had on there) generates some HTML that the browser displayed. Then we decided that wasn't cool anymore and went through this whole clusterfuck of SPAs to justify cool kids' careers and now we're going back full-circle to a way more complex solution with more moving parts of doing exactly what we implicitly had 2 decades ago because we realised cool kids' careers had negative impacts in terms of page load performance.
> Then we decided that wasn't cool anymore and went through this whole clusterfuck of SPAs to justify cool kids' careers and now we're going back full-circle to a way more complex solution with more moving parts of doing exactly what we implicitly had 2 decades ago because we realised cool kids' careers had negative impacts in terms of page load performance.
I really don't think the author of most of the tooling in the ES based javascript ecosystem are "cool kids trying to justify their careers". If you actually think that, take a look at the github profiles of some of the contributors for many of these repos. There's a ton of smart people working on these tools. They're not chasing trends. Sometimes complex problems require complex solutions. Sometimes they don't. It really depends on your project. Bemoaning the amount of options available seems like a waste of time.
I however stand by my words that most React/Vue/Angular front-end developers in most companies are absolutely unnecessary and are actively detrimental to the project by introducing complexity to justify their position.
Most projects do not have any requirements like real-time UIs that would justify a front-end app and will be just fine with a "boring" backend-rendered UI with some HTML, CSS & forms and will automatically avoid a horde of problems like syncing authentication between your backend & frontend, having to manage a separate build pipeline, server for SSR, etc.
I strongly disagree; most of the projects that I worked on a decade ago that lasted more than a few months ended up with ad-hoc frameworks or conventions implemented in vanilla JS or jQuery that varied wildly in quality and changed frequently through the lifespan of the project. In my experience React/Vue/Angular with their generally well engineered and thought-out principles have resulted in a huge boon for productivity for long term projects in a team environment.
> Most projects do not have any requirements like real-time UIs
Whose "most projects" are we talking about here? Yours?
Go on a job board, search for React/Vue/Your-Favorite-SPA-framework, go to their website and then see if there are any features that would actually justify an SPA.
Some examples: the Airbnb website, the New Reddit, etc.
They have a full wysgi for theming built in, a real time chat app, a video sharing app, multiple messaging platforms, and methods of bundling multiple subreddits together.
They added all this really fast, due to the nature of the platform being an SPA.
I have the same issue at work. Any given feature in isolation could be done simply as a jQuery plugin, but together the only way to make it seamless is an SPA.
They have a good design staff, but there was so many minor decisions made over the years that no knew exactly what was a necessary feature of the UI and what was just fluff.
They needed some real world testing to get a better design.
If we don't adopt a framework we end up building one - increasingly of a patchwork of pieces fitting a bit roughly together.
Sounds like you're blaming good tools instead of bad developers.
Besides, a combo of PHP backend codebase and a jQuery frontend codebase has many more shortcomings than a single React codebase.
I assume you roll your own OS then?
Laravel NGINX VanillaJS/WebComponents (toying with Svelte right now) MariaDB
Fast prototyping, simple deployment, almost no time spent with tooling.
A recent example with too much tooling I had was with Root's bedrock+trellis+sage. They do make working with WordPress management for a developer (a lot less clicking that with normal WP setup). But the frontend setup, webpack, backend, browserify and all of that is so complicated and slow. I was able to set it up on one machine, but failed to git clone the same project on two others. Scripts would be missing, things wouldn't load etc. Nightmare.
But I kept getting mired and "stuck" in how I should architect things, or what framework to use, or this or that. I eventually decided that I wanted it to be a browser-based app of some sort (thus the road of ES6) - but then I started to wonder what tooling to use there. Lots of questions, etc - and I never got that far with it.
I eventually wised up and realized that it didn't matter what I chose - what I needed was the application to work. Who cares about frameworks, requirejs, css frameworks, etc - I just wanted something working. So I stepped back...and decided to chuck all of that away.
I ended up with a basic webpage, with a script tag and the code inside that - nothing fancy, purely procedural, old-school javascript functions, tied to events. Bare bones, basic.
...and I made real progress for the first time.
Basically, by regressing to the relative simplicity of Javascript back from the 1990s, I was able to get my tool finally going, without having to worry about the last two decades of cruft around that language. Now, I could have also done it using Python or anything else, in the same manner - but again, I wanted it to be browser based.
As you note, my own journey, and not something I'd tell anyone else to do (and certainly not something meant for a production environment!) - but for myself, and my need, this fit the bill. I'm still working on it; I figure when I complete it proper-like, I can go back and refactor it to something more respectable. Or maybe not.
After all, if it works, why try to break it? In the end, I want the results from the tool - who cares what it looks like under the hood, so long as it works.
After playing around with some react/vue/express/angular/younameit apps for various clients I am more than happy to escape the dependency hell and write efficient code in pure JS that load basically instantly and doesn't need a build environment in the first place. The last straw for me was spending over a day trying to find the right versions for node and all the packages involved to at least get a "legacy app" I inherited running.
I find that I don't even need jQuery anymore, support for things like closest() or a simple document.querySelector is so good that I save those few kb as well.
I've written some reasonably complex apps this way, but I'd probably have a hard time selling this approach to fellow devs, most I've worked with are very entrenched in <insert favorite framework here> and not particularly keen on doing things differently. I can understand and appreciate that point of view, and will acquiesce to the will of the team, but in the past year or so I've had the luxury of being the sole dev on most of the projects I've worked on so this is what I've done and it's been wonderful.
F5 is my compiler, it requires no additional configuration beyond what's already in the HTML, and it's super fast. I love it! :o)
With regards to tooling I agree it is too complicated. I really wish that everyone would coalesce around a standard set of tools. But it would be the equivalent of cat herding.
I have had a great development experience. The Wagtail core team are very active and helpful.
http://dokku.viewdocs.io/dokku/
Dokku also uses(Heroku) buildpacks, which are becoming standardized:
LiveView is an alternate architecture to intercooler.js but with the same goal. There is a standard JS bundle that goes to the client that opens a websocket to the server. You annotate HTML tags (like intercooler) and then handle the events on the server. This is all abstracted away though so you end up writing a controller that looks a lot like a normal server side rendered page.
> - Anyone who loves tooling-heavy development! This isn’t sarcastic, I promise! By dropping the bundler, you can’t do the magic that Webpack is famous for. Using import to load CSS, Images, and other non-JS resources is non-standard and unsupported in the browser (for now). You may appreciate a dev environment that is true to what standard JavaScript browsers support. Or, you may find this annoying.
---
I like that they make this a point, and I'm very much in the "let's not overload the standards" camp so I appreciate this as a feature, not a bug. This convinces me to give this tool a go!
But they're missing the point, this is a really good idea.
I used to use 1000 NPM packages as a sarcastic example about bad decisions and death by dependency overkill then I installed Angular which pulls in 1100 packages alone. The end user doesn’t care about your framework choice, favorite language, tech stack, or build process. They just know your application is slow, clumsy, and riddled with defects.
It's basically just a static file server that can automatically rewrite bare module specifiers using Node module resolution. It's the minimal transform you can apply to npm-installed JS modules that import dependencies via package name.
Yes, you get a waterfall of loads during development, but I haven't had this slow things down in practice, and once you get to development you can use Rollup to bundle modules, but unlike Webpack, it can bundle to standard module output.
I've rescued several projects where more time was spent on making the lives of the developers "easier" than actually solving the problems of the user. Bike shedding and navel gazing is a huge problem in our industry, even if we don't like to admit it.
- Use better JS (TypeScript) to be sent as ES5 (down to IE6 supoort) without waiting for people to upgrade their browsers to the latest, which is forever.
- Upgrade to latest specified version of libraries without having have to check every site and download the min.js or change the script tag url manually and dependencies are resolved automatically.
- Get to use stuff like stylus which is already far better than CSS 3 syntax and again, no need to wait for people to upgrade their browsers.
- Bundle all JS and CSS as a single file (and place all the other assets like images at a specified location automatically), which can be cached for instant load from second page, unless your frontend code is so fat, a single file becomes too huge for it.
- If your server side is node.js, you get to use a completely same language (TypeScript) for backend and frontend.
Webpack certainly is confusing too. I did a side project with some webpack and es6 stuff. It was kinda fun, but man, front-end development has sucked forever. I remember back in the day having to fight with IE6. Here we are, thirteen fucking years later and shit seems to have gotten only MORE complex.
I look at server-side programming for comparison. PHP for instance certainly is more complex with some of the frameworks you can use now and of course composer. But those are WAY simpler than the shit I had to deal with when coding the front. I just don't understand how things have gotten more complex on the front-end, brutal.
It got me thinking about playing around with WebAssembly for building front-end applications. Maybe that doesn't fit all use-cases and maybe the grass is always greener, but I wonder if programming in sane ecosystem would be the sane thing to do...?
Put me in the camp that if there isn't a use-case slapping me in the face, choking me, and yelling at me to do a SPA then I'll avoid the shit like a plague. I'll just go with server-side render pages and sprinkle in some very basic jQuery as needed. I actually did that for a CRM two years ago and the thing is so damn simple to program in, because JavaScript is only used if it ACTUALLY provides a benefit to the user. There is a site-wide script that is maybe 100 lines of code. Then some page-specific things that load in stuff using RequireJS, but the most complex JS out of those is maybe 300 lines. The vast majority of the site doesn't really use much JavaScript. Just plain old MVC.
As always, please BURN YOUR JAVASCRIPT STICKERS.
I can’t count the number of times the solution to a problem we had was described as ‘just add these lines of magic to your webpack config’.
With web assembly maturing, interacting with this mess is becoming increasingly optional. Also languages like typescript and kotlin that compile to javascript add layers of much needed sanity. IMHO any project not using that is doing it wrong at this point. I'm very aware that this is opinionated and even offensive to some but after 2 decades of "maybe this will fix it" type innovation in the javascript world, I have very little patience left for that. The less I'm exposed to that smelly pile of manure, the better IMHO.
So, my recommendation: avoid this tool and use a sensible compile, verify, test, minify, and package it up style tool chain like all the grown ups do these days. I agree, tools for this are very much a cluster-fuck in terms of complexity, lack of any sane defaults that are actually good enough, usability, and performance but they're better than nothing.
In an ideal world, you'd not have to download hundreds of MB of layers of tools around tools that try to fix and work around each other. But there's no good technical reason to skip using them entirely. There's no sane excuse to skip sanity checks, type checks, static code analysis and running tests (and designing such that you can actually do this in a sane way, which seems to be hard with JS). Skipping that is immature and irresponsible. I don't tolerate it in my own projects and have no patience for self styled full stack js ninjas claiming their code is fine. It's not anywhere near fine.
Also, my guess is JS still predominates as the web language being used by developers, provided that React syntax is included.
What about SASS, minification, etc?
I've touched some vue.js too, but I just hate the direction everything is going. These projects are just insanely complex. Component frameworks may be easier to develop with, but they add so much damn bloat and crazy amounts of tooling. I get frustrated enough with Jekyll and that's just a static content generator.
I really miss the simplicity of plain old jQuery and some backend.
If this direction of simplified web development is something you're interested in, you'll enjoy this post I wrote back when we started this project (and it was called @pika/web): "A Future Without Webpack" - https://www.pika.dev/blog/pika-web-a-future-without-webpack/
Disclaimer: I created Snowpack & Pika (pika.dev).
I think what the guy you're responding to is after is similar to what I'd like to see: a front end that isn't composed of 20 years of hacks layered on top of each other because of poor initial choices.
Luke Jacksonn is someone who's done some interesting work in this space with zero-build-tooling sites: https://perf.link - https://github.com/lukejacksonn/perflink
https://www.pika.dev is built with Babel and TypeScript, so it's not technically "zero-tooling", but we still get almost instant iteration by skipping a "bundle" step during development.
Hopefully with WASM we see the rise of client-side frameworks that bypass all of this bullshit entirely and give us a clean slate to develop on that picks up the best of the 90s low-code projects and makes them cloudworthy. There's no reason why 99% of the UI that most sites need isn't just assembled from a nice list of stock UI widgets.
Disclaimer, am old and miss 90s desktop apps
JS _is_ the native language for browsers. Therefore, it's reasonable to target it.
While it's entirely possible to compile your language interpreter of choice to WASM and run that in a browser, you're now in sort of the reverse position that folks complain about with Electron: adding tons of extra bloat, overhead, and complexity, just to duplicate some other runtime environment into a place it wasn't particularly intended to be used in the first place.
In addition, with most "compile other language to WASM" demos I've seen so far, they end up just drawing things on canvas, thus losing all the accessibility aspects that are built into the DOM already. (Yes, I know WASM has some DOM interop abilities and more coming, but that's not generally what I'm seeing done atm.)
What's _really_ needed is way better UI elements built directly into HTML, but those are sadly lacking.
Beyond that, nothing meaningful is happening. Even the input types defined as part of the HTML5 spec are still barely supported [2], and if browsers can't manage to implement decent date/time/range/color inputs, there's no way of getting more complex components designed and standardized.
Of course, the other aspect of that is, anything that is part of the web API is there forever, which means bugs and mistakes aren't really fixable. So, there's some benefits to having a purely community-driven ecosystem instead.
[0] https://github.com/WICG/virtual-scroller
[1] https://blogs.windows.com/msedgedev/2019/10/15/form-controls...
[2] https://www.smashingmagazine.com/2019/01/html5-input-types/
- Material Design Web Components, https://github.com/material-components/material-components-w...
- Vaadin, https://vaadin.com/components
2. You're not writing WASM by hand, exactly like how you don't write assembly by hand. There's little semantic difference of compiling from <your_language> to WASM versus transpiling from typescript to javascript.
3. Typescript isn't really that new.
We are just saying that we'd appreciate something that removes the need for webpack et al.
I'd personally kill for a much simpler (and faster!) webpack.
> TL;DR - Snowpack removes the need for bundlers (Webpack, Parcel, Rollup) in a traditional application build process by leveraging the ESM syntax you're already writing. Keep using your favorite web frameworks (React, Preact, Vue, Svelte) & build tools (Babel, TypeScript).
A question for you: I see the site mentions using Snowpack with Vue but there's no guide like there is for React. Can you point me at some sort of "getting started" guide, blog post, or example repo for using Snowpack with Vue?
I would use a framework that did the majority of its magic on the back end and emitted either zero code that needs to run on the client or completely gracefully degrades when the client refuses to run untrusted code.
Every day it feels more and more like the web is a tracking framework with the lowest effort content that will keep the cattle clicking than an actual platform that provides real value. Being able to switch off executing remote code but be left with a functioning web experience would go a long way to providing real user privacy, which is, of course, why I have zero hope of it actually happening.
If the hard part of your project is setting it up the tools you've picked are too complex for the problem you're trying to solve.
Sure, but what tooling choice do we have? Webpack is pretty much a standard and is expected almost everywhere, with rollup and parcel used here and there.
And I throw my hands in the air every time. Stuff like React or Vue generators seem to work fine but then I am left confused what do all the files do and why don't I have a stricter control over what gets pulled inside the project.
how often has this panned out for you?
JS though, always has been the exception. I understand what transpiling and bundling and minifying etc. are. But the tooling is somehow... don't know, hard to work with. And sometimes you get errors even in newly generated projects.
It's indeed hard to articulate the problems but that’s because I've only done isolated toe-dipping for a while now, not because I don’t understand something. JS could still use shortcuts during development, a la the Parcel tool, and turn that into an universal approach in all of its ecosystem.
Exactly. I don't think your proficiency as a developer is in question, the issue is that your approach is backwards. You're searching for a reason to justify why you should use these tools, rather than trying to build a piece of software with specific requirements and then determining which tools facilitate that goal.
> JS could still use shortcuts during development, a la the Parcel tool, and turn that into an universal approach in all of its ecosystem
The ecosystem already represents millions of developer hours distilled into "shortcuts" that allow developers to achieve capabilities that are very impractical without those tools. The idea of a "universal approach" in open-source makes no sense, people use the tools that best solve the problems they encounter, there will never be a one-size fits all solution, you have to understand the problem you're facing in order to pick the correct tool for the job.
I realise that and you are correct. I am just wondering: is there a way for me to ascertain if JS ecosystem has calmed down and is more friendly to productive programmer workflow, or is still pretty much the Wild West and everybody does whatever they like and there are not many widely accepted good practices for JS project management?
It does seem however that I should just pick up a project idea from, say, RosettaGIT or TodoMVC, and try and implement them with a few different JS stacks (React / PReact / Vue / Svelte come to mind) and gather my own info.
I would reject the framing that suggests the ecosystem is not geared towards productivity. These frameworks allow developers to be more productive than ever, as I noted in another thread, these tools have been a proven success across every major tech company with a front-end presence, it's not just hype, there are demonstrable results.
> everybody does whatever they like and there are not many widely accepted good practices for JS project management
There are many widely accepted best practices, but thats a huge topic. Use of linters like eslint can ensure hundreds of best practices are enforced in your project, and type systems like flow/typescript are an indisputable boon to long-term software maintenance. A software project with types is always much easier to maintain than one without, and the upfront cost of thinking about your data structures in advance of writing your business logic is the technical debt equivalent of not carrying a month to month balance on your credit cards.
> I should just pick up a project idea from, say, RosettaGIT or TodoMVC, and try and implement them with a few different JS stacks (React / PReact / Vue / Svelte come to mind)
This is a great idea. Everyone has different opinions about these frameworks but they're all productive.
In my personal opinion, React is the best of those options because the JSX code-as-markup paradigm means that your application variables interpolate with your views seamlessly without the added complexity of a system for processing gigantic string templates with custom logic directives and custom template inclusion mechanisms. Svelte has some interesting new ideas with regard to preprocessing the views at build time that are pretty cool, but I still prefer React due to the string template thing I just mentioned. PReact is basically just a slimmer React, not much distinction in terms of the workflow. I find Vue to be the least appealing of the options you mentioned since it has poor TypeScript support and in most implementations relies heavily on string templates, but it is often regarded as the most accessible framework for newcomers. Those are just my personal opinions, I think any of those tools are solid and they all have beginner friendly options like create-react-app to help you get up and running quickly.
I am inclined to agree. I know things have been bad in the past -- that's why I exited JS and gave up my title as a full-stack dev -- but I am still left wondering if things can't get even better. I'll take your word for it that things are better than before because from occasional observations I reached the same conclusion.
> Use of linters like eslint can ensure hundreds of best practices are enforced in your project
Learned something very useful. Thank you!
> and type systems like flow/typescript are an indisputable boon to long-term software maintenance. A software project with types is always much easier to maintain than one without, and the upfront cost of thinking about your data structures in advance of writing your business logic is the technical debt equivalent of not carrying a month to month balance on your credit cards.
You'll never catch me disagreeing. That's why I am learning Rust and OCaml currently. Dynamic languages can be amazing -- Elixir is one example -- but there comes a point where you just need a much stricter compiler because you are otherwise chasing your own tail for weeks. So yeah, I am fully with you here. If I get back to JS it's definitely going to be proxied through TypeScript!
> In my personal opinion, React is the best of those options...
I have no idea for now. I get what you are saying and I also would base my choice on which lib supports TypeScript [better than others]. I just want lagless UIs in the cases where my projects absolutely positively need dynamism in the said UI.
I want something that works excellently even on an iPhone 4 / Galaxy S3 / Nokia 2.1. I am looking for minimal bundle sizes, least extra cruft carried, and speed.
Which JS lib/framework would you recommend? For now I don't intend on having complex UI or complex data bindings. But I'd also like to have to option in the future.
I would go with the minimalist Vue setup. Write static HTML, add Vue as a script tag, and sprinkle in Vue components where you need complex JavaScript. This is the primary use case for which I recommend Vue.
There are widely accepted good practices, but the domains in which they are widely accepted are narrower than “JavaScript development”.
Each major front-end framework is something of a community of its own (often with sub-communities), and there are others.
It's all well documented, so if you need further details, there's nothing magic about these tools.
If you really don't want to be bothered with it, just use create react app, vue cli, or angular cli. Some people aren't that interested tooling, I get it.
If you have the luxury to only care about modern browsers, do you need to bother transpiling? Every modern browser supports ES6 natively.
> and webpack collapses all the require(...) calls into a smaller set of files
Also less of an issue if you're using http/2 or http/3.
Is there a "preview of the future" framework out there that people can use if they want to see what a world looks like that doesn't have to work around old browsers?
In my particular case, my infrastructure team will not, and has no plans on, enabling HTTP/2 in our upstream servers. The joy of application development at scale. You can't get everything you want, unless you control it all. Things are too distributed for me to practically sell the team on HTTP/2.
I'm definitely looking forward to HTTP/3, but I anticipate HTTP/3 having more problems with adoption due to overzealous firewalls and UDP blocking. I expect a longer tail of "I can't use HTTP/3" clients than "I can't use HTTP/2" clients, which means it'll be longer before you can reasonably count on it for performance optimization.
Oh wait. That didn't happen. What is preventing you from using only jQuery and "some" backend?
That's right. Just you.
Try without them with jquery only and you'll hit some walls. You'd basically ending up by rolling your own stuff with something vaguely similar.
Sure you can do static pages all day, but the whole idea is maintaining state and stateful transitions.
My satisfaction as a software dev has increased massively since I've renewed my focus on the backend, and also spent some time with Java and other mature languages.
We still get things badly wrong but at least it's wrong in a way I can understand. I've looked at some new frontend projects and I would have to learn 7 or 8 different abstractions, inside a monorepo, just to understand how to build a simple interface to a collection of APIs.
Fuck that. The churn is too high and you might wonder how people built GUIs at all when you look at a modern web-app codebase.
I've had the exact same thoughts. For a long time, I was a big VueJS fan because of its simplicity and I could build really nice clean and fast apps without a bundler. When your app has few dependencies, bundling is overkill. For some personal projects, I didn't even bundle for production; still, it loaded faster and the user experience felt smoother than the vast majority of web applications that we have today.
Now I can see VueJS is moving towards TypeScript and forced bundling. It's beyond frustrating. It's refreshing to read comments like above because so few people are experienced enough to see it as a problem. There was a period in front end development a bit less than a decade ago when it felt like things where always getting better every year; bundlers were only used for production for some projects and HTTP2 was going to allow us to push scripts to the browser so that we wouldn't even need to bundle for production... The future was bright. Then Webpack came along and it became crazy popular, then suddenly people started bundling during development? WTF! Then CoffeeScript came along, added essentially no value at all but people were crazy about it, then transpiling and bundling during development became completely normal. I never thought I'd live to see the day that people would be debugging machine-mangled code. All the work that had been done before since the invention of the computer was about making machine code more readable for humans so this was a shocking reversal of progress.
Most younger people think that bundling is normal... Always existing kind of thing. They don't realize that bundling and transpilation is a massive hack that was meant to be temporary and really should never have existed.
Very experienced engineers from previous generations invested a lot of time and effort into making fast interpreters for dynamic languages like JavaScript so that people didn't have to wait for code to compile. I remember watching interviews with Google Engineers who worked on V8 thinking to myself how great it was that they were able to get interpreted JavaScript to almost match the performance of compiled languages like Java; that was a huge achievement. Waiting for the code to compile was considered a major problem back then; especially for front end web development. Let's face it, the underlying problems of front end development are trivial, but the ecosystem itself has turned simple problems into highly complex ones.
If you've used programming languages like C/C++ where you have to link static and dynamic libraries together, the value of a fast interpreted language is very clear and JavaScript fits the use case quite well. Front end development was never rocket science though it seems to be getting there.
Now people added a massive, highly complex and poorly thought out bundling and transpilation layer between the efficient browser engine and their web apps which essentially takes away all the value and efficiency that had been thoughtfully and painstakingly added to all the layers underneath since the dawn of time.
Then people start complaining about how bloated and bulky and difficult software development is, but before we can all realize that the answer is to throw out all the unnecessary crap that was added on top, some genius will come along out of nowhere with hot new technology which will add even more crap on top and which gives the illusion of solving the problems that people were complaining about but it will in fact cause new, even worse problems... and the cycle of bloat and disappointment will continue.
But at least we will all have more jobs... For a while.
I swear if this industry gets any more retarded, they'll be able to replace us with monkeys. Some genius with an MBA will figure out that same productivity with lower costs = higher profits.
Vue.js using TypeScript doesn't mean that you'll have to. You can continue to ignore it and enjoy using plain old JavaScript (albeit with more informative feedback in your IDE).
Also, you'll continue to be able to include Vue.js with a <SCRIPT> tag, as easily as you did jQuery.
This is helpful if you want to get some reassurance right from the source: https://www.youtube.com/watch?v=WLpLYhnGqPA
Really, setting up and fixing js tooling breakage often take more time than actual development for smaller projects
Also if your needs are simple you can just write a cgi script (provided you don't need too many RPS.)
Snowpack is for bundling ES modules to build web applications. Nothing mentioned in your comments works to build a client-side web application. If this your comment was some sly remark, it's totally lost on me.
Also, what's RPS?
It is an endless loop.
The first dot-com bubble resource wastefulness was spending so much money on networking gear. Every one had oversized expensive Cisco gear.
This dot-com bubble resource wastefulness is so many hundreds of thousands of engineering hours devoted to mega super over engineered Javascript solutions.
Hey now, let's not discount the rise and fall of NoSQL, reinventing of data analysis except using python and spark cause SQL is too boring, or discovering linear regressions using a fleet of GPUs under the banner of Machine Learning!
It'll be nice when people get back to solving real business problems.
No one's bragging about it, probably everyone regrets it, and most companies will never practically be able to get off it (because, when your data is an unstructured mess it's a huge project to try and figure out how to get to structure, not to mention maintaining consistency during the migration. And you have that home-grown "relational" layer someone wrote for Mongo when they realised that they really did have relational data after all, and which is now coupled to everything...)
(If you thought I was describing the primary database at my day job, well...)
The post-IPO success of Mongodb Inc, and Amazon's recent roll out of their own compatible hosted solution makes me suspect not, though.
jquery-era code solved this by just putting the dependencies in the README of a project (e.g. "this project requires jQuery and jQuery UI version 3! load them before loading this script!"). It worked, but it was error prone and manual.
More recent code has solved it by writing code that used abstract specifiers, like require('jquery'), which meant that you needed to use a complicated and often hyperconfigurable bundler to run in the browser (because the browser can't go searching the filesystem to figure out where the code for the 'jquery' package is)
With ES modules we're almost there, browsers can import files now, but they still need a bit of additional info to tell them how to resolve underspecified modules like 'jquery' (as opposed to './utils.js' which they can handle with no problem). You can write your code with fully specified imports, but the difficulty is that that code doesn't travel well, e.g. if you write `import '../node_modules/jquery/jquery.js'` that won't work if someone uses your package as a library, because jquery.js will actually be at '../jquery/jquery.js' because your package lives in the node_modules directory.
because literally just putting them in a folder somehow became insufficient for any number of reasons, some of which seem to have to do with JS's lack of an include() function like every other interpreted language has had since forever
like, how about i don't need 20,000 dependancies, and just use an application stack that includes normal things like trimming a string
This has been solved by ES Modules, which is already in all major browsers. Only IE is lagging behind (but there are polyfills).
By writing all code from scratch so that it doesn’t require any dependence’s from aging frameworks.
If everyone wrote their own kits then the web would be a more of a mature place.
Downvoted without any reasons? The web once before didn’t rely on frameworks.
PHPNuke wasn’t a framework.
PHPBB wasn’t a framework.
E107 wasn’t a framework.
If you wanted something. you coded it yourself.
/shrug
maybe it’s just me that feels the web is now polluted with Mb’s of wasted code. And even now it’s seen as bad practise not to use framework.
I'm a core contributor on Rollup. Rollup is surging, and we've been seeing a ton of interest and new contributors. We're doing some awesome things to improve it, and if you'd like to help advance ES Modules and tooling, we'd love your help.
It's almost like comparing jQuery to web components, maybe you can achieve similar things to both, but one is a feature with native browser support.