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)
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.
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.
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.
> 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?
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?
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).
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.
I have had a great development experience. The Wagtail core team are very active and helpful.
But now this tooling is out of hand. I threw up my hands and found sanity again in simplicity (my username namesake).
It is like war-games. The only winning move is not to play.Now I deploy apps with no more than 100 lines of JS.
Again, not prescriptive, just my own journey.