Tipe raises $2.1M seed round to build a customizable CMS for developers
tipe.io
tipe.io
Their GitHub page is some confusing bullshit where they seem to have taken the repo of a completely unrelated Angular animation library that has been inactive for 6 years and converted it to be Tipe, presumably to make it seem as if Tipe has earned 2.1k stars when it was actually the Angular project that earned those stars.
They claim to be open-source but I see zero source code. Maybe the source is in one of the two different CLIs that seem to exist? But the one that actually seems documented and usable hasn't had a commit in 10 months.
Seems questionable to repurpose the repo to leverage the stars regardless of whether you posted it here or someone else did.
Still prone to abuse from transferring repo to credit somebody else, but the original repo owner would have to sign off on the transfer at least.
How common is this?
Seems like fraud to intentionally swap out a project within a repo for something very different to repurpose a reputation metric.
I'd say for 90% of people Wordpress for all its problems is fine, if someone is technical and wants more control and customization well really at that point Jekyll is pretty powerful, and if you want fancier you've got Gatsby or whatever the JS flavor of the month CMS is.
Is there a shortage of tools to allow me to publish a webpage? Is the problem of creating and publishing a website so hard that we need a new entrant to solve the problem? How much more complicated can it get then "Here is HTML, CSS and JS put it on a webserver."?
The key is allowing non-technical folks to work without much training. I don't think anyone has found the right balance yet.
Since headless CMSes became popular 5-6 years ago (in large part thanks to Contentful), a lot of companies have moved to them based on the promise of separation of concerns, "omnichannel" publishing and better developer experience.
But what a lot of people missed was that a traditional CMS like Sitecore or Wordpress etc provides not only content management (for structured content) but also experience management (for pages and layouts). And in larger orgs, these two things are often managed by different teams, but both are driven by business users, not necessarily developers.
Headless CMSes typically only provide structured content management - by design - and so experience management ends up needing to be built into the consuming applications, which vastly increases their complexity (not to mention how you manage updates over time - developers now need to be involved), and that doesn't scale well.
Or it gets shoe-horned into the CMS as a less-than-ideal type of structured content, and becomes hard to manage by non-technical folks.
How do you see Tipe being used for experience management?
One of the problems with the WYSIWYG editor was that the developer effort typically added and extra 50% effort onto any task and like anything with Sitecore you ended up having to dig through PDFs on their development portal.
A slight aside though. One of the best things about Sitecore was its OOP approach to content. Every piece of content was an instance of a template. If you knew what you were doing with it you could build things very cleanly. I haven't seen anyone else implement anything similar in their CMS.
Additionally, something like GitHub/GitLab/Gitea is at the minimum required to even make that existing pain-in-the-ass workflow work.
Try updating your jekyll site from your phone without using GitHub, for example.
Gatsby is not a CMS. It would be very nice to have a well-designed and supported CMS that is actually secure and efficient by default.
> How much more complicated can it get then "Here is HTML, CSS and JS put it on a webserver."?
My favorite so far is the combination of WordPress and Gatsby in such a way that you get the worst of both worlds. E.g. building a single page requires creating 10-20 posts in WP, with zero ability to see what changes will look like without actually deploying the site. All this complexity instead of just setting rel="preload".
Unfortunately all sites are worth hacking to host phish kits (fake login pages for phishing), and hosting one will get your website added to browser warn lists and flagged by search engines. There seem to be automated bots scanning for vulnerable WordPress sites so it's possible to become a target without much attention from the attacker.
Given that there are things like:
Contentful, Ghost, Strapi, etc., which either have a REST API for content, and/or other API for customizing the interface for non-devs, or are developer-oriented.
I'm surprised something like this received funding... makes me think, "Snap, I guess I can get funded too?"
I would like to make a plug for Statamic who I have no affiliation with other than being a happy customer that added a bit of customization years ago: https://www.pixlee.com/blog/how-we-allow-anyone-to-make-and-...
I'm Scott Moss, CEO of Tipe (YC W18). We actually just saw that someone posted us on HN. So here to just drop a little bit about Tipe. Tipe is a headless, open-source CMS with a focus on Jamstack apps. Our goal is to have the quickest setup to allow your team to edit, preview, and publish content. We also want to enable you to customize and extend your CMS to fit your team's needs. You can even reuse components you already created in your app to customize tipe. The sky is the limit. We handle the API and infrastructure. We're currently in a Private release and are looking for teams who are using Next.js. If that's you, please sign up!
I'm not in this industry anymore but used to work for a company that provides CMS to fortune 500s. A significant portion of our customers used angular (not angularjs). Are you planning on supporting that as well or remaining react focused?
Of course all these things are really trade-offs. It's arguably much easier just to throw together some PHP and stick it on some LAMP shared hosting if that meets your needs. Or if you're more comfortable with server side languages, you'll be a fish out of water. If you don't know why you would need it, you probably don't.
Yes, and the punishments will continue until hardware improves. More seriously, this is definitely a big trade-off. That's why page weight has been growing over time and client side metrics haven't been getting much better despite improved hardware and connection speeds. There's no free lunch. As I've mentioned in past comments, now's a great time to be a web performance consultant.
> Also aren't you moving much more data back and forth to do that?
Considering that usually the bulk of the frontend arrives once and then gets cached/runs continuously, I would say generally no. Server side rendering requires the page to be sent in whole on each request, unless you're doing some funky hybrid stuff with partial server rendering.
All the transformation & orchestration of your content has to happen in your app.
If you have one backend and one app, that's not necessarily a bad thing, because you have to do that work somewhere, but if you have multiple apps (perhaps by multiple teams) that all consume the same backend, you start to duplicate a lot of that complexity all along the edge of your system.
1. Our frontend editor, where you edit content, is open-source. You can add new field types with react components easily. 2. The editor is also mounted on your site and lives there wherever you want. So, yousite.com/cms. We handle auth as well. 3. You define your schema in your code, like a DB schema, instead of in a GUI. Your schema lives in git with your app. 4. You can get started completely from the CLI, never touching a web app. 5. You can extend your schemas with plugins from the community. 6. We give your features like content previews right out the box with no code setup.
- in my experience most cms implementations are handled by a partner or vendor with some expertise. few businesses have the direction/leadership in place to hire a few devs of the intended cms and start hacking away.
- if you are targeting enterprise you need to market to C-level (or slightly below) marketing people, not devs. marketing holds the keys here and any technical people are usually just along for the ride.
- non-cms content (coming from business systems/integrations) will come into play quickly, figure out a simple blueprint to extend the cms object model to account for this.
- though these were enterprise setups they were usually way off the mark by the time we talked to actual system users. think multiserver architecture, requirements to edit the most obscure content that will never be touched after launch, integrations that dont make sense, access to inaccessible data, etc. probably 30% of the time it should've been something simpler like wordpress, netlifyCMS, etc., 30% should have been static content, 20% should have been completely custom and 20% were actually a good fit for the cms.
- set up examples of common site layouts/components and a WYSIWYG implementation for each. non technical users will expect to be able to change EVERYTHING and page templates quickly turn into a mess trying to keep it all together. episerver has a pretty good system for this IMO.
Is this a typo?