Guillermo Rauch

I actually strongly advocate for: SSR and server is the absolute best default[1], and Next.js gives you tremendous flexibility on where to place your compute[2], including skipping SSR altogether[3], with the best-in-class static export that can actually at least put some content in your HTML instead of a blank page[4] [1] https://rauchg.com/2014/7-principles-of-rich-web-applications#pre-rend… [2] https://twitter.com/rauchg/status/1637136013083684864 [3] https://twitter.com/timneutkens/status/1636693508223270912 [4] https://twitter.com/dan_abramov/status/1636827365677383700

I think by now many HNers will have grasped the idea behind "The core premise for React is that UIs are simply a projection of data into a different form of data", but here's a related good read from around the time this was written: Pure UI https://rauchg.com/2015/pure-ui Also of interest, the classic 'Rethinking best practices' presentation: https://www.youtube.com/watch?v=x7cQ3mrcKaY

As the author noted at the bottom, it's taken from https://rauchg.com (the guy behind now.sh)

There is no need to always create an "opposite"-view post in response to other "controversial" posts. Can't wait for "The Pragmatic Front-End Developer" to pop-up in a few days. Bottom line, we should focus on discussion that progresses our craft and not superficial rivalries. Take for example the excellent Pure UI by rauchg [1] (at the very least check the first footnote of the article, a true engineer in mind) [1]: http://rauchg.com/2015/pure-ui

congrats team! 21m series A is hefty even before coronavirus. Good to have locked it in. I've been following this frontend-gets-fullstack-abilities trend for a while. I think Next.js is the best expression of this idea, and is truly the crown jewel of Vercel and also the React ecosystem. Unlike other React distros like Gatsby or Create-React-App, Next.js is the first "hybrid" framework that lets you choose whether to deploy static or serverless pages on a per page level. This means you can ship features without being locked into app level architectural choices. Even static pages get a "Preview" mode, solving a key pain point for content workflow. (all with the caveat that you must use a hosting setup capable of supporting these features, and naturally Vercel is the best place to do that if you don't want to roll your own). A few months ago Dan Abramov noted[0]: > The next wave of techniques won’t be about putting everything on the client. Or doing everything on the server. It will let you move code between them without friction, and adjust the tradeoff to the use case. Take advantage of both. The Middle Way. I see Next.js as the way most of the ecosystem will experience this colocation of client and server concerns. The other trend I see is that React is continuing to work on integrated client-and-server experiences. (Note: everything I discuss here are experimental projects by the React team, so should not be taken as an official roadmap). React Suspense's…

I think you make an excellent observation that FE is a system engineering challenge. Algorithms do play an important role as you can see in this great presentation by Marc de Marco (https://www.youtube.com/watch?v=90NsjKvz9Ns) However I think it's fair to say most FE engineers apply existing solutions and the system design is a bigger part of their role. I differentiate between UI Engineering and Front-End Engineering. The former emphasises design integration (pixels) and performance (rendering). The latter is broader scope and emphasises the systems engineering. Both have to deal with system design. UI is about components and messaging across the components with the front-end application being the "system". FE is about components that integrate the front-end application with what have traditionally been back-end APIs and services. In many cases when people say FE they mean both FE and UI. I would not get hung up on these but they help to clarify what you are talking about and who you are trying to hire. In the case of design and pixels there are specific challenges around dealing with layout and CSS and achieving 60fps. Creating UI components is an exciting area. For example see Pure UI (http://rauchg.com/2015/pure-ui/) by @rauchg. Mess in Web Components (https://hacks.mozilla.org/2015/06/the-state-of-web-components/). Challenge of style encapsulation... So there are a lot of unique challenges and skills and experience required in UI engineering. There are also…

> private, local and in the hand of the people. We've seen time and time again that "the people" prefers centralised, paid, convenient management of complexity. If the majority of "the people" prefers paying a subscription for watching movies or listening to music, I doubt they'll make the effort to learn how to tune and run private LLMs locally, for medical aspects or otherwise. Not when there will be major companies spending billions on marketing more convenient options. Guillermo Rauch's essay [1] still rings true: it's hard to forego efficiency (though it works just as well for convenience). [1] https://rauchg.com/2017/its-hard-to-forego-efficiency

We believe the future of the frontend is "at the edge"[1], meaning it's as close to your customers as physically possible. The only way to beat the speed of light is to be closer[2]. Frameworks and tooling should be designed with this constraint from the start[3]. [1] https://vercel.com/edge [2] https://rauchg.com/2014/7-principles-of-rich-web-applications#pre-rend… [3] https://vercel.com/features/infrastructure

Truly remarkable result from the Sia core team after 5+ years of work! It will be really interesting to see how the whole JAMStack "static is the new dynamic" movement (NextJS, Gatsby), and the immutable deploy URL pattern can benefit from being built on top of something like this![1] [1] https://rauchg.com/2020/2019-in-review

By abandoning React, Vue, and Angular, you're excluding yourself from hiring all the webdevs that need a front-end technology on their resumes in order to get hired elsewhere. That's a pretty large swath. But yes, it's nice that the world is finally realizing Arc was way ahead of its time. HN is snappy because the HTML is small, with few network requests. https://rauchg.com/2014/7-principles-of-rich-web-applications

So for context that was written whilst I was funemployed before joining Airbnb. - René etc is more conceptual - it’s obviously not a practical day-to-day tool - React Sketch.app solves the problems in our org that I can do something about, but also lets you do combinatorial/permutational exploration (see the GIFs in the intro!) because _it’s just javascript_. Both embrace the paradigm of UI-as-a-function-of-data, and really are indebted to the mark that Guillermo left on my brain with https://rauchg.com/2015/pure-ui

Looks like you left out the URL to the Slack group. In any case, why don't you use Slackin [1] to allow interested people to become members? [1] http://rauchg.com/slackin/

I don't think I could write a comment that's a stronger explanation than what Guillermo Rauch wrote: https://rauchg.com/2015/pure-ui TL;DR: It's not about the HTML in Javascript; it's about being able to declare all the states of your UI in a stateless way. The result is that React components are like pure functions: you pass them inputs and you get predictable outputs.

This poor example of an SPA is not going to convince anyone that Single page apps are a good thing. I think if an SPA can achieve all of these http://rauchg.com/2014/7-principles-of-rich-web-applications/ with minimal additional payload, then it's good.

That post was from 2010. I think you vastly underestimate the difficulty of building from scratch rich, modern single-page apps that satisfy today's users' needs. Have a look at "7 Principles of Rich Web Applications" [1] by the creator of Socket.io, and at my comparison between Meteor and the MEAN stack [2]. By the time you've built a reliable data synch transport that watches the server database and pushes changes to clients over intermittent connections, then pushes changes from client back to servers when they reconnect, all this with access control, a Meteor developer will have built 10 proof-of-concept apps, determined the product-market fit, and have a working web app for users to use. [1]: http://rauchg.com/2014/7-principles-of-rich-web-applications/ [2]: http://wiki.dandascalescu.com/essays/meteor_js_vs_the_mean_stack