Ridicule me all you guys want but I still write using just html/css/js and sublime text (no jquery either). And I have written a 30k line project using just that and php.
Being a filthy casual has it's upsides. I can do whatever I want insanely quick. Moving projects from machine to machine is quick as well. Only time I use command line is for git. I do have the advantage of having all my customers on a modern browser. But if that were not the case, only thing extra that I would need is babel. None of what OP mentions is "needed" to create a "modern" web app. Far from it.
Exactly. It seems the less people know about web tech, the more third party stuff the add to a website. And then they wonder why the visitors drop off and hate the sites. Some website got so bad, that they crash mobile browsers due excessive CPU/memory usage. As you mentioned server side generated code with eg PHP and HTML5, CSS3 and JS5+ is in many cases all you need to know.
Lately I've been seeing this as part of the problem in web dev. When you start a new project - let's say something like an employee management system that tracks schedules, locations, reviews, etc. - one of the early things you do is probably grab a framework for the back-end; maybe Laravel or Symfony or Zend - or maybe you roll your own (router, controllers, models, views, whatever). You mentally conceptualize and visualize the entire project in terms of delivering "views" to the browser (something not helped by the inaccurate terminology used in most back-end "MVC" frameworks).
Why don't we see the front-end in the exact same way? I have a list of requirements that the interface needs to accomplish - why don't I use a front-end framework (which can actually be a real MVC framework)? Why do we consider all these things for the back-end, but then write just one or two Javascript files for the front-end and add a few libraries like jQuery and/or Modernizr? Where's the consistency? Why do we just throw all our JS code into a single file? Our contemporaries would ridicule us if we did that with our PHP files.
Up until, like, Thursday, I thought this way as well.
I guarantee my next big project (after a few small practice projects) will place the "views" and "controllers" where they belong, completely within the browser. This is where the user interaction happens, and there's no need for a server round-trip every time something gets clicked. The "model" is the data store (i.e. the back-end server) - all the client needs is an interface to it. The back-end will be nothing more than the "model" layer, though it will necessarily have it's own routing and controllers (after all, business logic still belongs on the server where the user can't mess with it). Access is through a REST API, and it delivers nothing but data and URLs for static/generated assets.
Is this more difficult? Definitely. Requires more tooling on both ends? Absolutely. Lets me properly architect and visualize the entire project from front to back without any inconsistencies in perception? Yes. This is not MVC, this is VC/MC.
How did you manage your js files ? Did you put everything in a single file ? If not, what scheme did you take up on to split the files ?
What about minification and obfuscation of js ? And since you are not using jquery, did you manually set event handlers (onclick, onchange) in the html ?
From my personal experience, I had once did a pretty big JS project without using the ES6, webpack flow. And beyond a point of time, it got pretty much out of control. In hindsight, using classes, require directives would have made life so much easier to understand.
> How did you manage your js files ? Did you put everything in a single file ? If not, what scheme did you take up on to split the files ?
Since I have the benefit of having all my customers' systems on chrome/ff (evergreen variety) I can use latest js features that are stable. So most of my main project (a CMS for schools to manage date sheet, exams, result, attendance, homework, assignments, etc) is divided into features/modules.
There are a few project wide classes (es6) that are all in one file /main.js (about 1000 line file, nothing outrageous). Then every feature can have any number of individual pages (mostly two). So for example attendance has two pages take.php and view.php. Each page with it's own js file, an average of 300-500 lines per page, though a couple js files go as far as 1500.
At the end most pages have about 2 or in some cases 3 js files that are included in the header. It used to be kind of a mess when I wasn't using classes but now it's all pretty much as good as it will get at my current skill level.
> What about minification and obfuscation of js ?
My overall static page load is about 30kb to 50kb on average (excluding api/json calls) so minification is not something that I had to look into but I can easily do it with a babel flag. I mentioned babel in my original comment because some of the site is also exposed to parents that can be from any device/browser. So I use babel to compile (and if I want, minify/obfuscate) some of my code as well.
> And since you are not using jquery, did you manually set event handlers (onclick, onchange) in the html ?
I think even in jquery you would have to set manual event handlers. But I have a `Node.prototype.on = (e, f) => this.addEventListener(n, f);` somewhere in main.js. So setting event handlers is not as verbose but I never needed anything more than that. Not sure what other advantage jquery provides over `node.on('click', e => {})`. Inline event handlers are yuck. My html/js/css are strictly segregated.
I mostly keep my interface simple and focused on one single task so I never needed frameworks like react either. I keep DOM interaction to minimum. Only place where I think something is left to be desired in my work flow is generating DOM nodes from my json api responses. I have it down to as simple as I can but it's still pretty verbose. But I don't want to include and figure out an entire framework just to do this one task that I am not completely satisfied with but isn't that big of a trouble either.
Whew that turned out to be longer than I expected.
Being a filthy casual has it's upsides. I can do whatever I want insanely quick. Moving projects from machine to machine is quick as well. Only time I use command line is for git. I do have the advantage of having all my customers on a modern browser. But if that were not the case, only thing extra that I would need is babel. None of what OP mentions is "needed" to create a "modern" web app. Far from it.