Hacker News new | past | comments | ask | show | jobs | submit login

Consider a site with a tabbed navigation bar. With the router you can develop each target page as it's own component and use the url to navigate between them.



I can appreciate the concept, but Hugo/Jekyll/Middleman can let you author the original "component" pages and automatically generate a nice, simple <nav> element with an unordered list (or ordered list, if it's more semantically correct) of <a> elements. Plus wrap those tab-page components in your site-wide layout "chrome". You could even progressively enhance the site so that the browser uses idle time post-DOMReady to preload linked pages via XMLHttpRequest, so that they can be pre-cached and ready to load when the user clicks the link. No second load required to load the chrome of the site and then load the routed page resource if someone deep-links.

My point isn't that React is bad (I really, really dig React for those "reactive" views connected to a model representing dynamic data), but that we're effectively over-engineering an ancient use case — a CMS where content is defined statically at build time — that good ol' HTML does exceedingly well with no complicated tooling and (if marked up and styled sanely, with progressive enhancement where appropriate) no browser compatibility concerns.


Also: in your case, the model (pages in your site, content in the tabs) isn't changing, the view is, and the built-in capabilities of the browser as the "controller" are sufficient for a static model.

Reacting to a user event doesn't mean it's a "reactive UI", every UI is a reactive one by that definition.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: