I see VuePress just went 1.0. Explained simply, it’s a static site generator based on Vue. But of course, you work in Vue, which means you work in components.
All the modern JavaScript frameworks are component-based. Even when they disagree with each other about specific things (like how Svelte requires compilation), they all seem to agree on the model of working in components. React is all components. A popular static site generator for React is Next.js. The Vue version of that is Nuxt.js.
Then there is Gatsby which is all React. (Listen to our latest ShopTalk Show as we discuss it.) Gridsome seems like the most 1-to-1 comparison in Vue-land, the notable comparison being how they both are designed to suck in data from any source. Components though, of course. I’m not sure there is a flagship Angular-based static site generator, but they are out there, and Angular is components all the way down.
Components are so ubiquitous that perhaps you don’t even think about it anymore. But you might feel it, particularly if you jump back and forth between projects that aren’t component-driven. WordPress development, generally, I feel, isn’t component driven. Sure, you’ve got your header.php and footer.php files and such. You can break those apart however you want, but it’s rather ad-hoc. You aren’t explicitly building components and feeding those components local data and testing them as such. (You can get a lot closer with something like Timber.)
Building front-ends out of server-side code is absolutely fine. Server-side rendering is rife with advantages. But server-side languages don’t seem to have embraced components the way JavaScript has. And since everyone seems to like components (front-end devs obviously love it, designers think that way anyway, back-end devs understand it…) it’s no surprise to me to see this surge of beloved projects build server-side (or build-time) generated sites from JavaScript, simply because it’s component-based and components are just a good idea.
NuxtJs no.1 !
‘But server-side languages don’t seem to have embraced components the way JavaScript has’
React and Angularjs got their ideas from JSF and Spring for Java and ASP MVC for .NET. Frameworks that forces the user to think in and work with components.
That’s cool! Just for my own curiosity, is there some articles or whatever out there talking about those early days and where the ideas came from? I’m sure there is lineage even deeper… there really are no new ideas anymore, right? :)
But in spite of origins, I still feel like my statement that server-side languages not embracing components in the same way holds some water, at least in the bubbles I live in. Java and .NET development are totally outside my bubbles, for the record. I’m closer to hearing what Ruby, Python, and PHP developers are saying, and it doesn’t seem like the conversation there is about frameworks that absolutely force component composition.
Agreed, the JavaScript world is borrowing the idea from serverside frameworks which very much embraced the idea of components.
ASP.NET started with “user controls”, now “View Components” in ASP.NET MVC. These are self-contained components that can have their own controller and state (like a “class component” in React). There are also “Partial Views” which are equivalent to “function components” in React.
Serverside languages have had these all along. In fact the early component library tools were borne out of Ruby on Rails and Django. Storybook came along and trod the same path for JavaScript, but really it’s nothing new.
Dang, I remember SSI (server side includes) from back in the days… Can this be considered HTML-based component tech?
Here’s a good one for ASP.NET user controls. You can see the emergence of encapsulated components with their own business logic, that can be dropped anywhere on a page. You can also see the start of syntax to pass attributes into them. It was quite normal to decompose UI into “user controls” at the start of building a page, much like we’d do with “components” these days.
https://www.codemag.com/Article/0209031/ASP.NET-Extending-the-Power-of-Web-Pages-with-User-Controls
This model spawned an entire industry of ready-made, self-contained UI components to be composed into project UI such as https://demos.telerik.com/aspnet-ajax/. Early examples of this were quite literally user controls (components with props) and some global CSS/JS.
Rails and other MVC-style frameworks have strong conventions for building UI out of a series of HTML partials. Think of a page view as a “container component” and much smaller views are simple “function components” that are passed parameters (props) to render components. Of course they don’t enforce the model, but Rails has such strong naming conventions that so long as you name your partial HTML files (components) correctly it will find them when you try to render out an object. The syntax of
<%= @order %>isn’t much different to<Order />— just a different way of passing values into a thing that returns HTML.