6 ms·

And this is exactly why any of my hobby projects that involve JS are done with plain JS, with as few libraries as possible. I might pull in specific libraries,

And this is exactly why any of my hobby projects that involve JS are done with plain JS, with as few libraries as possible. I might pull in specific libraries, but I don't want to pull in a giant framework that will be outdated the next time I decide to work on that particular project.

rectang 6y ago
Another thing I find weird is how bloated static typical site generator tools are. The delivery medium of static HTML is timeless. But the odds that a static site generator with dozens of dependencies will still work N years from now? Grim.
- nanna 6y ago
  'Typically' meaning...? Jekyll? Gatsby?
  - nitrogen 6y ago
    I have a couple of older static sites (one using Jekyll/Octopress, one using Middleman), and if I ever do a bundle update something is guaranteed to break. Not sure if that's the "bloat" the parent comment is talking about though.
    - cutler 6y ago
      I've been using Perl Template::Toolkit since around 2001 and it's even better since version 3 was released. Worth a try. You don't even need to know Perl to make use of it.
  - laurent92 6y ago
    Yes. I was on Jekyll 2 years ago, I don’t think I’ll be able to compile it in two years. It’s already on an old version of Ruby if I remember, if not Bundle or Gulp or... and it’s just a simple website.
  - blacktriangle 6y ago
    I've had this exact issue with my Middleman sites.
- lenkite 6y ago
  They all started off lean and mean. Then after adding feature after feature they become bloated. Then the next lean-and-mean static HTMl generator becomes vogue.
- enriquto 6y ago
  just write html by hand. With html5, implicit and auto-closing tags, it's really not more difficult than markdown. Then your "generator" is simply the cat program, that appends a common header and footer.
- red_trumpet 6y ago
  Bashblog[1] is pretty lean, and doesn't use any dependencies. [1] https://github.com/cfenollosa/bashblog https://github.com/cfenollosa/bashblog
- vitejose 6y ago
  One of the reasons I like Hugo: it's a single executable that will basically work forever. There's no need to update to a newer version if the one you have meets your needs.
- brunoluiz 6y ago
  That is why I've changed to Hugo (from Hexo & Gatsby). It does exactly what is supposed to, it doesn't import any dependencies and it is quite fast. Besides, no runtime is required. I thought about plain HTML, but writing blog articles with it is a bit of a pain. Hugo was quite the right balance.
- tomgp 6y ago
  agreed, but for me the appeal of static site generation is that the input is typically just markdown and some templates so even if a particular generator ceases to be supported it should be trivial to drop in a replacement in whatever the currently fashionable language is.
lenkite 6y ago
A micro-library like https://redom.js.org/ https://redom.js.org/ does make things easier though. I have also given up on mega-frameworks - just too many things to keep in mind as I get older.
- winphone1974 6y ago
  Easier through ignorance seems like cheating IMO. you're basically saying yes things are harder but I just ignore them. How would a newbie decide what's safe to skip?
  - MereInterest 6y ago
    While agree with your conclusion, I don't agree with your argument to reach it. Any software development sits on such a tall and wobbly stack of dependencies that no one human can even understand every layer, let alone build it. For most projects, I don't hand-solder together transistors into the logic layer, write my own bootstrapping compiler out of hex assembly instructions, or directly interface with graphics drivers to display the program's output. That doesn't make these be bad programs or bad projects, just because they are focused on only one part of the program space. My concern isn't in "ignorance" or "cheating", but in spending time to learn a technology or framework that may quickly become obsolete.
- grishka 6y ago
  Here's my "femto-library" for creating DOM dynamically from JS: function ce(tag, attrs={}, children=[]){ var el=document.createElement(tag); for(var attrName in attrs){ el[attrName]=attrs[attrName]; } for(var child of children){ el.appendChild(child); } return el; };
nirui 6y ago
> ... are done with plain JS, with as few libraries as possible ... I was having the same opinion and practice. However, I'm kind regret it as well. Even if you done everything with plain JS, eventually, one day some idea will float into your head such as "Hey... I want to automatically compress the script file/snip", "Hey I wonder if I can polyfill all my script", "Automatically bundle assets?", "Compress assets images?" etc. Then, you start to learn Webpack/Gulp/Grunt (if the last two are still alive), and commit your entire soul to it few minutes later. I think the reason for the messy front-end tech is, the Web itself is messy. You have to consider a lots of things, networking, file management, cache management, cookie, user-side storage, security etc. Some eyes saw the problem and then built a framework to address it, then others discovered some other issues in the framework ... the circle of life. I guess we'll eventually settle down on something when people finally figure out what they want from the Web technology, or when the Web is "dead" (no dramatic changes anymore, like what happened to Desktop Applications today).
- alanbernstein 6y ago
  I have lots of tiny hobby projects. I never want to do any of those things you mentioned. Just a simple page, with the minimum amount of javascript to make it work.
