6 ms·

> Traditional frameworks hydrate entire pages with JavaScript. Even if you've got a simple blog post with one interactive widget, the whole page gets the JavaSc

• chrisldgk 1y ago
  I agree with that it’s not a new concept by itself, but the way it’s being done is much more elegant in my opinion. I originally started as a web developer during the time where PHP+jQuery was the state of the art for interactive webpages, shortly before React with SPAs became a thing. Looking back at it now, architecturally, the original approach was nicer, however DX used to be horrible at the time. Remember trying to debug with PHP on the frontend? I wouldn’t want to go back to that. SPAs have their place, most so in customer dashboards or heavily interactive applications, but Astro find a very nice balance of having your server and client code in one codebase, being able to define which is which and not having to parse your data from whatever PHP is doing into your JavaScript code is a huge DX improvement.
  • diggan 1y ago
    > Remember trying to debug with PHP on the frontend? I wouldn’t want to go back to that. I do remember that, all too well. Countless hours spent with templates in Symfony, or dealing with Zend Framework and all that jazz... But as far as I remember, the issue was debuggability and testing of the templates themselves, which was easily managed by moving functionality out of the templates (lots of people put lots of logic into templates...) and then putting that behavior under unit tests. Basically being better at enforcing proper MVC split was the way to solve that. The DX wasn't horrible outside of that, even early 2010s which was when I was dealing with that for the first time.
    • leetrout 1y ago
      Bingo. Modern PHP development with Laravel is wildly effective and efficient. Facebook brought React forth with influences from PHPs immediate context switching and Laravel’s Blade templates have brought a lot of React and Vue influences back to templating in a very useful way.
    • Vinnl 1y ago
      Well, that's a way to manage server-side logic, but your progressively-enhanced client-side logic (i.e. JS) still wasn't necessarily easy to debug, let alone being able to write unit tests for them.
      • diggan 1y ago
        > but your progressively-enhanced client-side logic (i.e. JS) still wasn't necessarily easy to debug, let alone being able to write unit tests for them True, don't remember doing much unit testing of JavaScript at that point. Even with BackboneJS and RequireJS, manual testing was pretty much the approach, trying to make it easy to repeat things with temporary dev UIs and such, that were commented out before deploying (FTPing). Probably not until AngularJS v1 came around, with Miško spreading the gospel of testing for frontend applications, together with Karma and PhantomJS, did it feel like the ecosystem started to pick up on testing.
      • evantbyrne 1y ago
        There wasn't as much JS to test. I built a progressively-enhanced SQLite GUI not too long ago to refresh my memory on the methodology, and I wound up with 50-ish lines of JS not counting Turbo. Fifty. It was a simple app, but it had the same style of partial DOM updates and feel that you would see from a SPA when doing form submissions and navigation.
        • Vinnl 1y ago
          Not usually, but in the context of > Astro find a very nice balance of having your server and client code in one codebase, being able to define which is which and not having to parse your data from whatever PHP is doing into your JavaScript code is a huge DX improvement. the point is pretty much that you can do more JS for rich client-side interactions in a much more elegant way without throwing away the benefits of "back in the days" where that's not needed.
