11 ms·

It seems contradictory to me that author learned to "deliberately assess cutting edge technologies, bias towards conservative choices," yet he regrets not using

It seems contradictory to me that author learned to "deliberately assess cutting edge technologies, bias towards conservative choices," yet he regrets not using react-native-web and Next.js.

j2kun 8y ago
Wait until the author hears about react-native-web-native, the go-to solution for using your react-native-web components in a native environment!
- sephoric 8y ago
  I honestly can't tell from your comment if that really exists or is satire.
  - kbenson 8y ago
    Neither can I. I'm I'm leaning towards it existing but being used as a vehicle of satire, because that's just how crazy the world is now.
    - navs 8y ago
      https://github.com/necolas/react-native-web https://github.com/necolas/react-native-web
      - stronglikedan 8y ago
        I don't know why I find it so funny that the browser's back button doesn't work in the examples[0]. [0] https://necolas.github.io/react-native-web/examples/ https://necolas.github.io/react-native-web/examples/
        ollerac 8y ago
        Because re-implementing native browser features that are core to an application's usability is a hard problem that "cutting edge" web frameworks open you up to?
        ksec 8y ago
        My hope is that LiveView from Phoenix, ( along with some form of Mobile Apps Default Solution ) would finally fix 90% of what we need without ever touching / resorting to what we are doing on the client side right now. Finger crossed.
        semi-extrinsic 8y ago
        Also that the examples are broken right to frack... Screenshot: https://boring.host/MWDuAnO https://boring.host/MWDuAnO
      - deleted 8y ago
        [deleted]
  - quickthrower2 8y ago
    Satire, because react-native-web-native === react-native, so there is no need for such a module
    - anyfoo 8y ago
      In the same way that react-native-web should be "react"?
      - deleted 8y ago
        [deleted]
      - threeseed 8y ago
        Sure. In an ideal world programming would be the same irrespective of whether it's Web, iOS, Android, Server Side etc. But because the platforms are quite different you have different libraries and programming models. Hence why React is not the same as React-Native-Web.
        growtofill 8y ago
        This doesn’t answer the question.
      - invaliduser 8y ago
        It is based on React, it is basically a react implementation of many react-native specific components, such as View.
- hinkley 8y ago
  We've only got two more years on this hype cycle, right?
mharroun 8y ago
React has become the most popular way to build front ends that are interactive. Many sites still need rendering on the server side for SEO purposes (CSR and SEO do not mix). So when your content needs to be highly indexable but has many interactive elements SSR react seems like a good choice. In this scenario, Next.js is the most "standardized" choice.
- mr_toad 8y ago
  React can render static markup without additional frameworks. You can basically run your React code in Node.js and either cache the HTML to disk or have it run on request. ReactDOMServer.renderToStaticMarkup();
  - mharroun 8y ago
    This ignores the "has many interactive elements" part of my comment. Having server-side render react code that can also hydrate and then be interactive (or at least parts of it) is not that simple.
    - mpeg 8y ago
      Hydration is also built-into React [0] I'm curious about what you consider complex about an SSR setup with React, I'm becoming very familiar with the internals of React and frameworks like Next and they're often relatively thin wrappers over the built-in features. [0]: https://reactjs.org/docs/react-dom.html#hydrate https://reactjs.org/docs/react-dom.html#hydrate
