121–130 of 213 posts
Earlier quoted context omitted.
[deleted]
" Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something. " https://news.ycombinator.com/newsguidelines.html
Earlier quoted context omitted.
" Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something. " https://news.ycombinator.com/newsguidelines.html
It's a dismissal for sure, but the original comment doesn't read as shallow to me.
Then I saw that the content preview feature was $50 / month - and it’s not even integrated yet with my CMS of choice.
How can teams accept to let go of such fundamental features? I love the React dev experience as much as the next guy, but I certainly can’t find a way to justify this to my clients...
I would not recommend to use Gatsby in a project if it requires a frontend with complexity beyond static-scrollable content. Some problems that I found after some months of integrating it with an existing CMS: * Development complexity: depending if Gatsby is run on development or production mode, React's `render` methods are called in the browser or inside NodeJS. Having this code executed in a Node process is expect…
Out of interest, what's good about building static websites with React?
Earlier quoted context omitted.
I take issue with your tone and cynicism, and disagree w/ your premise. Your sarcasm and condescension aren't helpful. And there's no way your "couple hundred lines of code" addressed more than a fraction of the real-world use cases addressed by Gatsby. You cast aspersions on a huge swath of your peers who work with the best tools at hand to solve difficult problems... it's not just arrogant, it's ignorant. IME it's…
Except a couple hundred lines of code could address the issues that Gatsby addresses. The posters here aren't wrong. It is an overhyped, overbloated, overconfig heavy stack that ultimately renders static html. I have used them, they are exactly as these posters say.
Question tangential to Gatsby for those of you who use such static site builders as blogs: are there any good tools for writing/composing posts or are you all doing it by hand? I have set up the same blog maybe 3 times and I always stop posting because I need to be in my coding environment to do so (and if I'm there, I might as well be working on code). I'd really like to find something that I could use to make a pos…
Full disclosure: I‘m a Developer Evangelist for Contentful A “Headless CMS” is one way to achieve what you’re looking to do. Contentful is one, there are others. Gatsby’s has source plugins for all popular ones. They have a nice getting started guide for Gatsby + Contentful: https://www.gatsbyjs.org/docs/sourcing-from-contentful/
I would not recommend to use Gatsby in a project if it requires a frontend with complexity beyond static-scrollable content. Some problems that I found after some months of integrating it with an existing CMS: * Development complexity: depending if Gatsby is run on development or production mode, React's `render` methods are called in the browser or inside NodeJS. Having this code executed in a Node process is expect…
I don't get it, is this some Gatsby limitation? I've been debugging JSX since the dawn of time with breakpoints, even with SSR and typescript
I would not recommend to use Gatsby in a project if it requires a frontend with complexity beyond static-scrollable content. Some problems that I found after some months of integrating it with an existing CMS: * Development complexity: depending if Gatsby is run on development or production mode, React's `render` methods are called in the browser or inside NodeJS. Having this code executed in a Node process is expect…
> JSX code is hard to debug, because the code that is really executed is generated at runtime, so it is not possible for example, to put a breakpoint in a JSX file from your text editor and start a build with Node running in debug mode I don't get it, is this some Gatsby limitation? I've been debugging JSX since the dawn of time with breakpoints, even with SSR and typescript
Gatsby's docs on debugging HTML builds [1] give you adhoc solutions for specific problems you may have, but 0 info on actually debugging.
Earlier quoted context omitted.
I take issue with your tone and cynicism, and disagree w/ your premise. Your sarcasm and condescension aren't helpful. And there's no way your "couple hundred lines of code" addressed more than a fraction of the real-world use cases addressed by Gatsby. You cast aspersions on a huge swath of your peers who work with the best tools at hand to solve difficult problems... it's not just arrogant, it's ignorant. IME it's…
As someone who has both used Gatsby and written custom static HTML generators, I do feel that Gatsby is far more complex than it needs to be. > there's no way your "couple hundred lines of code" addressed more than a fraction of the real-world use cases addressed by Gatsby Gatsby on its own doesn't actually do much. There are plugins to do most useful things. Here's an example: https://www.gatsbyjs.org/packages/gatsb…
It's also not too surprising to hear that it doesn't support code highlighting out of the box in React given it's a plugin for Gatsby's remark plugin.
However, because we added prismjs as a dependency, you can still use it in React without hacking it with `dangerouslySetInnerHtml` so no idea where you got that idea from: https://pathof.dev/blog/code-highlighting-in-react-using-pri...