[HN Gopher] Launch HN: Weweb.io (YC W21) - Create websites visua...
       ___________________________________________________________________
        
       Launch HN: Weweb.io (YC W21) - Create websites visually using
       JAMstack tools
        
       We're Raphael, Florian and Marc, co-founders of weweb.io
       (https://www.weweb.io/). We are building a Webflow/WordPress style
       product, but where users can drag & drop their own React/Vue
       components and use data fetched from any API.  We started working
       together on a side project in 2016, it was a mobile app in rails
       that lets people choose music in their favourite bars. The app
       didn't bring much value to bar owners, but it was fun to build and
       we made good friends among our first customers. Aside from our jobs
       we loved spending time building and iterating on different web
       products, we even built a simple angular web-app that would let
       anyone create a website entirely from a mobile phone.  Fast-forward
       to 2018, we stumbled upon the Jamstack ecosystem and loved it. But
       one thing surprised us so much that we decided to quit our jobs to
       solve it: while many developers were switching their websites to
       the Jamstack, businesses were (almost) always pushing to go back to
       WordPress or no-code systems because Jamstack sites didn't come
       with a no-code interface to update the front-end.  The thing is,
       even with headless CMSes, most changes on a website still need to
       be addressed by engineers, who usually don't have the time to do
       it. This situation frustrates marketers, who then argue against
       their developers' technical choices.  That's why we built weweb.io,
       to allow developers to use their favorite Jamstack tools while
       providing a nice GUI so marketers can edit their websites in
       autonomy.  The main uses-cases where people find weweb.io useful
       are 1) when they want to ship websites fast, with a no-code tool
       that's not a black-box for developers, 2) when they want to create
       websites at scale (hundreds of landing pages) with data coming from
       an external back-end (API, database, Headless CMSes, Airtable,
       etc.) or 3) when they have a custom React/Vue front-end and want to
       let marketers iterate faster on it.  We currently have integrations
       to fetch data from Airtable, Google Sheets, Ghost CMS, Strapi and
       any REST API. We are planning to release more integrations in the
       following months.  We have a free plan where users can build a site
       and redirect on their own domain name for free! We start charging a
       recurring fee when these sites are becoming more mature (more than
       500 visits / month)  To deploy a site, users hit a "publish" button
       and we pre-render the site, optimize the images and deploy the
       files on a CDN (Cloudfront). We are planning on opening the
       deployment system so developers can use their favorite platform
       (Netlify, Vercel, or anything) and choose their favorite SSR/SSG
       (Next, Gatsby, Nuxt, Gridsome, etc.).  We currently support
       uploading Vue.js components from GitHub out-of-the-box, and make
       the props editable in our GUI thanks to a simple config file in the
       component.  Furthermore, we're working on improving our support for
       React. On this subject, we would be interested to get your feedback
       on how to interpret React from a Vue app. We tinkered with
       libraries like https://github.com/akxcv/vuera and were hoping to
       not have to rewrite our whole app using React. If you people have
       any advice on this, we would be more than happy to hear it!  We
       would also love to hear your feedback about the tool. Feel free to
       give it a spin at https://www.weweb.io/
        
       Author : raphael-gold
       Score  : 148 points
       Date   : 2021-02-24 09:13 UTC (13 hours ago)
        
       | domano wrote:
       | I've been whishing for a CMS like that, but i would prefer
       | something selfhosted though. Headless CMSes are not customer
       | friendly at all.
        
         | raphael-gold wrote:
         | I understand. When you say self-hosted you are talking about
         | the websites generated or the full app?
        
       | Gys wrote:
       | Pricing depends (also) on number of visitors, for example, the
       | free tier includes 500 visits per month.
       | 
       | So this is hosted by you? This is a tool/service in the space of
       | squarespace, weebly and such?
        
         | raphael-gold wrote:
         | yes for the free tier we host the website. Starting from the
         | paying tiers we enable self-hosting. Today it is still an on-
         | demand feature but we are planning to enable self-hosting in
         | self-service before the summer. We also plan to have one-click
         | integrations with Netlify and Vercel (we are in discussion with
         | them at the moment).
         | 
         | Yes, the tool is in the space of no-code site builders, we
         | typically see users choosing weweb when they've outgrown their
         | regular site builders like Webflow, Wix or Squarespace and want
         | more customization options.
        
           | mekkkkkk wrote:
           | When it comes to the per-visit limits, what exactly counts as
           | a visit? Being crawled and indexed can quickly consume hits
           | if they are simply renderings of the page. Even the business
           | tier seems really limited if that is the case. Especially for
           | 100$ a month.
        
             | raphael-gold wrote:
             | that's a good point, we are currently discussing this with
             | our early adopters to find the right balance. We might
             | increase this per-visit limits. What would be a fair limit
             | for the business plan according to you?
        
               | mekkkkkk wrote:
               | If you could use heuristics to discard automation such as
               | search engine indexing and open graph lookups, then the
               | limit is probably fine. I'm not sure I'm a fan of the
               | pricing model in general though.
               | 
               | If I were you, I'd look into smart caching, traditional
               | (high and scaling) bandwidth limits, and instead applying
               | tier limits on updates/edits/data pulls. More user
               | friendly, more generous for smaller projects and slightly
               | less open for exploits. In the current model (with no
               | heuristics), you could shut down one of your customers in
               | 5 min just using curl.
        
               | raphael-gold wrote:
               | Yes that makes sense. Though, it would be hard to apply
               | edits limits because the number of edits can vary
               | greatly, independently from the purchasing power of a
               | customer (for example a startup would change it's home
               | page every other day while a large corporate would barely
               | touch it once a quarter). The bandwidth or page views
               | limits seem to be raising the same issue and the logic
               | for us is simply to avoid server costs that would be too
               | high for a single site that would pay a basic monthly
               | subscription.
        
               | mekkkkkk wrote:
               | If a large company is not updating their site very often,
               | then you do not have a great value proposition anyway.
               | Your core product is ease of updating/editing and
               | customization, no? Makes sense to charge based on that
               | aspect.
               | 
               | Of course you need some sort of traffic restriction for
               | things not to spiral out of control. Putting this
               | restriction on actual MB's transferred is an acceptable
               | safeguard. Cache bandwidth is cheap using the right
               | strategies, so your bounds could be pretty high while
               | keeping it profitable.
        
               | raphael-gold wrote:
               | cool, great feedback. We'll look into implementing
               | bandwidth restriction instead of page view, I had the
               | same conversation with an agency yesterday and they were
               | leaning toward your point of view.
        
       | samtimalsina wrote:
       | I have felt the need for this before, and wanted to work on it as
       | a side project. Congratulations on launching! I will be watching
       | your growth.
        
         | raphael-gold wrote:
         | cool that you felt there should be a solution to this problem
         | too. Let us know what you think about the tool, I'd happily
         | share point of views on how to solve this problem.
        
       | sandGorgon wrote:
       | I would love to see a Next SSR output here. This would be killer
       | !
        
         | raphael-gold wrote:
         | I discussed this with the guys at Vercel a few weeks ago, this
         | is definitely something we'll look into when we improve our
         | React support. We'll also enable a one click deployment to
         | Vercel so you can do a Next SSR + deployment on Vercel in one
         | click. This should be possible by the end of Q3 this year.
        
       | bwghughes-fth wrote:
       | I'm afraid Editor doesn't load in Safari. I get a 403 when
       | loading the editor.
        
         | raphael-gold wrote:
         | whoops! yes sorry the editor only works with chromium based
         | browsers. We will add a message to let users know!
        
           | raphael-gold wrote:
           | we are also planning to expand support to other browser
           | engines as we grow :)
        
       | ath92 wrote:
       | Looks really cool. Out of curiosity, how did you build the real-
       | time collaborative aspect of your editor? Is it built on some
       | existing tools, or did you build that part from scratch?
        
         | raphael-gold wrote:
         | The collaborative feature is built from scratch :D It works
         | with WebSockets. At the beginning we used WebSockets to enable
         | autosaving and undo (ctrl+z) in the no-code editor: we save all
         | the actions happening on the elements with unique IDs. Once
         | this was done, it was much easier to add the collaborative
         | feature.
        
       | imgermi wrote:
       | Great product. At first I was kinda skeptical about it. My
       | initial reaction was "hmm ok, another one of this no code tools
       | competing with Webflow".
       | 
       | The market is slowly getting crowded. Webflow has been growing
       | like crazy. And Wordpress creators are not falling behind. Divi
       | and Elementor are constantly improving their products, they have
       | a huge community, and they just work.
       | 
       | Spoiler: Weweb hits the problem very well.
       | 
       | I've been lucky enough to play around with it for the past few
       | weeks. The number one thing I looked for was not all the fancy
       | tools for Vue js, design systems and headless integrations (even
       | though my team needs them). It was not feeling overwhelmed
       | whenever I'd need to use it.
       | 
       | That's what happens to me with tools like Wordpress. Every time I
       | have to update a Wordpress site at scale I'm like "shit, here we
       | go again".
       | 
       | They nail it at this pain point. Weweb is dead simple, and it
       | just works.
       | 
       | I'm excited to give this a shot at scale, using a large design
       | system, updating data regurarly with a tool like Airtable, and
       | using custom components with Vue Js.
       | 
       | Great work Weweb folks!
        
         | raphael-gold wrote:
         | oh wow, thank you. You are comparing us with giants and I feel
         | we still have a lot of work to do on the editor to catch up
         | with them. But we are working hard to ship improvements fast!
         | Feedback are always welcomed, that's how we improve, so, much
         | love for our early adopters <3
        
       | alex-wallish wrote:
       | This is really cool, congrats on the launch! Is there any way to
       | add authentication currently?
        
       | 0xferruccio wrote:
       | I've used Contentful, Strapi, Ghost, Wordpress, Webflow and
       | Netlify CMS in the past so I think I might have a good
       | perspective on this. I think all those tools fall short when you
       | want to make a site with 90% standard components and then one or
       | two interactive custom React components with some Framer motion
       | effects.
       | 
       | I've played around a bit with this product and it looks like it
       | does a good compromise between flexibility and ease of use. As
       | I'm redesigning my company's site in the next weeks I think I'll
       | give this a try
        
         | raphael-gold wrote:
         | yes, from a no-code edition perspective, it is the problem we
         | are trying to solve. We've seen a lot of users frustrated by
         | their regular site builders because they couldn't do this extra
         | 10% of customization. Another frustration we've seen is that
         | websites built with regular no-code builder live in isolation
         | from the content ecosystem of the company (headless cms, custom
         | back-end / database, etc.). While testing feel free to let us
         | know if you need an integration with one of the cms mentioned
         | above. We don't have Contentful, WP nor Netlify yet but they
         | are on the list :)
        
       | mintone wrote:
       | Great work on launching! I would be interested to know who the
       | target market is - if you're technically competent enough to know
       | your react from your vue how likely are you to use a visual
       | builder? I'm speaking from a technical background, but also
       | webflow etc haven't clicked for me so maybe I just prefer the had
       | way. The airtable integrations etc; I know people who would LOVE
       | that and wish they could run their entire lives from the platform
       | so that's a winner. Sort of in the same way as you used to see
       | people pushing excel to be the "everything" tool, people are now
       | doing with airtable, so giving a nice front end of just running
       | the site out of there is great. Well done guys!
        
         | raphael-gold wrote:
         | We've typically seen technical people using weweb.io when they
         | want to collaborate on the website with non-technical people
         | (their content creators or marketing team). Interestingly, we
         | see teams splitting the work on the website as follows:
         | developers build custom components and upload them from Github
         | on the editor, then marketing people build the pages and edit
         | the content in autonomy, so developers are involved only for
         | highly custom front-end elements. You are right about the
         | Airtable integration, it is the most used feature of our tool
         | so far :D together with the custom vue.js components
         | integration.
        
         | amitport wrote:
         | Even if you have a team of react developers. Faster is still
         | faster. The cycle of design-code-feedback can be much quicker
         | with such tools.
         | 
         | Your react developers can spend more time on custom components,
         | more complex flows, etc.
        
           | raphael-gold wrote:
           | yes, we've seen that one of the drivers for choosing our tool
           | is often a shorter time to market and faster iteration
           | cycles.
        
       | tobr wrote:
       | I feel like you wrote a better pitch for it here than on the
       | website. It's certainly a pain I've ran into many times: building
       | on tech that devs prefer leads to a situation where only devs can
       | make certain changes, something they often don't enjoy doing,
       | while other team members wish they could just do it quickly
       | themselves. Frustration all around.
       | 
       | It sounds like a thing that should be marketed to jamstack
       | developers who understand how this is different from, say,
       | Wordpress or Webflow, but that doesn't seem to be the main
       | audience of the communication on the site.
       | 
       | First impression from just watching the video is that it looks a
       | bit complicated, and that "marketers" (or whatever title the
       | person editing a site with this would have) might be confused if
       | their site is not set up in just the right way to fit weweb.
        
         | raphael-gold wrote:
         | that's interesting, we actually have a real difficulty here
         | because our buyers are either marketers or developers. As the
         | problem we are trying to solve is shared between them, both are
         | looking out for solution and we are having a hard time
         | positioning our marketing website's communication because of
         | this. Also, thanks for sharing your impression on the video!
         | When you say "if their site is not set up in just the right way
         | to fit weweb", do you mean that it feels like the editor won't
         | allow you to build custom layouts that fit with any design?
         | Your feedback is most welcomed!
        
           | tobr wrote:
           | > When you say "if their site is not set up in just the right
           | way to fit weweb", do you mean that it feels like the editor
           | won't allow you to build custom layouts that fit with any
           | design?
           | 
           | I find it a little hard to put this succinctly, but basically
           | as a dev I get a little nervous seeing all the features in
           | the UI. In my experience any complex editor like that _has_
           | to be designed around a bunch of assumptions about what kind
           | of site you're editing, and almost every slightly complex
           | real world site will have aspects that break those
           | assumptions. It could something subtle, like confusion around
           | terminology (imagine being a non-technical editor for a book
           | binding website, and seeing terminology about "bindings"), or
           | features that look like they should do something but for
           | whatever reason don't have any effect on the components in
           | use. The more complex the editor is, the more likely that
           | certain things will cause confusion when they meet the real
           | world.
        
             | raphael-gold wrote:
             | these are definitely real life example we experience every
             | day. It is hard to draw the line between simplicity and
             | customisability. For this our biggest inspiration is Figma.
             | It's amazing to see non-designers drawing things in Figma
             | without getting too many frustration together with
             | designers doing complex and very precise designs & design
             | systems without feeling limited.
             | 
             | Their interface feels easy to start with but can take you
             | very far if you need customization and scalability.
             | 
             | We are far from what they achieve, but that's where we'd
             | love the end up. :D
        
           | notahacker wrote:
           | Have you explored the simplest option: separate "Weweb for
           | devs" and "We web for marketers" landing pages, videos and
           | homepage subsections/columns/tags?
           | 
           | On the video: first impression is that it's heavily Weweb-
           | built template driven like another Squarespace (especially if
           | I stop watching in the first couple of mins before the bit
           | about design systems) whereas I assume from the description
           | in this thread that the design elements marketers can add and
           | what layouts/colours etc they can choose can be fully
           | configured by devs (and the target audience is teams that
           | want to do this) Ultimately I assume you plan on replacing
           | the tutorial on the home page with a video that's snappier,
           | more benefit-focused and more selective about UI examples
           | anyway?
        
             | raphael-gold wrote:
             | On the previous version of our website we actually
             | dedicated the home page to marketers and had a link in the
             | nav called "For Developers". The for developers page
             | started to rank on google on some requests like "visual
             | builder for react". We are revamping this page now and
             | we'll add it again on the site.
             | 
             | Thanks for the feedback on the video, it's really useful.
             | Makes me think that on the developer video we should
             | probably start from a blank site and add a custom component
             | in the editor right away.
        
       | pembrook wrote:
       | I think you've definitely identified the problem correctly. I've
       | complained about this problem before on HN, since it's the only
       | place where people are wise enough to not get swept up in the
       | latest hype train.
       | 
       | If you want to do any regular content marketing/blogging, custom
       | landing pages for SEO, a/b test copy, or even just update the
       | design of your site...Jamstack paired with an enterprisey
       | headless CMS is just an absolute freaking nightmare. I like to
       | joke that Jamstack is the fastest way to build a site that nobody
       | ever visits.
       | 
       | Literally every Saas company I work with has switched their
       | marketing site over to Webflow for this reason (especially since
       | most Saas companies get a majority of inbound leads through
       | content).
       | 
       | And they seem to be pretty happy with it! So I think you're
       | definitely on the right path.
       | 
       | I have none of the traditional armchair critiques for you. Just
       | keep doing what you're doing! Marketing sites should be easily
       | controlled by marketing people.
        
         | harrisreynolds wrote:
         | Agree. I recently refactored WeBase [1] to be 100% Jamstack
         | compliant so it can serve as the UI site builder for platforms
         | like Netlify.
         | 
         | But it is targeted at "no-coders" instead of coders given how
         | out of balance the supply and demand is for software
         | developers. We need more powerful tooling for professionals
         | without coding skill to be able to build and maintain.
         | 
         | And while Webflow is a really nice tool it still feels too hard
         | to use for non-developers.
         | 
         | [1] https://www.webase.com
        
           | raphael-gold wrote:
           | yay! good luck with webase, good vibes in the name too :D
        
         | raphael-gold wrote:
         | yes, that's a pattern that we saw as well! Teams migrating to
         | webflow or wordpress to give back the autonomy to marketers. We
         | also saw teams willing to migrate to the Jamstack from
         | squarespace sites or webflow sites but not doing it because it
         | would mean that marketers would lose their autonomy on the
         | front-end. We felt these pattern should be broken and that
         | Jamstack should be "marketer friendly" as well :)
        
         | FanaHOVA wrote:
         | There's a lot of tooling being built. uniform.dev and
         | outsmartly.com for personalization, GraphCMS for content
         | federation across data stores, etc. It's still pretty early
         | days for the ecosystem.
        
           | raphael-gold wrote:
           | Absolutely, the Jamstack ecosystem is just beginning.
        
             | harrisreynolds wrote:
             | I've built a competing tool but I will say I love what you
             | guys are doing with open sourcing some of your components
             | etc. Also love seeing Vue! It is game changer for us at
             | WeBase.
             | 
             | Lots of opportunity in this space... best of luck to you!
        
               | raphael-gold wrote:
               | good luck to you too!
        
       | jack_riminton wrote:
       | Makes a lot of sense. I was a contract PM for a company which
       | used Wordpress and off-shore devs to customise it and it was
       | pretty painful. Couple of observations:
       | 
       | 1. The Wordpress ecosystem is valuable because of the plugins.
       | How do you envisage enabling such an ecosystem? 2. The beauty of
       | React is with the components. An ideal end-state would be where a
       | non-techie searches and find a React component they like (without
       | having to go through Github) and they can add it to their WYSIWYG
       | editor without even needing to speak to a dev
       | 
       | Wish you all the best
        
         | raphael-gold wrote:
         | Oh wow this flow would be really cool! Both observations are
         | linked in a way: the WordPress ecosystem is really impressive
         | and we'd love to create something similar in the Jamstack
         | universe. To do that we are planning to open a "marketplace"
         | where users could find components, themes & plugins. So, if we
         | enable one-click integrations of components in a user's
         | library, I think you are right that it'd be better not to have
         | to link a Github account as most non-developers won't have one.
         | 
         | We will start working on the marketplace sometimes in Spring.
         | We'll probably have our power users contributing first and then
         | gradually open the marketplace to all the developers willing to
         | build for the community.
        
           | jack_riminton wrote:
           | Sounds exciting! is there a place to sign up for
           | contributors?
        
             | raphael-gold wrote:
             | Yes! Following your comment I just created a new page for
             | that (:D), you can sign up here:
             | https://www.weweb.io/partner-program/
        
               | jack_riminton wrote:
               | I just tried it but got a "something went wrong" error
        
               | raphael-gold wrote:
               | correct! It should be working now :)
        
       | winkelvoss wrote:
       | This is 100% where the website building ecosystem is going. As a
       | coder who knows just enough to be dangerous, I'm so excited about
       | it. I know http://stackbit.com/ has been doing this for a while.
       | What makes WeWeb guys different/better?
        
         | raphael-gold wrote:
         | great question! From my perspective, stackbit is made for large
         | corporates willing to add a no-code layer above an existing
         | Jamstack site. This provides additional customization option to
         | marketers compared to a headless CMS only.
         | 
         | Our approach is different because you would build your site
         | from scratch using weweb, which gives you much more
         | customization possibilities on the front-end than a stackbit,
         | but it would not be possible to add weweb "on-top" of an
         | existing react or vue website.
        
           | winkelvoss wrote:
           | huh, that's totally off. Stackbit enables visual editing from
           | a Jamstack site built from scratch too. Their visual editor
           | seems like it's better. And you could do a site from scratch,
           | with a theme or even just add it to your existing site. Neat
           | product. But don't see any value add to the ecosystem in it.
        
             | raphael-gold wrote:
             | To start with Stackbit I believe you need to start with one
             | of their themes and stackbit would be added on top of it.
             | While you can start from a blank page in our tool. In their
             | editor, the customization possibilities are limited in no-
             | code compared to a comprehensive no-code website builder.
        
       | fireeyed wrote:
       | The editor doesn't work on Safari 14 ?
        
         | raphael-gold wrote:
         | no unfortunately the editor supports only Chromium based
         | browsers but we are planning to expand support to other browser
         | engines as we grow :)
        
       | koolakalaban wrote:
       | Very cool! It seems like this is more the way things are moving.
       | Just out of curiosity, how did you get the big name companies on
       | your landing page to use your product if you just now launched?
        
         | raphael-gold wrote:
         | we actually "privately launched" 18 months ago and we knew some
         | people in these companies who had the problem we are trying to
         | solve - so they were willing to try us out. They gave us tons
         | of feedback, we improved the product thanks to that and we now
         | felt like it was a good time to launch publicly and get more
         | feedback from you folks :)
        
       | ROARosen wrote:
       | Looks amazing, just what I needed, but I was trying to add a
       | Google font and it just doesn't come up as that font when I
       | select it for use.
        
         | raphael-gold wrote:
         | oh yes, we will release a native integration soon, in the
         | meantime here is how to add a google font in your site:
         | https://www.loom.com/share/6d2156f99f024362a4286f648d255c7b
        
       | [deleted]
        
       | miyuks wrote:
       | Love weweb!!
        
       | MCorbani wrote:
       | Love it, go weweb.io!!
        
       | jerrygoyal wrote:
       | As far as I understood I could use both drag and drop editor as
       | well as code. If so, how's it handling css? do you handover
       | tailwind classes/bootstrap/just vanilla css.
        
         | raphael-gold wrote:
         | we handle CSS at component level, this means that you can add
         | custom css for every element or "section" (UI block) in the
         | site but not at site level. If you import your custom component
         | it can have its own CSS. We don't support adding CSS at site
         | level yet, but so far users didn't ask for it too often.
        
       | ROARosen wrote:
       | Congratulations! Are the finished-product sites exportable?
        
         | raphael-gold wrote:
         | yes they are exportable, but it is on a on-demand basis. Not so
         | many users asked for it yet, so we didn't build this feature in
         | self-service but it is in our backlog. We want to make sure
         | anyone can deploy the static files on their own infrastructure,
         | but we are just waiting for more demand to build it in self-
         | service. You can actually go upvote for it on our public
         | roadmap: https://weweb.canny.io/feature-requests
        
       | swyx wrote:
       | congrats on launching!
       | 
       | i confess i struggled to get the value proposition at first. i
       | tend to look for as simple as possible positioning. people can
       | get behind "no code", people can get behind Jamstack/"empowering
       | developers", but pitching the messy middle is very tricky in my
       | mind.
       | 
       | i think where i was swayed is less in the custom components part,
       | but more the integrations with airtable/other APIs. you might
       | have a decent shot of doing that better than wordpress and
       | webflow can (although both are formidable already). as a marketer
       | with some dev time i might find that very useful.
       | 
       | with the custom components piece, i'd lean into more of a
       | marketplace approach so that people can reuse components made by
       | others/pick them off the shelf, and people who maintain
       | components might even be able to make money from the weweb users
       | who are using them!
       | 
       | as for embedding React in Vue - what are the constraints to
       | simply mounting the React component on a DOM node rendered by
       | Vue? are you solving for SSR or something? its not clear from
       | your description what exactly you are struggling with.
        
         | raphael-gold wrote:
         | Yes, back-end integrations seem to be one of the main reasons
         | why users decide to adopt us. Being able to add their own
         | components is also one of the big reasons. Also, being able to
         | customize the front-end without limits also reassures
         | developers who were mainly interested in using back-end
         | integrations.
         | 
         | I really like your point of vue on the marketplace approach and
         | tend to agree. Most users will want off the shelf elements that
         | they can customize easily (especially marketers). We will start
         | working on the marketplace this Spring.
         | 
         | As for react in vue, our problem really lies into the pre-
         | rendering -> the main problem is that we have react in a vue.js
         | environment which can create performance problems and conflicts
         | between the two frameworks.
        
       | stanislavb wrote:
       | Who would you consider your top 3 competitors?
        
       ___________________________________________________________________
       (page generated 2021-02-24 23:01 UTC)