- geofft 8y ago
  If I can ask a somewhat ignorant question... is there no way to render a traditional HTML page from a normal (Django/Rails/PHP-style) server-side template, and then add React on top for interactivity? Is it that everything has to be built in React and it can't work with exising DOM elements? or just that it's easier to do everything in React and not have a separate static template, or something? Is the answer any different for React Native? (I guess you lack a server-side renderer at that point, so maybe it's easier to plan to do everythig in React if you plan on using React Native?)
andrewingram 8y ago
I find the regret for not using Next.js to be interesting, because I don't think it would have been a particularly good fit anyway. I've built an relatively high-traffic SSR'd React website from scratch, and I've done the prototype for the rebuild of the website at work (we're moving away from Gatsby). The reason I'm considering Next is precisely because what i'm building isn't a "web app" like Spectrum, but merely a website (with some e-commerce features). The sweet spot for Next.js seems to be that you're trying to make something that resembles a traditional pre-React-era website in structure, but just happens to be built using React. Once you're building an app, it doesn't feel like the best tool for the job. You can obviously bend Next to your needs, but fighting the framework is the last thing you want to be doing in the first year of a startup's life. They managed to get an exit, which is a great result. And obviously they've learned a lot in the process which is another great outcome. But I can't help but feel that having just one experienced engineer on the team would have made their road a lot less bumpy.
- tuesdayrain 8y ago
  Out of curiosity, what was your reason for moving away from Gatsby? I found it very pleasant to work with. I actually moved from Next to Gatsby for personal projects because it felt more intuitive for me, and I like the plugins that they offer.
  - rozenmd 8y ago
    Not the OP, but Gatsby works well for sites that rarely change content. For e-commerce sites with >100 SKUs + variants, having to rebuild every single time you make a description update is pretty tedious, and Next.js seems to be the solution in that case.
    - mpeg 8y ago
      It's only tedious if the build is not automated, static site generators work pretty well with continuous delivery practices though.
    - deltron3030 8y ago
75dvtwin 8y ago
I do not think author contradicts himself at all. If they would have used react-native-web, he would have saved some time writing the Android (or IOS) apps. Because he could have reused the code (he said that too). This is what I have done, anyway. Also react-native-web is very very high quality library. I am just amazed at the quality Nicolas Gallagher is putting out. My app now runs on web and via browser on android/ios with all the magic of responsive UIs, reshaping all those positions when a user rotates the screen or zooms out. I am wondering, on occasion why I spent time on native apps (even with React Native) -- at all, as React Native Web (with a bit of React-bootstrap) -- are just amazing. Wrt next.js, at least when I looked at it mid last year, did not support routing with React-router. And for me it was a big deal, I did not want spend time on learning specifics next-js routing. Instead I went with https://github.com/jaredpalmer/razzle https://github.com/jaredpalmer/razzle which supports React Router for routing, which I use Android/react-native and React-native-web, uniformly. React-router, is also very good and useful library with nice, intuitive architecture for routing. At the end, I decided for my need the Server Side rendering is a later-stage item. So I have not spend more time on it. I suspect Spectrum did not loose much traffic because their app is not using SSA routes. Zulip chat app (may be they are spectrum's competitor, not sure) - uses React Native for mobile (https://github.com/zulip/zulip-mobile https://github.com/zulip/zulip-mobile ), but something else for web. As a reference.
- vishnu_ks 8y ago
  So the reason why Zulip doesn't use React for the web app is that there was no React(at least not available for public) when Zulip started out in 2012. The Javascript frameworks which did exist in 2012 no longer exists or is not used by anyone anymore. Zulip still uses jQuery with some internal abstractions. The reason why Zulip decided to use React Native for mobile app was probably it was much easier to have a single codebase than maintaining a different codebase for Android and iOS. Same reason for using Electron for Desktop app. That said we have been talking about the possibility of using a Javascript framework for Zulip web app for a while now but we have not found a good enough reason to make the switch yet. See the following link for more details https://chat.zulip.org/#narrow/stream/6-frontend/topic/vue.20upgrade https://chat.zulip.org/#narrow/stream/6-frontend/topic/vue.2...
jondubois 8y ago
I wouldn't trust any 'open source' project which has received funding from investors (especially early stages) - These projects are almost always hype-driven. They're popular because the team is good as social networking; they mostly leverage their blogger friends to do writeups and spam tweeter until people believe it.

It seems contradictory to me that author learned to "deliberately assess cutting edge technologies, bias towards conservative choices," yet he regrets not using react-native-web and Next.js.

j2kun 8y ago

Wait until the author hears about react-native-web-native, the go-to solution for using your react-native-web components in a native environment!

sephoric 8y ago
I honestly can't tell from your comment if that really exists or is satire.
- kbenson 8y ago
  Neither can I. I'm I'm leaning towards it existing but being used as a vehicle of satire, because that's just how crazy the world is now.
  - navs 8y ago
    https://github.com/necolas/react-native-web https://github.com/necolas/react-native-web
    - stronglikedan 8y ago
      I don't know why I find it so funny that the browser's back button doesn't work in the examples[0]. [0] https://necolas.github.io/react-native-web/examples/ https://necolas.github.io/react-native-web/examples/
      - ollerac 8y ago
        Because re-implementing native browser features that are core to an application's usability is a hard problem that "cutting edge" web frameworks open you up to?
        ksec 8y ago
        My hope is that LiveView from Phoenix, ( along with some form of Mobile Apps Default Solution ) would finally fix 90% of what we need without ever touching / resorting to what we are doing on the client side right now. Finger crossed.
      - semi-extrinsic 8y ago
        Also that the examples are broken right to frack... Screenshot: https://boring.host/MWDuAnO https://boring.host/MWDuAnO
    - deleted 8y ago
      [deleted]
- quickthrower2 8y ago
  Satire, because react-native-web-native === react-native, so there is no need for such a module
  - anyfoo 8y ago
    In the same way that react-native-web should be "react"?
    - deleted 8y ago
      [deleted]
    - threeseed 8y ago
      Sure. In an ideal world programming would be the same irrespective of whether it's Web, iOS, Android, Server Side etc. But because the platforms are quite different you have different libraries and programming models. Hence why React is not the same as React-Native-Web.
      - growtofill 8y ago
        This doesn’t answer the question.
    - invaliduser 8y ago
      It is based on React, it is basically a react implementation of many react-native specific components, such as View.
hinkley 8y ago
We've only got two more years on this hype cycle, right?

mharroun 8y ago

React has become the most popular way to build front ends that are interactive. Many sites still need rendering on the server side for SEO purposes (CSR and SEO do not mix). So when your content needs to be highly indexable but has many interactive elements SSR react seems like a good choice. In this scenario, Next.js is the most "standardized" choice.

mr_toad 8y ago
React can render static markup without additional frameworks. You can basically run your React code in Node.js and either cache the HTML to disk or have it run on request. ReactDOMServer.renderToStaticMarkup();
- mharroun 8y ago
  This ignores the "has many interactive elements" part of my comment. Having server-side render react code that can also hydrate and then be interactive (or at least parts of it) is not that simple.
  - mpeg 8y ago
    Hydration is also built-into React [0] I'm curious about what you consider complex about an SSR setup with React, I'm becoming very familiar with the internals of React and frameworks like Next and they're often relatively thin wrappers over the built-in features. [0]: https://reactjs.org/docs/react-dom.html#hydrate https://reactjs.org/docs/react-dom.html#hydrate
geofft 8y ago
If I can ask a somewhat ignorant question... is there no way to render a traditional HTML page from a normal (Django/Rails/PHP-style) server-side template, and then add React on top for interactivity? Is it that everything has to be built in React and it can't work with exising DOM elements? or just that it's easier to do everything in React and not have a separate static template, or something? Is the answer any different for React Native? (I guess you lack a server-side renderer at that point, so maybe it's easier to plan to do everythig in React if you plan on using React Native?)

andrewingram 8y ago

I find the regret for not using Next.js to be interesting, because I don't think it would have been a particularly good fit anyway. I've built an relatively high-traffic SSR'd React website from scratch, and I've done the prototype for the rebuild of the website at work (we're moving away from Gatsby). The reason I'm considering Next is precisely because what i'm building isn't a "web app" like Spectrum, but merely a website (with some e-commerce features). The sweet spot for Next.js seems to be that you're trying to make something that resembles a traditional pre-React-era website in structure, but just happens to be built using React. Once you're building an app, it doesn't feel like the best tool for the job. You can obviously bend Next to your needs, but fighting the framework is the last thing you want to be doing in the first year of a startup's life. They managed to get an exit, which is a great result. And obviously they've learned a lot in the process which is another great outcome. But I can't help but feel that having just one experienced engineer on the team would have made their road a lot less bumpy.

tuesdayrain 8y ago
Out of curiosity, what was your reason for moving away from Gatsby? I found it very pleasant to work with. I actually moved from Next to Gatsby for personal projects because it felt more intuitive for me, and I like the plugins that they offer.
- rozenmd 8y ago
  Not the OP, but Gatsby works well for sites that rarely change content. For e-commerce sites with >100 SKUs + variants, having to rebuild every single time you make a description update is pretty tedious, and Next.js seems to be the solution in that case.
  - mpeg 8y ago
    It's only tedious if the build is not automated, static site generators work pretty well with continuous delivery practices though.
  - deltron3030 8y ago

75dvtwin 8y ago

I do not think author contradicts himself at all. If they would have used react-native-web, he would have saved some time writing the Android (or IOS) apps. Because he could have reused the code (he said that too). This is what I have done, anyway. Also react-native-web is very very high quality library. I am just amazed at the quality Nicolas Gallagher is putting out. My app now runs on web and via browser on android/ios with all the magic of responsive UIs, reshaping all those positions when a user rotates the screen or zooms out. I am wondering, on occasion why I spent time on native apps (even with React Native) -- at all, as React Native Web (with a bit of React-bootstrap) -- are just amazing. Wrt next.js, at least when I looked at it mid last year, did not support routing with React-router. And for me it was a big deal, I did not want spend time on learning specifics next-js routing. Instead I went with https://github.com/jaredpalmer/razzle https://github.com/jaredpalmer/razzle which supports React Router for routing, which I use Android/react-native and React-native-web, uniformly. React-router, is also very good and useful library with nice, intuitive architecture for routing. At the end, I decided for my need the Server Side rendering is a later-stage item. So I have not spend more time on it. I suspect Spectrum did not loose much traffic because their app is not using SSA routes. Zulip chat app (may be they are spectrum's competitor, not sure) - uses React Native for mobile (https://github.com/zulip/zulip-mobile https://github.com/zulip/zulip-mobile ), but something else for web. As a reference.

vishnu_ks 8y ago
So the reason why Zulip doesn't use React for the web app is that there was no React(at least not available for public) when Zulip started out in 2012. The Javascript frameworks which did exist in 2012 no longer exists or is not used by anyone anymore. Zulip still uses jQuery with some internal abstractions. The reason why Zulip decided to use React Native for mobile app was probably it was much easier to have a single codebase than maintaining a different codebase for Android and iOS. Same reason for using Electron for Desktop app. That said we have been talking about the possibility of using a Javascript framework for Zulip web app for a while now but we have not found a good enough reason to make the switch yet. See the following link for more details https://chat.zulip.org/#narrow/stream/6-frontend/topic/vue.20upgrade https://chat.zulip.org/#narrow/stream/6-frontend/topic/vue.2...

jondubois 8y ago

I wouldn't trust any 'open source' project which has received funding from investors (especially early stages) - These projects are almost always hype-driven. They're popular because the team is good as social networking; they mostly leverage their blogger friends to do writeups and spam tweeter until people believe it.