
A static website with React - moehm
http://www.thedotpost.com/2016/12/maxime-thirouin-a-static-website-with-react-really
======
ggregoire
> _" The one that allows you to improve the quality of your code with unit
> testing and type checking"_

Wait, are we really talking about a static website?

I'm a big fan of React and all the JS ecosystem, but when I need a static
website, I just make my bunch of html files (and I copy/paste the same
header/footer on each), my css file, eventually 2 lines of JS directly in a
<script> tag to toggle a menu on mobile devices, I upload it on S3/CloudFront
and that's it.

~~~
kennu
I think we are taking about websites that can be hosted on a static file
server like Amazon S3/CloudFront, but which also have all the dynamic features
of React available for building a rich and complex UX. For instance, when
working with Phenomic (which uses Webpack), it's very easy to add any
necessary React components to your project simply with npm install / yarn add.
So it's really a marriage of Markdown based content publishing and interactive
client-side UX.

~~~
paulddraper
I eternally have this misunderstanding. I think static means unchanging.

In this context, it means static HTTP responses, but dynamic HTML/DOM.

I want a word to mean _really_ static.

~~~
bloodyowl
Hello,

I'm in the core Phenomic team.

The idea in Phenomic is that we generate for each page:

\- the HTML entry point, rendered like it would be with ReactDOMServer \- the
data-requirements of the page

That lets us offer the following: \- Any page is accessible directly, without
runtime (which has advantages regarding performance and SEO) \- Navigation
works even if JS is disabled \- If JavaScript is enabled, the runtime just
loads the minimum required data for the next page to display and renders it

Phenomic really is static, it just uses a few techniques that we learnt from
the modern front-end development workflows and capabilities :)

~~~
paulddraper
Neat. Thanks for the info!

