31–40 of 73 posts
Earlier quoted context omitted.
Did you even read the docs for this project? In my opinion, this pulls together different tools that improve developer experience dramatically. For me personally, hot reloading is quite useful.
Hot reloading is not exclusive to react. Live reloading has been around for about a decade and is compatible with everything that renders to a web browser.
Earlier quoted context omitted.
Some people prefer it as a templating tool (myself included). React also enables some of the features of the tool. For example, hot reloading the contents of the page while writing/developing, which may make for a smoother experience. If this isn't to your taste or doesn't fit your requirements, I'm sure the OP and author of the tool would not be offended if you continued to use Jekyll et al.
What is so special about hot reloading? Live Reload has been around for about a decade and it's compatible with everything that renders to a web browser. Am I missing something here?
In interactive contexts, it probably helps to keep the application in a single state while reloading, but I don't believe that applies here.
Over-engineering at it's finest. React is great for some applications, IMO this is not one of them. To me it just over complicates things for minimal gain.
Did you even read the docs for this project? In my opinion, this pulls together different tools that improve developer experience dramatically. For me personally, hot reloading is quite useful.
How hard is it to hit cmd-R? Or install a browser extension that reloads every n seconds? Do we really need to add complexity for this?
If it works for you, go for it! Call me lazy, but unless I can see a substantial, measurable increase to either the user or my experience without tradeoffs, I am not going to invest the time.
I'm pleasently surprised that the generated sites work just fine with JavaScript disabled (at least on the author's blog). Which on the other hand makes me wonder why I (as the visitor) need to download a 700KB JS blob that contains all blog posts, React and other things just to read the content. Without JS: 4 requests, 20 KB transferred, DOMContentLoaded @ 360ms With JS: 27 requests, 518 KB transferred, DOMContentLo…
As long as the top of the article content (headline + first few paragraphs) loads immediately I don't care if it loads 700kb afterwards for other interactive content. 'Progressive enhancement' should be the primary goal; size reduction is just one means to achieving that but not always required. From testing out one of the example blogs and this doesn't seem to be a UX issue: https://bricolage.io/tools-administer-fac…
Progressive enhancement would be making all of the content visible and accessible, then adding functionality on top after the base page load is complete. If JS is required to simply view the text on a page, you're doing it wrong.
PS: You can find the Gatsby Stay Static Sample Site @ http://staystatic.github.io/sites/gatsby and sources -> https://github.com/staystatic/gatsby
Earlier quoted context omitted.
Some people prefer it as a templating tool (myself included). React also enables some of the features of the tool. For example, hot reloading the contents of the page while writing/developing, which may make for a smoother experience. If this isn't to your taste or doesn't fit your requirements, I'm sure the OP and author of the tool would not be offended if you continued to use Jekyll et al.
What is so special about hot reloading? Live Reload has been around for about a decade and it's compatible with everything that renders to a web browser. Am I missing something here?
It's clever. It's well done. I'm not the audience, though. I love React for, you know, "Reactive UI", the "V" of an "MVC" app, but when creating the site's content store (the "static API backend") is a "build" time event, I don't feel that there is anything to "react" to.
It's clever. It's well done. I'm not the audience, though. I love React for, you know, "Reactive UI", the "V" of an "MVC" app, but when creating the site's content store (the "static API backend") is a "build" time event, I don't feel that there is anything to "react" to.
Well, I suspect user interaction is what it would react to.
The model isn't changing state. The controller is translating the same static content over and over. Browsers already do that in "reacting" to user's event inputs, e.g. onclick.
Earlier quoted context omitted.
As long as the top of the article content (headline + first few paragraphs) loads immediately I don't care if it loads 700kb afterwards for other interactive content. 'Progressive enhancement' should be the primary goal; size reduction is just one means to achieving that but not always required. From testing out one of the example blogs and this doesn't seem to be a UX issue: https://bricolage.io/tools-administer-fac…
That's not progressive enhancement, it's lazy loading. Progressive enhancement would be making all of the content visible and accessible, then adding functionality on top after the base page load is complete. If JS is required to simply view the text on a page, you're doing it wrong.