Live data from Hacker News

Astro: Ship Less JavaScript

astro.build

141–150 of 171 posts

Re: Astro: Ship Less JavaScript

#141

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 s…

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.

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.

Re: Astro: Ship Less JavaScript

#142

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 s…

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.

Re: Astro: Ship Less JavaScript

#143
I see this tool as peak micro-intelligence and macro-stupidity of the whole web dev community. The tool itself is very interesting, and congrats to the authors. But needing this tool shows that in general we have no fucking clue what we're doing.

Re: Astro: Ship Less JavaScript

#144

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 s…

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.

NIH?

Re: Astro: Ship Less JavaScript

#145

Earlier quoted context omitted.

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.

NIH?

https://en.wikipedia.org/wiki/Not_invented_here

Re: Astro: Ship Less JavaScript

#146
post #136
post #133

Earlier quoted context omitted.

After reading the front page, I'm a little confused. How do you go from "compose your website using UI components from your favorite JavaScript web framework" to "a fully static website with all JavaScript removed from the final page" without losing functionality provided by those components? What's the purpose of using components without JavaScript?

I don’t use this, but I do something similar for my personal blog. JSX (and components) is possibly the nicest templating language I’ve ever used. The problem with almost all others is that they are based on strings, so you lose type-safety (and more importantly completions) for the template parameters. However, the current ecosystem makes it really hard to use JSX for just templating. There are libraries that do exa…

I'm sorry, but how is JSX a good templating language? I much prefer Svelte's approach where you have native HTML and script/css tags within which lives native (scoped) code.

Re: Astro: Ship Less JavaScript

#147
post #132

Earlier quoted context omitted.

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.

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.

> 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.

Re: Astro: Ship Less JavaScript

#148

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 s…

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.

> The productivity gained from these Tools

You don't gain productivity using 500 libraries pulled off NPM unless it's write once read never.

Re: Astro: Ship Less JavaScript

#150

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 s…

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

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!).
Post reply on HN