------
kylemathews
I'm the author of another React static site generator
([https://github.com/gatsbyjs/gatsby](https://github.com/gatsbyjs/gatsby)).

I totally agree that for many sites, using Phenomic or Gatsby would be
overkill.

But for something small, it doesn't really matter what tool you use as long as
it's familiar. For small projects, familiarity trumps any other concern.

React came out of Facebook that needed a frontend technology that could scale
to 1000s of developers.

Gatsby and Phenomic are both an attempt to port the best of the React
ecosystem to the world of building web sites. They're designed so that as your
website gets larger and you add more people, the code still feels simple and
it's still easy to make changes and add new features.

So yes there's a learning curve and some overhead but it really pays off for
larger projects.

And the nice thing is that once you understand them, they're now familiar so
just as easy to use on small projects as any other solution.

~~~
djcollier
I just started building a blog with Gatsby, after a lot of research it was
exactly what I was looking for. As the author of Gatsby, what would you say
the major differences are between Phenomic and Gatsby?

------
restlessdesign
> The result is a website completely SEO friendly that will work for the two
> people in the whole world who disabled JS

What will it take to dispel the myth that JS rendering isn’t SEO friendly?
There seems so much confusion on this point but the fact is that as long as
your UI is rendered synchronously (i.e., any data needed for the UI doesn’t
have to get fetched from a server), the page will be crawlable by Google.

Further, the goal of isomorphic rendering/rendering static sites in general is
not to serve individuals who have JS disabled (that’s a bonus, sure), but
rather to remove JS loading and execution from the equation with the end goal
of faster paint times for your application.

To be clear, this is a really cool project but I fear that many of us throw
out keyword spam like SEO and UX to make something more digestible, when the
reality is that the performance gain is the real hero!

~~~
lcw
Do you have proof that JS rendering is equally as friendly to SEO as
statically rendered html?

I have been fighting this battle for a while at different places by I can't
definitely prove it's true, and most SEO experts that I work with seem to be
afraid to upset the apple cart explaining that Google might be good at it, but
what about yandex or baidu. I know there are small tests, but has a large
corporation where SEO really matters made the switch without a meaningful SEO
hit?

~~~
dfabulich
On the contrary, all I've ever heard of are folks who start with JS rendering
and then add server-side rendering (e.g. with React Server) and report how
much better their SEO traffic gets.

------
yodon
The article is about phenomic, a static site building tool for React.

As a long-time C# dev, about a week ago I started learning phenomic and
typescript by porting a large-ish horrible-mess-of-html-and-javascript site to
typescript and phenomic using VS Code. It's been one of the most joyful coding
experiences I've had in years. The joy wasn't because everything was easy (I
was doing too much learning for it to be easy), it was because everything was
just so right.

I take back everything I've ever said about web development. Those horrible
days are behind us. Thank you to the react, typescript, and phenomic teams. I
can easily base my next 5-10 years of web development work off the frameworks
and directions you've set out for us.

------
megawatthours
This claims to improve static websites by adding hot reloading, search, React,
the NPM ecosystem, and faster page load.

Search can already be done using Jekyll [https://blog.algolia.com/instant-
search-blog-documentation-j...](https://blog.algolia.com/instant-search-blog-
documentation-jekyll-plugin/) (same idea of indexing at build time).

Jekyll can hot reload with jekyll serve.

Anyone who is familiar with React is familiar with HTML and CSS, whereas the
opposite is not necessarily true. This means if you are able to use Phenomic,
you are able to use Jekyll, but not vice versa.

The NPM ecosystem is useful for authoring templates, not for the end user. If
I were writing a Jekyll template I'd probably use webpack and npm, but I don't
need that baked into the static site generator itself.

Finally, page load is a really dubious claim, here's some numbers:

On phenomic.io, the HTML for the index page weighs 3K gzipped (measured by
copying HTML, removing what can be externalized and cached like styles +
scripts, and gzipping index.html)

When using Phemonic to do client-side loading, the JSON for the different
pages is from 600B to 2.9K (as seen in network tools when clicking on the
links in the top nav).

A page load with phemonic therefore saves you: * 2KB of bandwidth for some
pages * a few 302 not modified requests for static resources, which are
negligible if you use HTTP/2

On the flip side of the coin, phemonic.js, the script bundle which makes all
this magic possible, weighs 132KB, ie 44 times the size of the content the
user wants to view.

I can't see the value here.

~~~
kylemathews
Javascript doesn't affect page load (generally). What Phenomic (and my project
Gatsby) speed up is clicking around within a site after the initial page load
as we pre-cache subsequent pages so loading those pages is near-instant.

~~~
juandazapata
Browsing static pages is near-instant. No need for React to do that.

~~~
kylemathews
Another point in favor of this model is because routing is client-side, page
changes are _consistently_ fast. In best-case network conditions, normal
static sites are very fast but throw the user on a glitchy 3g network and
you'll soon see 5-10 second page loads. The same site built with Gatsby will
still see instant page changes as page data is precached.

~~~
onion2k
That's a big advantage, but at the same time you're pushing content to a user
that they might not want, or ever see, which could be a problem for users on
poor quality 3G networks. If bandwidth is at a premium a developer shouldn't
waste it.

~~~
kylemathews
"Bandwidth" isn't the problem on 3g generally. What does cause UX problems is
high latency. Speculatively precaching content is basically the only solution.

FWIW, while I'm in the US so don't really understand developing for very poor
networks, the methods I'm describing is exactly what companies in India and
other places with poor networks are adopting:
[https://developers.google.com/web/showcase/2016/flipkart](https://developers.google.com/web/showcase/2016/flipkart)

This is also a good read
[https://developers.google.com/web/fundamentals/performance/p...](https://developers.google.com/web/fundamentals/performance/prpl-
pattern/)

------
LogicX
Came here to see if anyone mentioned next.js:
[https://zeit.co/blog/next](https://zeit.co/blog/next)

Which fits in with this discussion.

Been working well for us on [https://DNSFilter.com](https://DNSFilter.com)

~~~
at-fates-hands
Looks pretty slick.

Is just me, or does it look like NextJS uses pure functions?

~~~
gobengo
It's just you.

Or rather, next.js uses React Components. You can write those as pure
functions or you can write them as classes to have more fancy features (e.g.
setState, lifecycle hooks)

------
magic_beans
Why does this feel like using a sledgehammer to hang a painting? I know people
like React a lot, but it has no place generating a static website.

~~~
Spivak
Because if you already use the sledgehammer to build mansions for your day
job, using it to build your shed will take no time at all.

~~~
StavrosK
That's why I screw all my screws in with a hammer. I'm just so good at nailing
things!

------
zitterbewegung
How are current static website generators limited? The powerpoint doesn't go
into more of why that is.

------
nkristoffersen
The biggest win with building a SPA in react or angular is that you can host
it on S3 and front it with Cloudfront and never ever worry about it dying.
Plus, performance is amazing.

------
andybak
I don't have time to formulate a proper response but I just wanted to say this
makes me sad.

We've now reached the point where HTML and CSS served via a normal webserver
is regarded as insufficient and anyone who wants to build websites of even the
simplest kind is expected to wheel in an incredibly large client-side and
development stack.

Something has gone wrong. All this to avoid a page reload? Should the terrible
effects of a page reload not be solved elsewhere?

> without the hacky "pjax" solution.

Before you start using the word 'hacky' you might want a moment of self-
reflection.

~~~
CoffeeDregs
I hugely agree. I've done a lot of web development in a range of circumstances
and this current period is frustrating. I just started a new project at a new
company; decided to use React; bought and downloaded a React Admin template;
spent 2 hours trying to get it to "build"; gave up after I couldn't sort the
node_modules conflicts among about 50 modules (totalling nearly 1GB!), each of
which had 10+ modules as a dependency.

Angular did have its issues, but I dropped a reference to CDN's version into a
web page and was off to the races very quickly.

I'm literally using Makefiles to build, test and deploy a set of about 7
microservices (including their web admin tooling). It's incredibly
straightforward, flexible and clearly documented... Gulp, Grunt, WebPack...
What are we doing?

~~~
justinsaccount
> bought and downloaded a React Admin template

huh?

> Angular did have its issues, but I dropped a reference to CDN's version into
> a web page and was off to the races very quickly.

Then you're not really comparing apples to apples here. There are <script>
loadable versions of react on CDNs that you could have used.

~~~
at-fates-hands
Probably the difference between having Angular being a full MVC framework,
while React is simply a View library you combine with other libraries to get
what you need.

Combining various libraries can be a pain and sorting out all of the
dependencies and node modules like he stated can be cumbersome.

------
jordanlev
Javascript fatigue aside, this suffers the same annoying (to me) limitation
that a lot of static site generators and CMS's do: it presumes that there will
only be 1 main content area per page that you populate with a big chunk of
markdown or html. ( [https://phenomic.io/docs/getting-started/#the-
body](https://phenomic.io/docs/getting-started/#the-body) )

This is a sensible assumption for a something like a blog, but falls apart
quickly on most other sites I've had to build for clients (e.g. more than 1
column, homepages with lots of "modules", etc).

Kind of ironic that React's "big idea" is that it's components all the way
down, but when it comes time to structure the content, it's like "nope, just
one big monolith of styled text".

(YAML front-matter helps a little bit, but usually is only intended for
"metadata", not the primary page content itself.)

------
kmonsen
Good project, but there is some confusion in what they mean with static
website. As I understand it static does not imply no JS (or in other ways
changing the page based on user input), but that the server is not rendering
it specifically for this request but just serves a page that is ready when the
request hits the server.

------
k__
Just blogged about static site generation with Webpack [0]. This is an React
independent approach, you can basically use any renderer that runs on Node.js.

[0] [https://dev.to/kayis/create-static-sites-with-
webpack](https://dev.to/kayis/create-static-sites-with-webpack)

------
sebringj
This is brilliant and a niche needed for React. My toolset is React Native,
React web apps and now this for simple marketing sites that you can inject
functionality into.

------
d08ble
Thanks for your work! That is cool stuff for my project. I'm looking for the
solution very long time. I worked with React from first versions. I remember,
how I was tried to startup first buggly webpack versoin and lost 2 week at
2014...

------
nicorama
The most important thing for me is that content is apart of the technic, in
markdown files that are easy to write, easy to read. The fact that Phenomic is
generating HTML makes it almost free to deploy, without any security leak.

------
bryanlarsen
Why would you do this?

\- to share styling & code between an app and a related static site

\- because it's really easy, iff you already have your full front-end dev
stack set up already.

------
qznc
Hot reloading is the only feature I could use compared to my self-made script.

That should be done the browser actually. The Epiphany browser does it, but no
other.

For search there is Google.

------
smegel
> What if this website will be static but dynamic at the same time?

Well then it wouldn't be static would it?

~~~
bloodyowl
Statically served isn't an opposite of dynamically updated, dynamically
fetched and extensible with dynamic parts on the client.

------
brunoc
Doing exactly this right now on a new project using Preact. Working great so
far.

------
brilliantcode
This seems like a tough sell. What's wrong with index.html with inline CSS or
CDN jQuery you can sprinkle to add dynamic feel? That comes in less than 5kb?

What is the point of over engineering a static website that can be solved with
far far less?

------
jondubois
That is crazy. React is just the current trend but having tried both React and
Polymer (Web Components), I'm confident that plain Web Components will win out
in the end. You just can't beat simplicity.

~~~
QuantumGravy
No, crazy is suggesting Web Components are even remotely suitable for a static
site or server-side rendering. Good luck with those if your users have
disabled JS.