• steve_taylor 1y ago
  Back in your day, there wasn’t a developer experience by which you could build a website or web app (or both) as a single, cohesive unit, covering both front-end and back-end, while avoiding the hydration performance hit. Now we have Astro, Next.js with RSC, and probably at least a dozen more strong contenders.
  • hasanhaja 1y ago
    > there wasn’t a developer experience by which you could build a website or web app (or both) as a single, cohesive unit, covering both front-end and back-end How much of the frontend and how much of the backend are we talking about? Contemporary JavaScript frameworks only cover a narrow band of the problem, and still require you to bootstrap the rest of the infrastructure on either side of the stack to have something substantial (e.g., more than just a personal blog with all of the content living inside of the repo as .md files). > while avoiding the hydration performance hit How are we solving that today with Islands or RSCs?
    • steve_taylor 1y ago
      It can cover as much of the back-end that your front-end uses directly as you’d care to deploy as one service. Obviously if you’re going to have a microservices architecture, you’re not going to put all those services in the one Next.js app. But you can certainly build a hell of a lot more in a monolith that a personal blog serving a handful of .md files. In terms of the front-end, there’s really no limit imposed by Next.js and it’s not limited to a narrow band of the problem (whatever that gibberish means), so I don’t know what you’re even talking about. > How are we solving that today with Islands or RSCs? Next.js/RSC solves it by loading JavaScript only for the parts of the page that are dynamic. The static parts of the page are never client-side rendered, whereas before RSC they were.
      • hasanhaja 1y ago
        There are a lot of moving parts when building an application and the abstractions that Next.js provides doesn't cover the same stuff when compared to frameworks like Ruby on Rails, Django and Laravel. The narrow band of problems Next.js solves for you are things like data fetching, routing, bundling assets and rendering interactive UI. It leaves things like auth, interacting with a database, logging, mailing, crons, queues, etc up to you to build yourself or integrate with 3rd party services. When you work with one of those frameworks, they pretty much solve all of those problems for you and you don't have to leave the framework often to get things done. This is fine generally because you have the choice to pick the right tool for the job, but in the context of "a single, cohesive unit" you can only get that with Next.js if you all that you care about are those specific abstractions and want your backend and frontend to be in the same language. Even then you run into this awkwardness where you have to really think about where your JavaScript is running because it all looks the same. This might be a personal shortcoming, but that definitely broken the illusion of cohesion for me. > The static parts of the page are never client-side rendered, whereas before RSC they were. Didn't the hydration performance issues start when we started doing the contemporary SSR method of isomorphic javascript? I think Islands are great and it's a huge improvement to how we started doing SSR with things like Next.js Pages Router. But that's not truly revolutionary industry wide because we've been able to do progressive enhancement long before contemporary frameworks caught up. The thing I'm clarifying here is the "before RSC" only refers to what was once possible with frameworks like Next.js and not what was possible; you could always template some HTML on the server and progressively enhance it with JavaScript.
• archerx 1y ago
  I remember when it was called AJAX. We have completely lost the plot.
  • 0x445442 1y ago
    It's why Alan Kay calls our industry a Cargo Cult and says it's much more akin to the fashion industry than engineering.
    • zoom6628 1y ago
      Absolutely.
  • nchmy 1y ago
    Htmx and, even moreso, Datastar have brought us back on track. Hypermedia + Ajax with whatever backend language(s)/framework(s) you want. Whereas astro is astro.
  • ksec 1y ago
    I remember it was called DHTML. ( And the code never works perfectly on IE and Netscape / Mozilla )
    • paradox460 1y ago
      DynamicDrive my beloved
• api 1y ago
  This field (software) in general, and especially web stuff, has no memory. It’s a cascade of teens and twentysomethings rediscovering the same paradigms over and over again with different names. I think we are overdue for a rediscovery of object oriented programming and OOP design patterns but it will be called something else. We just got through an era of rediscovering the mainframe and calling it “cloud native.” Every now and then you do get a new thing like LLMs and diffusion models.
  • rambambram 1y ago
    This. So much this. I'm not even 42 and I feel old when I read stuff like this. Like you say, there's no memory in the web software field.
    • api 1y ago
      Wasted effort reinventing things and rediscovering their limits and failure modes is a major downside of the ageism that is rampant in the industry. There is nobody around to say “actually this has been tried three times by three previous generations of devs and this is what they learned.” Another one: WASM is a good VM spec and the VM implementations are good, but the ecosystem with its DSLs and component model is getting an over engineered complexity smell. Remind anyone of… say… J2EE? Good VM, good foundation, massive excess complexity higher up the stack.
    • omnimus 1y ago
      Even if you are 10 years younger than you and youve been doing it webdev in your late teens you’ve seen like three spins of the concepts wheel to come back again and again.
  • daotoad 1y ago
    Software engineering/development has had a long September. https://en.wikipedia.org/wiki/Eternal_September https://en.wikipedia.org/wiki/Eternal_September
