Hacker News new | ask | show | jobs
by detritus 2073 days ago
From https://www.makeswift.com/early-access:

> Can I host a Makeswift site elsewhere? > Makeswift code can't be exported. Every page created in Makeswift is securely hosted and served via Google Cloud.

I'm sorry, maybe I'm just being absolutist and cranky, but this doesn't sound to me like it's a 'website builder' - it's a tool that allows users to create presentations that can be displayed on the web.

I get why you'd go that route in the first place for 'non-coder' users, but locking them in to your ecosystem is, to me, antithetical to the culture of the web.

Of course - everyone does it, but it doesn't make it right.

4 comments

I don't think you're being absolutist or cranky at all. I think there's valid reasons why you would want to export your site.

I guess the reason we call ourselves a "website builder" is because Makeswift lets you build, well, websites. As for "presentations that can be displayed on the web", it's a bit more powerful than that. All components use to build Makeswift sites are React components and we are planning on opening that up so that third-party developers can create components any Makeswift user could drop in to their website.

As for lock-in, again, I think you make a fair point. In the long term we will probably have a self-hosting solution but it's something we're not focusing on at the moment. Most of our customers just want to focus on designing a website and then clicking a few buttons to have it live.

Thanks so much for your feedback :)

I'm reading through the first half of the article, which mostly tells some story about how a pain point might turn out, but I don't feel like that's really answering the "why _another_ website builder".

To really address that question, one needs to address the elephant in the room: wordpress. Thanks to over a decade head start, it's arguably the most advanced solution in the space. Wordpress and its ecosystem handle a myriad of business-focused things that make most attempts at React-based solutions look like toys. There are power user templates that let you configure pretty much every aspect of the site and then some, and if you want to defer, you can also find wordpress experts very very easily.

> All components use to build Makeswift sites are React components and we are planning on opening that up so that third-party developers can create components any Makeswift user could drop in to their website

I'm being a bit facetious, but why would you need this if marketers can control everything already? :-)

Hah, all good. We give them _visual_ control of everything. But say you wanted to make a component that pull the last 10 tweets from an account or a Stripe Checkout button or some other custom component, then you can.

Any React component is already a Makeswift component, the question is, how do you get the props? Well we've got a whole bunch of what we call prop controllers for basic stuff like numbers, colors, images, padding, margin, etc. You can also make your own. For example, in the Twitter feed component, you might make a panel that lets you search for tweets and then once you pick the account it passes the Twitter username to the component as a prop. The component can then fetch the tweets using the Twitter API, etc.

We have plans to open source all of our components as a reference for third-party developers building their own custom Makeswift components. Also, if you're a company that already has an internal design system built in React, your marketing team can just drop those in to your Makeswift site (constrained by the props the developers decide to expose).

This is all internal right now, though. I can't wait until we can release this API to the public, haha.

Dumb question. Does React matter in using the service - like an advantage of something like wordpress or shopify?
It will give us the opportunity to let developers build their own components, allow us to use frameworks like Next.js to power our users' sites, and let us leverage the ecosystem to build cool components and integrations. So as far as the end-user is concerned this should result in better performance, more options for components, and easier extensibility if they are developers.
This might be a sticking point to adopting your service for some stakeholders, not so much because they actually need to export the website anywhere but because the business model of so many website builders seems to be 'regret'.
Yeah, that's a no from me, dawg.
No, you are right on. It's really a bespoke to techstars_ solution for Google Cloud. When I think I web, I think HTML and HTTP and all the resources that can be accessed under those two. Note, the web can also be SFTP and a plethora of other resources.

The lock-in here is created by a clever use of the word "Web." It's the same use that allowed marketers at Netscape to call LiveScript JavaScript because it would sell better by bandwagoning on Java. We all know how that went: decades of new users confusing JavaScript and Java. The same mistake is made here by confusing users betweent Makesswift and Swift!

The Web Remembers!

Javascript could interact with, script if we are being charitable, Java applets through LiveConnect.
I consider Shopify a website builder, but I can't export my website to other hosting services.
Also Wix, Squarespace, and Weebly.

I didn't realize that all these services are actually presentations and not websites. Whatever that means.

The value of a tool like this without the backend and infrastructure is minimal. If you need to setup your own host and generate new HTML/CSS every time you'd like to update the site, the market for this product drops close to zero.

You could use their APIs to pull your product catalog out, but IIRC their terms of service says that's not allowed if you're migrating to another system.

l.o.l.

Yeah, you can't do that right now. But we do have plans to support self-hosting. We believe it will be table stakes for various customers.

We're a small team of 5 right now, though, and decided to focus on the core experience right now.

Bit confused reading this, thread was talking about Shopify. (Other confused readers: parent's profile says they work at Makeswift, the site builder in OP.)
I mistakenly replied to the incorrect thread hah. Sorry for the confusion!
Good point, although Shopify does solve a very specific problem that's beyond the realm of basic front-end HTML sites.

Although Shopify does allow you to export your webite too - it just won't be able to do very much used elsewhere, without the Liquid-supporting back-end! :)

Shopify has a Shopify website builder.
I am not the most educated person on the matter, but I think there is an argument to be had about what constitutes a "website" and what is just a "multi-paged presentation" or even a "multi-paged advertisement" that is hosted on the web. I can imagine that even certain presentations can foster more intrigue and be more informative than just a place online that supports brands, products and services. I wish I was more well-versed on the history and principles behind the web so that I can express myself better, but I am quite unnerved by this service and how it presents itself.
I agree that there's a clear difference between the two. Makeswift sites aren't just a "presentation", though. They're hybrid (server-side rendered on first load and client-side rendered after) React apps. And because of that you can have components that do all sorts of things a "presentation" can't do. For example, you can pull in data from third party APIs, you can build dynamic UIs with dialogs, you can animate components, you can submit forms, etc.

Not all of this is exposed just yet, which is why we're in early access. But a Makeswift site couldn't be further away from a "presentation builder".

That being said, it does seem the way we're presenting ourselves leaves much to be desired. So I appreciate you pointing that you!