8 ms·

I get it, I’m glad it exists, it’s Neat, and congrats, but it’s also amusing to me that we’ve reached the point of JS tooling where we’re making frameworks to d

I get it, I’m glad it exists, it’s Neat, and congrats, but it’s also amusing to me that we’ve reached the point of JS tooling where we’re making frameworks to deal with frameworks, build tool frameworks a few levels deep, etc. It just seems like so much…stuff. And now we have stuff to help us use less stuff, but it’s still stuff in itself. Nothing is stopping anyone from opening notepad and writing HTML with inline style, then using FileZilla to FTP/SCP that to a server (probably a VPS these days) somewhere, or publish it on GitHub/GitLab Pages. I remember a time when people here would cite http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ a lot. Modern browser APIs can do more than ever. I wonder if there’s a more recently-updated equivalent about how one might not need node tooling at all to build a static site.

varrock 5y ago
I felt this way when approaching my personal site. I was falling into the Gatsby trap and then realized all I needed were HTML, CSS, and a few JavaScript files. I think you see over-engineered solutions as a result of career driven development and the hype around these libraries/frameworks on forums/social media.
- mro_name 5y ago
  have a link? I even do similar for a microblog: https://demo.mro.name/shaarligo https://demo.mro.name/shaarligo - try without JS and look at the source (not the DOM).
