Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Astro: Ship Less JavaScript

astro.build

Post reply on HN
Print view View original

121–130 of 171 posts

Re: Astro: Ship Less JavaScript

#121

Post by bildung »

pjmlp wrote: post #113
varrock wrote: post #107

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.

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.

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.

Re: Astro: Ship Less JavaScript

#122

Post by httgp »

fks wrote: post #2

:wave: Hey everyone, one of the Astro creators here! Happy to talk Astro or answer any questions you have about what we're building. Our README has a bunch more info that we couldn't fit into the release post: https://github.com/snowpackjs/astro

This looks super-exciting. Will you be building plugins or examples that show how to use this with other frameworks like Next.js/Nuxt.js?

Re: Astro: Ship Less JavaScript

#123

Post by mcintyre1994 »

fks wrote: post #2

:wave: Hey everyone, one of the Astro creators here! Happy to talk Astro or answer any questions you have about what we're building. Our README has a bunch more info that we couldn't fit into the release post: https://github.com/snowpackjs/astro

Does this handle anything serverside at all, like if you need auth or if you need to read data from a database at request time? Or would you fall back to something like Next if you needed that?

Re: Astro: Ship Less JavaScript

#124

Post by strokirk »

seanp2k2 wrote: post #102

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 exakt same thing happens in the backend. Kubernetes, docker, procfiles, apt, yum, various frameworks and languages...

Re: Astro: Ship Less JavaScript

#125

Post by pjmlp »

bildung wrote: post #121
pjmlp wrote: post #113

Earlier quoted context omitted.

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.

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

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.

Re: Astro: Ship Less JavaScript

#126

Post by ehnto »

seanp2k2 wrote: post #102

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…

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.

Re: Astro: Ship Less JavaScript

#127

Post by have_faith »

seanp2k2 wrote: post #102

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…

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.

Re: Astro: Ship Less JavaScript

#128

Post by diveanon »

seanp2k2 wrote: post #102

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…

Not everyone is building single page static html sites.

Re: Astro: Ship Less JavaScript

#129

Post by ehnto »

nicbou wrote: post #119
seanp2k2 wrote: post #102

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…

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.

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