I know a lot of people can be hostile to the seemingly excessive tooling in web development today, but it's not all bad. Even when I'm writing basically a plain, static site for like a one-off...
I know a lot of people can be hostile to the seemingly excessive tooling in web development today, but it's not all bad. Even when I'm writing basically a plain, static site for like a one-off promo or something, I still have a build chain and separate development and production copies of JavaScript and CSS. While I rarely truly need to use Babel since most of the heavily used new language features have adequate support everywhere, I still like to have all my JS files bundled and minified so that I'm making fewer requests for fewer kb. Also I really prefer to write my CSS in Sass because it's light years more structured and maintainable for me, so that all gets bundled and minified down too. Sure I could have done all of that in plain HTML, JS, and CSS with no tooling, but with just some minimal tooling I get a cleaner, more modular, infinitely more maintainable structure, and fewer, smaller network requests. Sometimes tooling is a good thing, even when it's not strictly needed.
Lots of examples how it is complicated, little explanation on why it is complicated. It's complicated because websites want to be their own "apps", nowadays, and for that you need javascript and...
Lots of examples how it is complicated, little explanation on why it is complicated. It's complicated because websites want to be their own "apps", nowadays, and for that you need javascript and keeping javascript compatible with the average browser is such a monumental hassle you have to automate it with mountains of scripts.
I think it did a pretty decent job of explaining. The article is all about Javascript! It doesn't talk about static html or css at all, except to note how comparatively easy it is. When I last did...
I think it did a pretty decent job of explaining. The article is all about Javascript! It doesn't talk about static html or css at all, except to note how comparatively easy it is.
for that you need javascript and keeping javascript compatible with the average browser is such a monumental hassle you have to automate it with mountains of scripts.
When I last did any serious web dev more than a decade ago, the norm was to use a library like JQuery for cross-browser compatibility and that was it. While the article addresses some of the technical difficulties of Javascript that have motivated this complex set of tooling, I don't think it adequately addresses the toxic mindset of so many web developers.
To generalize a bit: Modern web developers suffer from a pathological fear of missing out. Even with all the issues mentioned in the article, it would be perfectly possible to use one packaging tool, and one framework, and just update those as needed. But the turnover of Javascript frameworks and tooling is far greater than what can be explained by the need for compatibility with web standards and older browsers. You could do that by merely updating old libraries regularly. The need to rewrite everything in a hot new framework every 6 months is far more prevalent in the web dev world than anywhere else. They have no real historical perspective on their work. Bootstrap declared the current version of their framework to be in "long term support" mode before the next major version was even out. And they consider "long term support" to be one year. That's actually insane.
Also, it's totally normal in other programming contexts to not be able to use the newest version of a programming language immediately due to backwards compatibility issues. Many places are still on C++98 or C++03 when C++17 is the newest version and C++20 is right around the corner. Either the entire codebase is written in a significantly outdated version of the language or you have to maintain a different branch that is written in the outdated version. The idea that you must have access features that were introduced in the last year or two or you're screwed would be a joke to many traditional developers, but is accepted as ground truth in web dev.
Another disease of the modern web developer is a pathological fear of Not Invented Here syndrome, combined with a fundamental laziness. The result is leftPad and 100+ dependencies in a minor project.
Obviously I'm generalizing here, but I don't think I'm overexaggerating. The thing to note is that these issues are the results of trying to avoid legitimate issues with traditional software development - then taking the solutions to those problems and jacking them up to 11, causing the solution to become its own problem.
Basically, it's because Javascript is garbage. In order to make it really usable, we need to layer all these frameworks and libraries on top of it. And everyone comes out with their own. And then...
Basically, it's because Javascript is garbage.
In order to make it really usable, we need to layer all these frameworks and libraries on top of it. And everyone comes out with their own. And then we make more frameworks and libraries to layer on top of those.
Most modern frameworks aren't addressing Javascript deficiencies. In fact, the libraries that did such as jQuery are going away because Javascript is sufficient today. fetch() and querySelector()...
Most modern frameworks aren't addressing Javascript deficiencies. In fact, the libraries that did such as jQuery are going away because Javascript is sufficient today. fetch() and querySelector() solved the two biggest problems.
Instead, modern frameworks are addressing shortcomings of other components of the browser like routing, caching, and DOM.
I don't think that JS is garbage, but it's certainly got a number of irritations. Irritation number one is how it handles types. The popularity of Typescript and similar transpiled-to-JS languages...
I don't think that JS is garbage, but it's certainly got a number of irritations. Irritation number one is how it handles types. The popularity of Typescript and similar transpiled-to-JS languages seems to be a good measurement of how much the community dislikes the fluidity of JS's automatic typing and casting.
JS also has a number of features that are sort of half-baked. The class keyword and inheratance-based OOP in general are a pretty good example. The good thing is that everyone knows they are half-baked and so those features are generally ignored. But they're also a pretty easy pitfall for a beginner to fall down in. It also means that 'expert' JS programmers can be flummoxed by completely valid code simply because it's done in a way that they would subconciously avoid doing.
Honestly, the worst part about JS is the community mindset that has everyone chasing whatever is shiny. It makes trying to keep up with the state of the language needlessly difficult, largely because everyone's trying to use features before they are widely available (see: babel, polyfills). Documentation commonly isn't given the amount of attention it needs, codebases can become confusing as standards change, and projects are frequently completely scrapped and/or rewritten.
Honestly, most of my problems with JS is not with the language itself, but how it is used. Node and Electron have made every problem a nail with which people hammer down with JS. The place where JS is most used (and is best suited) is in making dynamic frontends, and that is where I see people making the worst possible UX mistakes - more specifically, changing the way a user expects the interface to work.
A lot of this comes from every graduating class from college needs to pad their resume, so they whip up a project that uses every technology they've read about in a blog. Many of these grow into...
A lot of this comes from every graduating class from college needs to pad their resume, so they whip up a project that uses every technology they've read about in a blog.
Many of these grow into full blown projects, and like gossip, spread through word of mouth, virally.
Most none of them are actually needed. But, developers generally like play with new things, every time. So, more gets added to frameworks, new frameworks used and sometimes just added alongside another framework, new technologies to get used, etc etc etc.
90% of the web today could be done in static HTML, generated once, with minimal JS use. Only less than 1% of the web does this today, though.
There's also the push for "engagement", which really boils down to keeping the user as addicted as possible to the site, rather than just to put out good information.
That still requires tooling. Even a basic Jekyll project requires ruby, probably node and npm, and sass for css compilation. Layer on the template engine and any plugins and you're starting to...
90% of the web today could be done in static HTML, generated once, with minimal JS use.
That still requires tooling. Even a basic Jekyll project requires ruby, probably node and npm, and sass for css compilation. Layer on the template engine and any plugins and you're starting to look at a complex project.
Static websites also require more Javascript use than their server-side brotherin. Any functionality like comments, reviews, or forms need to be installed in client-side code, and probably use an external service (eg. Disqus, Sendgrid, Mailchimp).
But at that point you're just offloading the problem to someone else's server.
No, forms require a server side app to kick the form off. As for comments and reviews, same thing. You can hand-code that pretty easily, to regenerate pages after updating. You don't need massive...
Any functionality like comments, reviews, or forms need to be installed in client-side code
No, forms require a server side app to kick the form off. As for comments and reviews, same thing. You can hand-code that pretty easily, to regenerate pages after updating.
You don't need massive frameworks, when you're doing 90% of the world's websites. Most of the code is dependencies of dependencies, for a single feature.
That's my point. If you have no server component, it means plugging into somebody else's system. And the way you do that is typically through Javascript. That's how Disqus comments are embedded,...
No, forms require a server side app to kick the form off.
That's my point. If you have no server component, it means plugging into somebody else's system. And the way you do that is typically through Javascript. That's how Disqus comments are embedded, for instance.
SSGs are great, but they require more Javascript than a traditional stack; not less.
I really didn't expect this to be a controversial statement. It seems simple enough that if you don't have a server-side language to work with, then you need to implement dynamic functionality on...
I really didn't expect this to be a controversial statement. It seems simple enough that if you don't have a server-side language to work with, then you need to implement dynamic functionality on the client instead. That's pretty logical, isn't it?
Forms are the exception because they can be handled entirely without JS if you don't need any custom client-side validation. You can still work with required, maxlength, and pattern attributes and get pretty far. You do of course need to go through a service like SendGrid.
Other types of interactivity are not as well supported however. The example above of embedding comments is still not possible using post and put. Most functionality will not be. Arguably you could use an iframe, but I think we're cheating a bit if we start just pulling in a dynamic page and claiming it's static.
I feel, that's ok. The www was not built for "interactivity", really. However, HTML5 bridges a lot of those gaps. Or, you could post and put, then rebuild the static page, then use a redirect to...
Other types of interactivity are not as well supported however.
I feel, that's ok. The www was not built for "interactivity", really. However, HTML5 bridges a lot of those gaps.
The example above of embedding comments is still not possible using post and put. Most functionality will not be.
Or, you could post and put, then rebuild the static page, then use a redirect to refresh the page....
A lot of this complication is because the idea of "pushing it all to the client to work" development design. Most of this can be done quite easily on the server side. I know, I've done it.
Hold on now. Your original comment was that: So we're talking about static site generation, aren't we? Jekyll, Hugo, or even hand-written .html files. That's why I've been working under the...
Hold on now. Your original comment was that:
90% of the web today could be done in static HTML, generated once, with minimal JS use.
So we're talking about static site generation, aren't we? Jekyll, Hugo, or even hand-written .html files. That's why I've been working under the assumption of there being no server-side code in this example. If you have PHP, then of course you could build out comments or whatever else. It'd just be a bit clunkier.
And also in another comment you say Wut? Totally depends on what you're doing. My website/blog is entirely JS free, and has been so for many years. Static sites don't necessarily need to have...
Static websites also require more Javascript use than their server-side brotherin.
And also in another comment you say
SSGs are great, but they require more Javascript than a traditional stack; not less.
Wut? Totally depends on what you're doing. My website/blog is entirely JS free, and has been so for many years. Static sites don't necessarily need to have comments or reviews, and forms need not use JS. And when you want these stuff, it is better and more reliable to do it across server-side code than rely on unsafe, privacy-invading javascript from Disqus, Facebook, etc.
No Jekyll (or other non-Node SSG) site requires node nor npm, and Sass is optional. You can put together a static site using merely make, or totally manually.
It is not hard to have the site be static and also run a backend server(s) to deal with dynamic stuff.
Also, that Disqus and stuff require JS is irrelevant. The main problem here is people reimplementing browser features like history or loading pages in Javascript. This is turning WWW into an unusable pile of battery-eating extravagance just to please some devs and/or managers/marketers. Pages that would be equally or more useful as static pages are becoming SPAs, and that's a disservice to many kinds of service, and in general useless to all of them.
Well that's true, but I was responding to the parent's comment that: I took that to mean an SSG with no server-side component. So that means no PHP to call mail() for forms, and no database to...
It is not hard to have the site be static and also run a backend server(s) to deal with dynamic stuff.
Well that's true, but I was responding to the parent's comment that:
90% of the web today could be done in static HTML, generated once, with minimal JS use.
I took that to mean an SSG with no server-side component. So that means no PHP to call mail() for forms, and no database to load comments from. If you want to add any sort of dynamic content then you'll very likely need to rely on JS. (Forms you could probably do without JS by using a service like SendGrid, unless you want client-side validation)
My website/blog is entirely JS free, and has been so for many years.
Mine too, sans analytics. I haven't added comments or other dynamic features though. It's just a plain jane blog so it doesn't need JS yet.
The main problem here is people reimplementing browser features like history or loading pages in Javascript.
Well I think that's more of an SPA thing. I was talking about SSGs as I believe that's what the parent was describing. To be fair though, I mentioned node/npm above which might have suggested there being more to it than that. I only mentioned it because it's quite common for libraries, plugins, and other things to be packaged in npm.
l tried setting up my own website on a CentOS virtual server l got through a friend. It's so incredibly confusing. So many options, nested dependencies and most of all, no foolproof docs. It sort...
l tried setting up my own website on a CentOS virtual server l got through a friend. It's so incredibly confusing. So many options, nested dependencies and most of all, no foolproof docs.
It sort of works now but nginx still is magic to me and l can't get MediaWiki plugins to work for god knows what reason. It just feels so bloated with hardly any guidelines to help you go where you need to.
l've also tried Wordpress but that's too walled up; l prefer simple stuff with maximum customization, but in practice l've found that DIY'ing it is pretty darn hard as a newbie who doesn't know their options.
Gitit has an easier setup. Stuff like MediaWiki is not packaged up really well, setup could be easier but the effort has not been put in to achive that it seems. Gitit has its own server, so you...
Gitit has an easier setup. Stuff like MediaWiki is not packaged up really well, setup could be easier but the effort has not been put in to achive that it seems. Gitit has its own server, so you can just use that before actually publishing your website.
What is your intended use for this website? If you just want to make a simple static website (or a blog with no comment section), that's easy - there are many static site generators that will spit...
What is your intended use for this website? If you just want to make a simple static website (or a blog with no comment section), that's easy - there are many static site generators that will spit out HTML files that you can place in a directory specified by the root directive in your Nginx site file, or you can write the HTML by hand. If you want to build a web application, you could use Nginx as a reverse proxy for Flask, Rails, PHP, etc.
If all you want to do is serve static files, then grab a static site generator, then in your nginx site config add an alias under location / directed to the output of the SSG, and you're done.
If all you want to do is serve static files, then grab a static site generator, then in your nginx site config add an alias under location / directed to the output of the SSG, and you're done.
I know a lot of people can be hostile to the seemingly excessive tooling in web development today, but it's not all bad. Even when I'm writing basically a plain, static site for like a one-off promo or something, I still have a build chain and separate development and production copies of JavaScript and CSS. While I rarely truly need to use Babel since most of the heavily used new language features have adequate support everywhere, I still like to have all my JS files bundled and minified so that I'm making fewer requests for fewer kb. Also I really prefer to write my CSS in Sass because it's light years more structured and maintainable for me, so that all gets bundled and minified down too. Sure I could have done all of that in plain HTML, JS, and CSS with no tooling, but with just some minimal tooling I get a cleaner, more modular, infinitely more maintainable structure, and fewer, smaller network requests. Sometimes tooling is a good thing, even when it's not strictly needed.
Lots of examples how it is complicated, little explanation on why it is complicated. It's complicated because websites want to be their own "apps", nowadays, and for that you need javascript and keeping javascript compatible with the average browser is such a monumental hassle you have to automate it with mountains of scripts.
I think it did a pretty decent job of explaining. The article is all about Javascript! It doesn't talk about static html or css at all, except to note how comparatively easy it is.
When I last did any serious web dev more than a decade ago, the norm was to use a library like JQuery for cross-browser compatibility and that was it. While the article addresses some of the technical difficulties of Javascript that have motivated this complex set of tooling, I don't think it adequately addresses the toxic mindset of so many web developers.
To generalize a bit: Modern web developers suffer from a pathological fear of missing out. Even with all the issues mentioned in the article, it would be perfectly possible to use one packaging tool, and one framework, and just update those as needed. But the turnover of Javascript frameworks and tooling is far greater than what can be explained by the need for compatibility with web standards and older browsers. You could do that by merely updating old libraries regularly. The need to rewrite everything in a hot new framework every 6 months is far more prevalent in the web dev world than anywhere else. They have no real historical perspective on their work. Bootstrap declared the current version of their framework to be in "long term support" mode before the next major version was even out. And they consider "long term support" to be one year. That's actually insane.
Also, it's totally normal in other programming contexts to not be able to use the newest version of a programming language immediately due to backwards compatibility issues. Many places are still on C++98 or C++03 when C++17 is the newest version and C++20 is right around the corner. Either the entire codebase is written in a significantly outdated version of the language or you have to maintain a different branch that is written in the outdated version. The idea that you must have access features that were introduced in the last year or two or you're screwed would be a joke to many traditional developers, but is accepted as ground truth in web dev.
Another disease of the modern web developer is a pathological fear of Not Invented Here syndrome, combined with a fundamental laziness. The result is
leftPadand 100+ dependencies in a minor project.Obviously I'm generalizing here, but I don't think I'm overexaggerating. The thing to note is that these issues are the results of trying to avoid legitimate issues with traditional software development - then taking the solutions to those problems and jacking them up to 11, causing the solution to become its own problem.
Basically, it's because Javascript is garbage.
In order to make it really usable, we need to layer all these frameworks and libraries on top of it. And everyone comes out with their own. And then we make more frameworks and libraries to layer on top of those.
And that doesn't even get into ES6 transpiling.
Most modern frameworks aren't addressing Javascript deficiencies. In fact, the libraries that did such as jQuery are going away because Javascript is sufficient today.
fetch()andquerySelector()solved the two biggest problems.Instead, modern frameworks are addressing shortcomings of other components of the browser like routing, caching, and DOM.
How is JavaScript garbage? Personally, I find it fun to code in, even when it’s just vanilla without any Vue or similar frameworks.
I don't think that JS is garbage, but it's certainly got a number of irritations. Irritation number one is how it handles types. The popularity of Typescript and similar transpiled-to-JS languages seems to be a good measurement of how much the community dislikes the fluidity of JS's automatic typing and casting.
JS also has a number of features that are sort of half-baked. The
classkeyword and inheratance-based OOP in general are a pretty good example. The good thing is that everyone knows they are half-baked and so those features are generally ignored. But they're also a pretty easy pitfall for a beginner to fall down in. It also means that 'expert' JS programmers can be flummoxed by completely valid code simply because it's done in a way that they would subconciously avoid doing.Honestly, the worst part about JS is the community mindset that has everyone chasing whatever is shiny. It makes trying to keep up with the state of the language needlessly difficult, largely because everyone's trying to use features before they are widely available (see: babel, polyfills). Documentation commonly isn't given the amount of attention it needs, codebases can become confusing as standards change, and projects are frequently completely scrapped and/or rewritten.
Honestly, most of my problems with JS is not with the language itself, but how it is used. Node and Electron have made every problem a nail with which people hammer down with JS. The place where JS is most used (and is best suited) is in making dynamic frontends, and that is where I see people making the worst possible UX mistakes - more specifically, changing the way a user expects the interface to work.
A lot of this comes from every graduating class from college needs to pad their resume, so they whip up a project that uses every technology they've read about in a blog.
Many of these grow into full blown projects, and like gossip, spread through word of mouth, virally.
Most none of them are actually needed. But, developers generally like play with new things, every time. So, more gets added to frameworks, new frameworks used and sometimes just added alongside another framework, new technologies to get used, etc etc etc.
90% of the web today could be done in static HTML, generated once, with minimal JS use. Only less than 1% of the web does this today, though.
There's also the push for "engagement", which really boils down to keeping the user as addicted as possible to the site, rather than just to put out good information.
That still requires tooling. Even a basic Jekyll project requires ruby, probably node and npm, and sass for css compilation. Layer on the template engine and any plugins and you're starting to look at a complex project.
Static websites also require more Javascript use than their server-side brotherin. Any functionality like comments, reviews, or forms need to be installed in client-side code, and probably use an external service (eg. Disqus, Sendgrid, Mailchimp).
But at that point you're just offloading the problem to someone else's server.
No, forms require a server side app to kick the form off. As for comments and reviews, same thing. You can hand-code that pretty easily, to regenerate pages after updating.
You don't need massive frameworks, when you're doing 90% of the world's websites. Most of the code is dependencies of dependencies, for a single feature.
That's my point. If you have no server component, it means plugging into somebody else's system. And the way you do that is typically through Javascript. That's how Disqus comments are embedded, for instance.
SSGs are great, but they require more Javascript than a traditional stack; not less.
You can use post and put. No js required. None of my forms use js.
I really didn't expect this to be a controversial statement. It seems simple enough that if you don't have a server-side language to work with, then you need to implement dynamic functionality on the client instead. That's pretty logical, isn't it?
Forms are the exception because they can be handled entirely without JS if you don't need any custom client-side validation. You can still work with
required,maxlength, andpatternattributes and get pretty far. You do of course need to go through a service like SendGrid.Other types of interactivity are not as well supported however. The example above of embedding comments is still not possible using post and put. Most functionality will not be. Arguably you could use an iframe, but I think we're cheating a bit if we start just pulling in a dynamic page and claiming it's static.
I feel, that's ok. The www was not built for "interactivity", really. However, HTML5 bridges a lot of those gaps.
Or, you could post and put, then rebuild the static page, then use a redirect to refresh the page....
A lot of this complication is because the idea of "pushing it all to the client to work" development design. Most of this can be done quite easily on the server side. I know, I've done it.
Hold on now. Your original comment was that:
So we're talking about static site generation, aren't we? Jekyll, Hugo, or even hand-written .html files. That's why I've been working under the assumption of there being no server-side code in this example. If you have PHP, then of course you could build out comments or whatever else. It'd just be a bit clunkier.
And also in another comment you say
Wut? Totally depends on what you're doing. My website/blog is entirely JS free, and has been so for many years. Static sites don't necessarily need to have comments or reviews, and forms need not use JS. And when you want these stuff, it is better and more reliable to do it across server-side code than rely on unsafe, privacy-invading javascript from Disqus, Facebook, etc.
No Jekyll (or other non-Node SSG) site requires node nor npm, and Sass is optional. You can put together a static site using merely make, or totally manually.
It is not hard to have the site be static and also run a backend server(s) to deal with dynamic stuff.
Also, that Disqus and stuff require JS is irrelevant. The main problem here is people reimplementing browser features like history or loading pages in Javascript. This is turning WWW into an unusable pile of battery-eating extravagance just to please some devs and/or managers/marketers. Pages that would be equally or more useful as static pages are becoming SPAs, and that's a disservice to many kinds of service, and in general useless to all of them.
Well that's true, but I was responding to the parent's comment that:
I took that to mean an SSG with no server-side component. So that means no PHP to call
mail()for forms, and no database to load comments from. If you want to add any sort of dynamic content then you'll very likely need to rely on JS. (Forms you could probably do without JS by using a service like SendGrid, unless you want client-side validation)Mine too, sans analytics. I haven't added comments or other dynamic features though. It's just a plain jane blog so it doesn't need JS yet.
Well I think that's more of an SPA thing. I was talking about SSGs as I believe that's what the parent was describing. To be fair though, I mentioned node/npm above which might have suggested there being more to it than that. I only mentioned it because it's quite common for libraries, plugins, and other things to be packaged in npm.
l tried setting up my own website on a CentOS virtual server l got through a friend. It's so incredibly confusing. So many options, nested dependencies and most of all, no foolproof docs.
It sort of works now but nginx still is magic to me and l can't get MediaWiki plugins to work for god knows what reason. It just feels so bloated with hardly any guidelines to help you go where you need to.
l've also tried Wordpress but that's too walled up; l prefer simple stuff with maximum customization, but in practice l've found that DIY'ing it is pretty darn hard as a newbie who doesn't know their options.
Gitit has an easier setup. Stuff like MediaWiki is not packaged up really well, setup could be easier but the effort has not been put in to achive that it seems. Gitit has its own server, so you can just use that before actually publishing your website.
What is your intended use for this website? If you just want to make a simple static website (or a blog with no comment section), that's easy - there are many static site generators that will spit out HTML files that you can place in a directory specified by the
rootdirective in your Nginx site file, or you can write the HTML by hand. If you want to build a web application, you could use Nginx as a reverse proxy for Flask, Rails, PHP, etc.Static probably. Serve public stuff on main page and have a passworded personal wiki subpage accessible anywhere.
If all you want to do is serve static files, then grab a static site generator, then in your nginx site config add an alias under
location /directed to the output of the SSG, and you're done.If you’re just doing a static site, try Netlify for hosting.