- majewsky 6y ago
  > Hey... I want to automatically compress the script file The trick is to write so little JS that its bandwidth usage does not even register. I'm recently going as far as to include licensing headers and extensive comments in my website JS, see e.g. <https://xyrillian.de/res/chapter-marks.js https://xyrillian.de/res/chapter-marks.js>.
  - MereInterest 6y ago
    I can't find a link at the moment, but there was an article on Hacker News a few years ago defending the use of plain text web pages with minimal styling. The page loaded amazingly fast, rendered well on both desktop and mobile, and had fast interactions with the page. The author had also included the full text of Moby Dick, more content than is ever served in a typical webpage. It was a fun and cheeky demonstration that it isn't the content of a webpage that results in poor performance, but all the frameworks, ad targeting, and client-side compiling of a webpage. (Side rant: I refuse to use the term "client-side rendering", because dang it, "rendering" makes an image. "Client-side rendering" as web developers use the term doesn't actually render anything, but instead compiles the page down to HTML, which is then rendered by the browser.)
d13 6y ago
This should be industry standard practice.

rectang 6y ago

Another thing I find weird is how bloated static typical site generator tools are. The delivery medium of static HTML is timeless. But the odds that a static site generator with dozens of dependencies will still work N years from now? Grim.

nanna 6y ago
'Typically' meaning...? Jekyll? Gatsby?
- nitrogen 6y ago
  I have a couple of older static sites (one using Jekyll/Octopress, one using Middleman), and if I ever do a bundle update something is guaranteed to break. Not sure if that's the "bloat" the parent comment is talking about though.
  - cutler 6y ago
    I've been using Perl Template::Toolkit since around 2001 and it's even better since version 3 was released. Worth a try. You don't even need to know Perl to make use of it.
- laurent92 6y ago
  Yes. I was on Jekyll 2 years ago, I don’t think I’ll be able to compile it in two years. It’s already on an old version of Ruby if I remember, if not Bundle or Gulp or... and it’s just a simple website.
- blacktriangle 6y ago
  I've had this exact issue with my Middleman sites.
lenkite 6y ago
They all started off lean and mean. Then after adding feature after feature they become bloated. Then the next lean-and-mean static HTMl generator becomes vogue.
enriquto 6y ago
just write html by hand. With html5, implicit and auto-closing tags, it's really not more difficult than markdown. Then your "generator" is simply the cat program, that appends a common header and footer.
red_trumpet 6y ago
Bashblog[1] is pretty lean, and doesn't use any dependencies. [1] https://github.com/cfenollosa/bashblog https://github.com/cfenollosa/bashblog
vitejose 6y ago
One of the reasons I like Hugo: it's a single executable that will basically work forever. There's no need to update to a newer version if the one you have meets your needs.
brunoluiz 6y ago
That is why I've changed to Hugo (from Hexo & Gatsby). It does exactly what is supposed to, it doesn't import any dependencies and it is quite fast. Besides, no runtime is required. I thought about plain HTML, but writing blog articles with it is a bit of a pain. Hugo was quite the right balance.
tomgp 6y ago
agreed, but for me the appeal of static site generation is that the input is typically just markdown and some templates so even if a particular generator ceases to be supported it should be trivial to drop in a replacement in whatever the currently fashionable language is.

lenkite 6y ago

A micro-library like https://redom.js.org/ https://redom.js.org/ does make things easier though. I have also given up on mega-frameworks - just too many things to keep in mind as I get older.

winphone1974 6y ago
Easier through ignorance seems like cheating IMO. you're basically saying yes things are harder but I just ignore them. How would a newbie decide what's safe to skip?
- MereInterest 6y ago
  While agree with your conclusion, I don't agree with your argument to reach it. Any software development sits on such a tall and wobbly stack of dependencies that no one human can even understand every layer, let alone build it. For most projects, I don't hand-solder together transistors into the logic layer, write my own bootstrapping compiler out of hex assembly instructions, or directly interface with graphics drivers to display the program's output. That doesn't make these be bad programs or bad projects, just because they are focused on only one part of the program space. My concern isn't in "ignorance" or "cheating", but in spending time to learn a technology or framework that may quickly become obsolete.
grishka 6y ago
Here's my "femto-library" for creating DOM dynamically from JS: function ce(tag, attrs={}, children=[]){ var el=document.createElement(tag); for(var attrName in attrs){ el[attrName]=attrs[attrName]; } for(var child of children){ el.appendChild(child); } return el; };

nirui 6y ago

> ... are done with plain JS, with as few libraries as possible ... I was having the same opinion and practice. However, I'm kind regret it as well. Even if you done everything with plain JS, eventually, one day some idea will float into your head such as "Hey... I want to automatically compress the script file/snip", "Hey I wonder if I can polyfill all my script", "Automatically bundle assets?", "Compress assets images?" etc. Then, you start to learn Webpack/Gulp/Grunt (if the last two are still alive), and commit your entire soul to it few minutes later. I think the reason for the messy front-end tech is, the Web itself is messy. You have to consider a lots of things, networking, file management, cache management, cookie, user-side storage, security etc. Some eyes saw the problem and then built a framework to address it, then others discovered some other issues in the framework ... the circle of life. I guess we'll eventually settle down on something when people finally figure out what they want from the Web technology, or when the Web is "dead" (no dramatic changes anymore, like what happened to Desktop Applications today).

alanbernstein 6y ago
I have lots of tiny hobby projects. I never want to do any of those things you mentioned. Just a simple page, with the minimum amount of javascript to make it work.
majewsky 6y ago
> Hey... I want to automatically compress the script file The trick is to write so little JS that its bandwidth usage does not even register. I'm recently going as far as to include licensing headers and extensive comments in my website JS, see e.g. <https://xyrillian.de/res/chapter-marks.js https://xyrillian.de/res/chapter-marks.js>.
- MereInterest 6y ago
  I can't find a link at the moment, but there was an article on Hacker News a few years ago defending the use of plain text web pages with minimal styling. The page loaded amazingly fast, rendered well on both desktop and mobile, and had fast interactions with the page. The author had also included the full text of Moby Dick, more content than is ever served in a typical webpage. It was a fun and cheeky demonstration that it isn't the content of a webpage that results in poor performance, but all the frameworks, ad targeting, and client-side compiling of a webpage. (Side rant: I refuse to use the term "client-side rendering", because dang it, "rendering" makes an image. "Client-side rendering" as web developers use the term doesn't actually render anything, but instead compiles the page down to HTML, which is then rendered by the browser.)

d13 6y ago

This should be industry standard practice.