• skipchris 1y ago
  Agreed! Astro is fantastic, but the biggest barrier I had in learning it was getting my head around range of terms that developers who entered the workplace after 2010 have invented to describe "how the web works".
  • rubyfan 1y ago
    I really appreciate that innovation can sometimes reinvent things that exist out of pure ignorance and sometimes hubris. I’ve seen people turn mountains out of molehills that take on a lore of their own and then along comes someone new who doesn’t know or is a little too sure of themselves and suddenly the problem is solved with something seemingly obvious. I’m not sure javascript islands is that but I appreciate a new approach to an old pattern.
• z3t4 1y ago
  The first web frameworks really got it right with stateless websites and server rendering.
• hombre_fatal 1y ago
  You're making the opposite mistake: you're seeing someone's description of a tool's feature and confusing it with the way we've already done things without even checking if the tool is transformative just because it kinda sounds similar. Astro's main value prop is that it integrates with JS frameworks, let's them handle subtrees of the HTML, renders their initial state as a string, and then hydrates them on the client with preloaded data from the server. TFA is trying to explain that value to someone who wants to use React/Svelte/Solid/Vue but only on a subset of their page while also preloading the data on the server. It's not necessarily progressive enhancement because the HTML that loads before JS hydration doesn't need to work at all. It just matches the initial state of the JS once it hydrates. e.g. The <form> probably doesn't work at all without the JS that takes it over. These are the kind of details you miss when you're chomping at the bit to be cynical instead of curious.
  • blackhaj7 1y ago
    > you're chomping at the bit to be cynical instead of curious. Nicely sums up a lot of interactions these days
  • zelphirkalt 1y ago
    What is the value in first sending dysfunctional HTML and then fixing it with later executed JS? If you do that, you might as well do 100% JS. Probably would simplify things in the framework. Sending functional HTML, and then only doing dynamic things dynamically, that's where the value is for web _apps_. So if what you point out is the value proposition for Astro, then I am not getting it, and don't see its value.
    • gbalduzzi 1y ago
      Dysfunctional HTML in the sense that interactivity is disabled, but visually it is rendered and therefore you can see the proper webpage immediately. Just compare the two cases, assuming 100ms for the initial HTML loading and 200ms for JS loading and processing. With full JS, you don't see anything for 300ms, the form does not exists (300ms is a noticeable delay for the human eye). With frameworks such as Astro, after 100ms you already see the form. By the time you move the mouse and/or start interacting with it, the JS will probably be ready (because 200ms is almost instant in the context of starting an interaction). This is not new at all, old school server side processing always did this. The advantage is writing the component only once, in one framework (React/vue/whatev). The server-client passage is transparent for the developer, and that wasn't the case at all in old school frameworks. Note that I'm not seeing this is good! but this is the value proposition of Astro and similar frameworks: transparent server-client context switching, with better performance perceived by the user.
• AlienRobot 1y ago
  >Traditional frameworks hydrate Dear God. In 20 years people will hire HTML experts as if they are COBOL experts today.
  • antonvs 1y ago
    I look forward to that day, because it implies something better would have replaced it.
    • diggan 1y ago
      > because it implies something better would have replaced it Hah, if only... Time and time again the ecosystem moves not to something that is better, but "same but different" or also commonly "kind of same but worse". There are so many cases where the "worse" solution "won", and there is a reason "worse is better" is such a popular mantra: https://en.wikipedia.org/wiki/Worse_is_better https://en.wikipedia.org/wiki/Worse_is_better
• renewiltord 1y ago
  The headline is literally “returns to the fundamentals of the web” so that’s the point.