- pjmlp 5y ago
  My personal website is still based on PHP, after using XML/XSLT for a short while, I rewrote it in PHP 5 shortly after it became available. While at work, it has been mostly Java JEE/ASP.NET since they exist. When I play around with WebGL, it is all JavaScript modules and script tags, nothing else. No babel, no webpack, no npm, nothing, just browser standard capabilities. Fully agree with your point of view.
  - bildung 5y ago
    The irritating thing is that this is often possible even with modern JS. I shipped a rather complex app (though still essentially CRUD that's used internally) this winter that is Vue 3 based. It's just the Vue library itself plus the app logic, directly included using script tags. No other libraries for Vue, no build steps and so on. It just feels great that I could just immediately start fixing things on any computer should an issue pop up next year or so, without worrying about dependencies or some build step being broken etc.
    - pjmlp 5y ago
      Yeah, I really share the sentiment. I guess younger generations get taught the cargo cult ways of SPAs, and aren't able to realise how much simpler it can be done, specially be letting the browser do the work, instead of replicating it on a dynamic language.
    - mvolfik 5y ago
      Just from what I've heard about Deno - isn't this exactly what they are aiming for? Bring Node/JS back closer to the browsers and make use of ES modules etc?
- nicbou 5y ago
  This plus a CMS. Writing is a separate activity for me. I also like that it handles tags, metadata and pagination for me. Templating and thumbnail generation is also nice.
- csomar 5y ago
  Problems start when you need to change the HTML structure, the CSS file name, or having a paginated list of your blog. If you do publish a lot, you'll need some sort of CMS. These frameworks/libraries are trying to replace WordPress, because WordPress is also a mess to work with.
  - krageon 5y ago
    > you'll need some sort of CMS. You will not need a CMS unless you publish multiple articles per day (and even then...). That's far beyond anything the preceding posts were talking about, so it's not really relevant.
    - mvolfik 5y ago
      or unless you build a site for somebody for whom editing Markdown files is too much
- tomxor 5y ago
  I'm also making my blog in plain html/css/js with the goal of making it as minimal as possible - in fact the JS wouldn't exist if it wasn't for the fact that it includes some running code examples about demoscene stuff. Except for my procrastination, it's a real pleasure to write this way, no frameworks, no libraries, no build systems with 10k dependencies, no preprocessors for content - just write plain HTML and be done with it, it's always forward compatible, you always have all HTML features and don't have to worry about some preprocessors capability... If I ever have a genuine need for some kind of build process, it will be a self contained script, I'm fed up with the fatigue of the churn of the web tooling world - i'll stuck to a script that will still run in 10 years. I did make one choice to alleviate the tediousness of writing tags: 'white-space: pre-wrap', which allows you to avoid html tags for basic stuff like paragraphs. Also using fixed width font and ch units since it's mostly a coding blog so this fits well and allows ascii diagrams without extra work... authoring feels like mostly writing an old skool text file with some nice HTML/CSS upgrades.
awestroke 5y ago
Imperative UI sucks. There is a very good reason everyone is using declarative UI frameworks these days
- eyelidlessness 5y ago
  And not just because they’re declarative. I’m currently working in an ecosystem of ~decade old JS projects. The imperative DOM stuff is of course a hassle, but the data flow is (predictably) all over the place. It takes a lot more discipline to keep data flow reasonable in an imperative UI. Modern declarative frameworks are generally opinionated about data flow (sometimes that’s their only opinion!).
- austincheney 5y ago
  Because they are afraid of the DOM and yell at each other about code style? This is common, but it’s still very junior thinking. The best way to minimize tech debt is to supply the most direct solution to a given problem and refactor along the way to bring similar solutions together into a single delivery. Decoration in the code is not that.
  - awestroke 5y ago
    I am very familiar with the DOM and have no problem using the DOM apis. You seem to have no experience writing complex Web apps, and seem to give little thought to maintainability. I'd never hire you.
    - austincheney 5y ago
      Complexity is bad. I prefer to write simple web apps. Less is more. > I'd never hire you. You probably couldn’t afford me.
mro_name 5y ago
> Nothing is stopping anyone from opening notepad and writing HTML with inline style, then using FileZilla to FTP/SCP that to a server I think that's exactly what 'computer literacy' should enable laypersons to do. And we as a profession should be teaching that and developing assistive tools (like htmltidy) rather than intrusive ones (like hugo or worse wordpress. Both or nice and helpful but intrusive nevertheless). Kids should learn this in grade 6 or so. Be it in school or elsewhere. Before they post pictures on inhumane and ignorant advertising platforms they should know that they can do otherwise.
SebastianKra 5y ago
In your argument, you could replace HTML/CSS with Assembler and JS/React/whatever with C and everything that came after. The productivity gained from these Tools is worth it, even if some use cases could be solved without it.
- hnlmorg 5y ago
  That's not really fair. A lot of static sites simply don't need JS at all but they're built with it because it's deemed "best practice". My latest website, for example, has zero Javascript in it. So much content is published in Github READMEs (typically markdown) and while Github itself will have Javascript elements, it does demonstrate that you don't need Javascript heavy sites to publish content. I honestly think half the time the front end best practices are based around what's more intellectually interesting for developers rather than what is genuinely a better website.
  - csomar 5y ago
    You can use NextJS to build a fully static website with no JavaScript at the initial loading. There are tons of libraries (I think around 300Mb) to compile your site, but if you do optimizations right, the final website should be as lightweight as you expect it to be. What you get? Routing, instant refresh, image optimization, and code optimization (your CSS could be smaller if you minify it).
    - FelipeCortez 5y ago
      Hmm, I think 300mb is a lot...
- mrmonkeyman 5y ago
  If by "productivity" you mean "short term financial gain through leveraging the influx of cheap labour produced by codemonkey farms", then yeah, sure.
- pjmlp 5y ago
  Completly unrelated, a page editor that writes pages in a WYSIWYG using only HTML and CSS, Dreamweaver style, can't be compared with using Assembly.
mproud 5y ago
I’m all for not having dependency hell and a million frameworks. I just want some UI controls like sortables lists, tables and not have to type everything out.
nicbou 5y ago
If I'm writing frontend code alone, I do it by hand. In a team, these heavy tools become important to keep some sort of cohesion. Even then, I'm not entirely sure. Nonetheless I had a good cycle the other day when I had to pull 400 MB of Javascript to build a single static page.
- ehnto 5y ago
  I advocate for frameworks in almost all team projects, the tools act as a set of idioms and best-practices your team should know and use.
strokirk 5y ago
The exakt same thing happens in the backend. Kubernetes, docker, procfiles, apt, yum, various frameworks and languages...
ehnto 5y ago
I think part of the issues is that the line between enterprise tooling and smaller site tooling has disappeared. Even people building personal blogs will be inclined to use enterprise tooling, and take on all of the overhead of tool-chains and configuration.
have_faith 5y ago
There is an ebb and flow in the JS ecosystem. First we get a framework. That framework is missing some key functionality or features so we get plugins and eventually a meta-framework standardising the new behaviour and maybe introducing a slightly new paradigm. That meta framework gets unwieldy and we get a ground up rewrite (new framework) that trims the fat and uses the new evolved features as first class concepts. This is exhausting only because of external and internal pressures to "keep up". I don't see anything inherently wrong with the evolution of ideas and concepts being explored in breadth and depth. Writing and publishing a new JS framework has a very low barrier which is a huge positive that I rarely see extolled compared to complaining that the ecosystem needs to constrain itself.
- Fractal_HQ 5y ago
  Svelte has everything I need to build websites and apps. The performance, bundle size, and DX combo is unparalleled. All vanilla JS libs are plug-and-play. Building production-ready apps is incredibly fast, and done with less code than any other framework. Svelte's compiler-first approach really fixes all of my problems with the JS ecosystem. Compile-to-JS langs aren't new, but learning a whole new language has non-0 overhead. HTML, CSS, and JS/TS in a .svelte file is awesome, and the syntactic sugar makes the ugly parts of JS (like state management and reactivity) extremely trivial to implement. The first class support for Vanilla JS & Typscript is brilliant. Vite and ESBuild are incredibly fast and hassle free. The water has never felt nicer for me as a web dev!
  - have_faith 5y ago
    I like Svelte a lot but haven't dived in deep yet. I'm currently waiting for SvelteKit to reach 1.0. What does your general setup look like for something relatively large and complex?
    - Fractal_HQ 5y ago
      I use Routify for everything- the ecosystem of tools from it's creator Jake already takes care of everything Sveltekit aims to solve. I have Starter Templates with everything set up the way I usually like it if you want to check them out- SvelteKit starter template: https://github.com/FractalHQ/frackit https://github.com/FractalHQ/frackit Routify starter template: https://github.com/FractalHQ/fractify https://github.com/FractalHQ/fractify
diveanon 5y ago
Not everyone is building single page static html sites.
- ehnto 5y ago
  I think the weird weighting goes in the other direction though, more people are over-encumbered with tools they didn't need.
austincheney 5y ago
The moment you don’t use the maximum number of tools possible or write any line of code that doesn’t call some framework method people will harass you about NIH. I see it nearly everyday online and used to see it at least monthly in the real world at work. If you can fix that problem all this excess tooling stupidity will largely fix itself.
- matthuggins 5y ago
  NIH?
  - scbrg 5y ago
    https://en.wikipedia.org/wiki/Not_invented_here https://en.wikipedia.org/wiki/Not_invented_here
dfinninger 5y ago
I don’t do a lot of front end dev. Just some personal projects here and there and I usually just slap Bootstrap on it to make things look reasonable. I had to do a bit for work and man, when I started actually reading the docs I was surprised to find things like form validation [1] out of the box! There were a few others that I forget now, but I was pleasantly surprised at how much I _didn’t_ have to do. I wound up needing no extra JavaScript. [1] https://developer.mozilla.org/en-US/docs/Learn/Forms/HTML5_input_types https://developer.mozilla.org/en-US/docs/Learn/Forms/HTML5_i...
pietrovismara 5y ago
> Nothing is stopping anyone from opening notepad and writing HTML with inline style, then using FileZilla to FTP/SCP that to a server (probably a VPS these days) somewhere, or publish it on GitHub/GitLab Pages Sure. Then try to write a highly complex e-commerce frontend app with this approach and tell me how does it work out. If notepad + HTML is enough tooling for your web development, you are not a potential user of such a framework. Good news then, you can just ignore it!

varrock 5y ago

I felt this way when approaching my personal site. I was falling into the Gatsby trap and then realized all I needed were HTML, CSS, and a few JavaScript files. I think you see over-engineered solutions as a result of career driven development and the hype around these libraries/frameworks on forums/social media.

mro_name 5y ago
have a link? I even do similar for a microblog: https://demo.mro.name/shaarligo https://demo.mro.name/shaarligo - try without JS and look at the source (not the DOM).
pjmlp 5y ago
My personal website is still based on PHP, after using XML/XSLT for a short while, I rewrote it in PHP 5 shortly after it became available. While at work, it has been mostly Java JEE/ASP.NET since they exist. When I play around with WebGL, it is all JavaScript modules and script tags, nothing else. No babel, no webpack, no npm, nothing, just browser standard capabilities. Fully agree with your point of view.
- bildung 5y ago
  The irritating thing is that this is often possible even with modern JS. I shipped a rather complex app (though still essentially CRUD that's used internally) this winter that is Vue 3 based. It's just the Vue library itself plus the app logic, directly included using script tags. No other libraries for Vue, no build steps and so on. It just feels great that I could just immediately start fixing things on any computer should an issue pop up next year or so, without worrying about dependencies or some build step being broken etc.
  - pjmlp 5y ago
    Yeah, I really share the sentiment. I guess younger generations get taught the cargo cult ways of SPAs, and aren't able to realise how much simpler it can be done, specially be letting the browser do the work, instead of replicating it on a dynamic language.
  - mvolfik 5y ago
    Just from what I've heard about Deno - isn't this exactly what they are aiming for? Bring Node/JS back closer to the browsers and make use of ES modules etc?
nicbou 5y ago
This plus a CMS. Writing is a separate activity for me. I also like that it handles tags, metadata and pagination for me. Templating and thumbnail generation is also nice.
csomar 5y ago
Problems start when you need to change the HTML structure, the CSS file name, or having a paginated list of your blog. If you do publish a lot, you'll need some sort of CMS. These frameworks/libraries are trying to replace WordPress, because WordPress is also a mess to work with.
- krageon 5y ago
  > you'll need some sort of CMS. You will not need a CMS unless you publish multiple articles per day (and even then...). That's far beyond anything the preceding posts were talking about, so it's not really relevant.
  - mvolfik 5y ago
    or unless you build a site for somebody for whom editing Markdown files is too much
tomxor 5y ago
I'm also making my blog in plain html/css/js with the goal of making it as minimal as possible - in fact the JS wouldn't exist if it wasn't for the fact that it includes some running code examples about demoscene stuff. Except for my procrastination, it's a real pleasure to write this way, no frameworks, no libraries, no build systems with 10k dependencies, no preprocessors for content - just write plain HTML and be done with it, it's always forward compatible, you always have all HTML features and don't have to worry about some preprocessors capability... If I ever have a genuine need for some kind of build process, it will be a self contained script, I'm fed up with the fatigue of the churn of the web tooling world - i'll stuck to a script that will still run in 10 years. I did make one choice to alleviate the tediousness of writing tags: 'white-space: pre-wrap', which allows you to avoid html tags for basic stuff like paragraphs. Also using fixed width font and ch units since it's mostly a coding blog so this fits well and allows ascii diagrams without extra work... authoring feels like mostly writing an old skool text file with some nice HTML/CSS upgrades.

awestroke 5y ago

Imperative UI sucks. There is a very good reason everyone is using declarative UI frameworks these days

eyelidlessness 5y ago
And not just because they’re declarative. I’m currently working in an ecosystem of ~decade old JS projects. The imperative DOM stuff is of course a hassle, but the data flow is (predictably) all over the place. It takes a lot more discipline to keep data flow reasonable in an imperative UI. Modern declarative frameworks are generally opinionated about data flow (sometimes that’s their only opinion!).
austincheney 5y ago
Because they are afraid of the DOM and yell at each other about code style? This is common, but it’s still very junior thinking. The best way to minimize tech debt is to supply the most direct solution to a given problem and refactor along the way to bring similar solutions together into a single delivery. Decoration in the code is not that.
- awestroke 5y ago
  I am very familiar with the DOM and have no problem using the DOM apis. You seem to have no experience writing complex Web apps, and seem to give little thought to maintainability. I'd never hire you.
  - austincheney 5y ago
    Complexity is bad. I prefer to write simple web apps. Less is more. > I'd never hire you. You probably couldn’t afford me.

mro_name 5y ago

> Nothing is stopping anyone from opening notepad and writing HTML with inline style, then using FileZilla to FTP/SCP that to a server I think that's exactly what 'computer literacy' should enable laypersons to do. And we as a profession should be teaching that and developing assistive tools (like htmltidy) rather than intrusive ones (like hugo or worse wordpress. Both or nice and helpful but intrusive nevertheless). Kids should learn this in grade 6 or so. Be it in school or elsewhere. Before they post pictures on inhumane and ignorant advertising platforms they should know that they can do otherwise.

SebastianKra 5y ago

In your argument, you could replace HTML/CSS with Assembler and JS/React/whatever with C and everything that came after. The productivity gained from these Tools is worth it, even if some use cases could be solved without it.

hnlmorg 5y ago
That's not really fair. A lot of static sites simply don't need JS at all but they're built with it because it's deemed "best practice". My latest website, for example, has zero Javascript in it. So much content is published in Github READMEs (typically markdown) and while Github itself will have Javascript elements, it does demonstrate that you don't need Javascript heavy sites to publish content. I honestly think half the time the front end best practices are based around what's more intellectually interesting for developers rather than what is genuinely a better website.
- csomar 5y ago
  You can use NextJS to build a fully static website with no JavaScript at the initial loading. There are tons of libraries (I think around 300Mb) to compile your site, but if you do optimizations right, the final website should be as lightweight as you expect it to be. What you get? Routing, instant refresh, image optimization, and code optimization (your CSS could be smaller if you minify it).
  - FelipeCortez 5y ago
    Hmm, I think 300mb is a lot...
mrmonkeyman 5y ago
If by "productivity" you mean "short term financial gain through leveraging the influx of cheap labour produced by codemonkey farms", then yeah, sure.
pjmlp 5y ago
Completly unrelated, a page editor that writes pages in a WYSIWYG using only HTML and CSS, Dreamweaver style, can't be compared with using Assembly.

mproud 5y ago

I’m all for not having dependency hell and a million frameworks. I just want some UI controls like sortables lists, tables and not have to type everything out.

nicbou 5y ago

If I'm writing frontend code alone, I do it by hand. In a team, these heavy tools become important to keep some sort of cohesion. Even then, I'm not entirely sure. Nonetheless I had a good cycle the other day when I had to pull 400 MB of Javascript to build a single static page.

ehnto 5y ago
I advocate for frameworks in almost all team projects, the tools act as a set of idioms and best-practices your team should know and use.

strokirk 5y ago

The exakt same thing happens in the backend. Kubernetes, docker, procfiles, apt, yum, various frameworks and languages...

ehnto 5y ago

I think part of the issues is that the line between enterprise tooling and smaller site tooling has disappeared. Even people building personal blogs will be inclined to use enterprise tooling, and take on all of the overhead of tool-chains and configuration.

have_faith 5y ago

There is an ebb and flow in the JS ecosystem. First we get a framework. That framework is missing some key functionality or features so we get plugins and eventually a meta-framework standardising the new behaviour and maybe introducing a slightly new paradigm. That meta framework gets unwieldy and we get a ground up rewrite (new framework) that trims the fat and uses the new evolved features as first class concepts. This is exhausting only because of external and internal pressures to "keep up". I don't see anything inherently wrong with the evolution of ideas and concepts being explored in breadth and depth. Writing and publishing a new JS framework has a very low barrier which is a huge positive that I rarely see extolled compared to complaining that the ecosystem needs to constrain itself.

Fractal_HQ 5y ago
Svelte has everything I need to build websites and apps. The performance, bundle size, and DX combo is unparalleled. All vanilla JS libs are plug-and-play. Building production-ready apps is incredibly fast, and done with less code than any other framework. Svelte's compiler-first approach really fixes all of my problems with the JS ecosystem. Compile-to-JS langs aren't new, but learning a whole new language has non-0 overhead. HTML, CSS, and JS/TS in a .svelte file is awesome, and the syntactic sugar makes the ugly parts of JS (like state management and reactivity) extremely trivial to implement. The first class support for Vanilla JS & Typscript is brilliant. Vite and ESBuild are incredibly fast and hassle free. The water has never felt nicer for me as a web dev!
- have_faith 5y ago
  I like Svelte a lot but haven't dived in deep yet. I'm currently waiting for SvelteKit to reach 1.0. What does your general setup look like for something relatively large and complex?
  - Fractal_HQ 5y ago
    I use Routify for everything- the ecosystem of tools from it's creator Jake already takes care of everything Sveltekit aims to solve. I have Starter Templates with everything set up the way I usually like it if you want to check them out- SvelteKit starter template: https://github.com/FractalHQ/frackit https://github.com/FractalHQ/frackit Routify starter template: https://github.com/FractalHQ/fractify https://github.com/FractalHQ/fractify

diveanon 5y ago

Not everyone is building single page static html sites.

ehnto 5y ago
I think the weird weighting goes in the other direction though, more people are over-encumbered with tools they didn't need.

austincheney 5y ago

The moment you don’t use the maximum number of tools possible or write any line of code that doesn’t call some framework method people will harass you about NIH. I see it nearly everyday online and used to see it at least monthly in the real world at work. If you can fix that problem all this excess tooling stupidity will largely fix itself.

matthuggins 5y ago
NIH?
- scbrg 5y ago
  https://en.wikipedia.org/wiki/Not_invented_here https://en.wikipedia.org/wiki/Not_invented_here

dfinninger 5y ago

I don’t do a lot of front end dev. Just some personal projects here and there and I usually just slap Bootstrap on it to make things look reasonable. I had to do a bit for work and man, when I started actually reading the docs I was surprised to find things like form validation [1] out of the box! There were a few others that I forget now, but I was pleasantly surprised at how much I _didn’t_ have to do. I wound up needing no extra JavaScript. [1] https://developer.mozilla.org/en-US/docs/Learn/Forms/HTML5_input_types https://developer.mozilla.org/en-US/docs/Learn/Forms/HTML5_i...

pietrovismara 5y ago

> Nothing is stopping anyone from opening notepad and writing HTML with inline style, then using FileZilla to FTP/SCP that to a server (probably a VPS these days) somewhere, or publish it on GitHub/GitLab Pages Sure. Then try to write a highly complex e-commerce frontend app with this approach and tell me how does it work out. If notepad + HTML is enough tooling for your web development, you are not a potential user of such a framework. Good news then, you can just ignore it!