ollerac

I'm launching 31 projects during the first 31 days of the year to break through my fear of launching and just put stuff out there.

If you're curious or want to join in, I'm running a behind-the-scenes newsletter: https://31launches.com

They already did: https://ui.supabase.com/

I ran into so many issues with content-box a decade back I never thought about it again and always defaulted to border-box.

I think it's absurd that I can set a div to a specific width (100px, 200px, whatever) and the padding or border will make the div larger than that width.

It makes it so hard to think about designing a page when you have to continuously add together padding, margin, and border with the width to get the actual width.

You're right about flexbox and grid solving most of these issues -- and responsive design has pretty much done away with using exact pixel widths for anything, but I still run into some cases (especially around creating grid layouts that automatically reflow) where CSS columns and floats are the best approach (not often, but it still happens...) and then you need to rely on the width being the actual width, you know?

I recorded a thorough guide based on weeks of research about how I hired an English-fluent VA from the Philippines: https://share.getcloudapp.com/8Luog9qo

The easy way 10 years ago was FTP or rsync. It seems like that's still the easy way.

I'm wondering why nothing simpler/more automatic has popped up.

I didn't say it was harder today, I asked: "why isn't it easier today?"

I would think with improvements in tech, things would actually become simpler.

Hi Peter, what's the easiest way to set up a profit-sharing agreement with people working with me? Is there a standard contract?

Web app capabilities built in to the foundation of HTML and the browser.

Elements that know they're user-editable (images with upload controls attached to them to replace the image that's there, dates that trigger calendar controls when clicked, and inline editing for other elements that actually works and is consistent across browsers).

An offline database in the browser that has the concept of user accounts and resetting passwords baked in, as well as subscription payments, and has a universal API that can be automatically deployed to any hosting platform.

All of this would make building web apps and games trivial for so many more people -- write some basic HTML, upload it to one of a million platforms of your choice with a click, and you have a testing ground for a product that can grow.

It would be a way for anyone on the internet to build something useful and get it out there without learning a thousand technologies with a thousand nuances.

This is incredible work and very close to my heart because it's similar to a project I've been dedicating most of my personal time to for the past 4 years [0].

It's amazing how much work you can skip when you treat the front-end of your app as a pretty interface for your database. I think a lot devs were inspired to go down this road by Meteor.js back in 2012 when it was released [1].

I think a tool like this is the future of web development: create the interface and boom, you're app is already working. That kind of instant validation of your work is addictive.

The problems arise when you want to change how data is processed behind the scenes before displaying it or after the user edits it. Or how it's connected to other users' data. But I think these issues can be solved either with reactive hooks or some of the innovations coming out of the GraphQL space.

I think you can get pretty far with a system like this:

  * User accounts
  * Automatic data syncing
  * Collaboration
  * Deployment & hosting
  * Payments
  * Form submissions

And these features, if done well, are all that 90% of businesses need to create value for their customers and become profitable.

I'm really excited about this space. My email is in my profile if anyone wants to talk about it further.

[0] https://remaketheweb.com/

[1] https://www.meteor.com/

It's because of components.

Web app dev has started focusing on single, separate, reusable components instead of trying to design everything on the page at once.

Often, in these components, the HTML, CSS, and JS is still separated, but now (theoretically) you can plug that component in anywhere (even a different app) and, as long as you feed it the right data, it should just work.

I believe you're looking for something like Outseta (https://www.outseta.com/)

They're a membership platform that supports:

- Payments

- Sign up forms

- CRM

- Authentication

- Content protection

- Email marketing

- Help desk

- Notifications

Pretty amazing if you ask me. I have no affiliation with Outseta, but I do follow the founder on Twitter.

Hi Hieu, thank you! That's a great way to explain it: dynamic HTML. I should use that.

Let me know if you need any help getting set up. I can hop on a video call if you want.

Thank you! Let me know if you want any help getting set up!

Thank you, I fixed it! You should have gotten a Getting Started email by now. And I changed the redirect to a different page.

If you do, let me know! I can help you work through any problems or answer questions. My Twitter DMs and email (in profile) are always open.

Thank you for the great feedback, I really appreciate it.

- I changed the vague copy you mentioned to be a little more technical, but also hopefully clearer

- I added underlines and backgrounds to the other tabs in the code demo, so it's more obvious they're clickable

- I added an animated, muted video in place of the first example app screenshot as an experiment. Does this work better or worse for you?

- I made the testimonials have a fixed height on mobile, so there's no layout jank

- Remake is definitely unsure of its customer. I want to go after both those markets. Any suggestions to improve the copy (or sections you'd like to see) in this area?

Thank you so much!

Yes, I've helped tutor kids in web dev & game dev and I'm passionate about making tech easier for them. Remake was made for beginners, so they don't have to learn everything about full-stack web development [0] the first time they want to build a simple web app.

If your kids know enough to build their first website (HTML + CSS), they can also build their first web app with Remake.

I'd recommend checking out the Remake Recipes page [1] to get an idea of just how easy it is to build something that works. All of the editable examples on that page – as long as they use Handlebars.js {{variables}} – are examples of fully-working Remake apps that can be pasted into a Remake project (the app-index.hbs file). After that, they'll be working apps with editable data and user accounts that can be instantly deployed.

However, if you want to start by understanding the vision of Remake and get a broad overview of how it works, I can recommend this video I recently made: "Why Build With Remake" [2]

Also, here are a few of the more difficult parts you might run into:

- Terminal. You will need to run a few commands (remake create & npm run dev) to get the local Remake server running. It sounds like your kids are familiar with the command line, so this probably won't be a problem.

- JSON. In addition to Handlebars.js templating and CSS, your kids will also need to learn a little JSON. It's a pretty simple version of JSON (just objects, arrays, and strings all the way down), but it's still an extra concept to learn.

- Routing. If your web app has multiple pages, each with it's own editable data (i.e. it's not just a one-page website builder) you'll need to turn on Remake's unique IDs. There's good documentation around this [3], but unique IDs is a slightly harder concept to grasp than just HTML ⇄ JSON.

Good luck and let me know if I can help in any way. If a concept is confusing and you send me an email [4], I'll be happy to make a custom tutorial on the subject.

[0] https://github.com/kamranahmedse/developer-roadmap

[1] https://recipes.remaketheweb.com/

[2] https://docs.remaketheweb.com/why-build-with-remake/

[3] https://docs.remaketheweb.com/nested-pages/

[4] https://remaketheweb.com/contact-us/

Hi HN,

I made Remake 2 years ago while working on a separate project. [0]

I started that project off with 6 months of research (interviewing potential customers) and 6 months of designing the pages.

I wasn't looking forward to spending another 6-12 months building it all out. I needed a quicker path.

Then the idea came to me: HTML & JSON have very similar structures. They're both ways of storing deeply nested page state. What if I could connect them together and make a really simple way of building web apps?

All I needed to do was convert deeply nested HTML into deeply nested JSON (by tagging elements as being arrays, objects, or keys in those objects) and save the result the current user's account!

Then I could use whatever client-side plugins I wanted (date pickers, file uploaders, inline edit popovers) to edit the page — and sync the resulting JSON data to the backend automatically. It was a really exciting insight for me and would make building a full-stack app as simple as prototyping.

I could even use the data across pages because the JSON structure could, of course, be reused on every page.

That's how I accidentally created a web app framework that lets you make web apps with only HTML templates. I'm really excited about bootstrapping it to profitability over the next year.

[0] RequestCreative.com

Are there any examples of the audio it produces?

I would love to hear more about this. I'd like to implement a model like this for my project.

Any articles or communities you could point me to?

I don't think this is a counterargument. I think he's saying that once you decide to do something, you'll stick with it if it matches your values and the learnings from your journey so far.

This resonates with me strongly. As someone who's started and stopped a lot of projects, I've often been afraid I would never settle on one thing. But now, even though I'm in a difficult phase with it, I feel more committed than ever to my current project.

I think this is in line with the post: I spent a lot of time in a "divergent phase", exploring options and testing possibilities (multiple smaller projects). Now, I'm in a "convergent phase" and focusing on just one thing for multiple years, even though it's hard.

I've been learning more about marketing over the past 5 years. Here's what I've learned so far:

1. Pick one strategy to test at a time and commit to it

2. Pick one platform/audience and commit

3. Have a newsletter and funnel people to it

These steps are mostly because I'm a solo founder and don't have a lot of time. If I experimented with multiple strategies at the same time, I'd quickly run out of time for development.

And building a newsletter is just the most reliable way of contacting people en mass these days. Twitter/Facebook/etc. all have algorithms that can filter you out. Email is a more reliable way of connecting.

As far as marketing strategies go, as a dev, I'd highly recommend the "indie maker / build in public" strategy. This is perfect for devs because it means a lot of your effort is duplicated as marketing.

Here's how it works:

1. Sign up for Makerlog/Twitter/WIP.chat or another community that lets you build in public

2. Post what you're working on before, during, and after it's done

3. Ask for advice and feedback when you need it

This will let people get involved in your product's development and give them a reason to cheer you on when you launch your product or get a new customer. My most popular tweet of the past year (other than my launch post) was getting my first customer. It was also responsible for me getting my second and third customers.

Once you've gotten comfortable on these platforms, you can try this more full process (which I outlined for myself yesterday):

1. Post a rough idea for an article/product/ebook/course to your social network of choice and get a feel for what people like or don't like about the idea. This doesn't have to be a fancy post, just a sentence or two. E.g. "I'm thinking of making a beginner JS course, what do you think?"

2. A few days later, ask a question about how to proceed with your idea or if anyone has done it before. E.g. "Which course platform for releasing paid courses do you like the best?"

3. Again, a few days later, post an outline of your approach for tackling this idea or talk about the content/features you're thinking about including in it. This will again help you measure interest and see where the real value of your idea is. E.g. "Here's what I plan on covering in my course: ___. Would this be useful for beginners to JS?"

4. Work for a few days. Then post a preview of the progress you've made so far. This could be a few lines of code, a blurry screenshot of the final design, or even a picture of you working on your laptop. Just show people that you're actively working on this and give them something to get excited by. Remember: they're probably just as interested in your journey as the final product. Don't focus on the product too much — you're also telling a story about what it takes to build a product.

5. Offer a taste of the final product. Make a thread or post with some of the actual content/features of the ebook/post/product. This could be a 5 minute video from the first lesson of your course. A screencast of you using your app. Or a the first page or two from your eBook.

6. Post a beta tester sign up form that gives people early (or instant) access to the MVP version of your idea. People who sign up are your true fans and will probably give you the best feedback over time. This form can be made with any email marketing software.

7. A week or two later, post a few quotes from early users showing what people said about their first experience of your product. E.g. "I wish I had this when I was first learning JS. I'm learning new things every 2 minutes!"

8. Finally, plan your launch! A few weeks or days before your big launch day, tell people you're launching. Tell them your goals, your hopes, and what your product will let people do (that they couldn't do before) once it's out in the world.

9. Post on Product Hunt, Hacker News, as well as on your social platform of choice. Make sure the product doesn't feel done yet. You want it to be a little rough around the edges. But it should solve a problem and that problem should be clearly stated on the home page.

10. After the launch, post about a piece of feedback you got from a user who signed up during the launch. It could be negative or positive piece of feedback, as long as it was useful to you.

11. Post about an update you made because of user feedback. This will show that your audience is important to you and are active participants in your journey.

12. Don't stop posting. Repeat the last two step (gathering feedback and making improvements to the product) over and over again until your product really starts to get good.

12. After you've improved the product enough that it can be considered a 2.0, launch it again.

The nice thing about this process is that it's symbiotic. Your audience benefits just as much as you do: for every idea of theirs you implement, they benefit by a) seeing their opinions matter and b) getting a final product that's more useful to them.

And, to top it off, you and your audience get to create a story together. It's the story of a fledgling idea coming into reality and finding its way. And they get to help it grow and help it along. It's a pretty magical process when it's done with intention and the desire to make people's lives better.

I agree with the general principle of this document: HTML is outdated and there should be a unification of web technologies so the web becomes easier to build on.

My solution to this problem is to upgrade HTML, a language with a syntax I love, so it can handle building full-stack, interactive web apps instead of just plain documents.

I recently released my version of this idea as an open-source web app framework called Remake [0]. I could really use some help from contributors to make this new approach to building web apps even better. It's not meant to replace other stacks, but to complement them as an easy-to-learn, quick-to-build-with alternative.

Large parts of its infrastructure were inspired by some excellent critiques of SPAs from this very message board:

- It's a server-rendered framework (doesn't need front-end JS at all if a user is viewing a page they can't edit)

- It uses plain HTML, CSS, and JS to build out functionality (no transpilers and only the simple Handlebars.js templating language). You don't need a million tools to get started.

- It uses a file-based JSON datastore so it's easier for devs to use and manipulate data

- It uses file-based routing, so there's no complex hierarchy of pages and a standard structure to URL params

- It feels like, to me, the gold standard of web development: using a single templating and behavior-rich language on the front-end, and a simple JSON file for each user that's synced to and loaded automatically on the backend

I've been building it and documenting it [1] mostly on my own, although I've gotten a few other devs to help me along the way. I really think it could be a great framework for beginners as well as experienced developers who want to release small side projects quickly.

I've built several example apps with it so far and they're pretty powerful. I'd love to know what the HN audience thinks though.

[0] https://remaketheweb.com/ [1] https://docs.remaketheweb.com/

This is a good idea. I like the easy-to-use interface and that it's free. Have you thought about making it open source?

I used this on a repository for an open source framework I'm working on and it looks nice [0]. Thank you for building this.

[0] https://repository-images.githubusercontent.com/173404546/a5...

I love this book called "Soowing Down to the Speed of Life". In one chaper the author talks about the incredible boon that comes from heading towards boredom instead of away from it. He decided to take a night to just do nothing.

At first, it was uncomfortable, but then his whole world slowed down. He started noticing things he hadn't noticed before: a particular color, a detail on a flower. It was like a different reality.

I use this idea of heading towards boredom to clear my own head. I find it incredibly helpful to sit in a dark room with no sounds and no goal for about 2 hours. After the initial discomfort (might last 20 minutes, might last an hour) my brain feels renewed and free. And the quality of my ideas goes way up.

I don't do it to be more productive though. I do it because it helps me get to a better, more attuned experience of reality. Closer to joy, peace, and acceptance, and further from always thinking about what's next.

Yeah, I think links are really under-appreciated, even though they're everywhere you look.

I'm curious about what the next set of hyperlink hacks will be. For example, I'd like to be able to click on an AirBnb experience, but load it up into VR instead of having to go to it.

MySpace is a great example! I think a lot of web developers out there who now work for major corporations or started their own companies probably started out just wanting to add a gif to their profile or change the background color.

Sure, the results turned out ugly 90% of the time, but it gave people a way in. A way to just experiment and have fun.

Compare that with the front-end build steps new devs are expected to find their way through these day... it doesn't make sense. I think one solution work considering is making the browser and HTML itself take on more responsibility. Front-end libraries are just giant hacks built on top of them.

This looks like a great product! Can I ask you want sets you apart from other services in this market like Vercel's og-image [0] or other more marketing-heavy sites that let you have more control and customization?

Also, I'm really curious what this will cost when you release it as a service? What do you think something like this is worth to people? Is it like a $20/year service or like $1,000/year? Are you going after mostly consumers and indie devs or big corporations?

[0] https://github.com/vercel/og-image

This is what my company is currently just getting started with, so I'd be interested in this comparison as well. If Reflect is much better, we still have time to switch.

Back when I was working on another startup, I hired a freelancer friend to create "The Freelance Rate Calculator" [0], which ended up on Sourceful a few months later. Before that, it went viral on Twitter (112,570 impressions) [1] and brought in a ton of traffic to my startup's home page.

Ever since then, I can't shake the feeling that I should probably turn it into a simple SaaS app.

It really made me think that nicely designed Google Sheets documents are probably the perfect way to prototype some applications. They're free, fast to build, and anyone can access them... And, apparently, you can get them to look pretty damn nice.

[0] https://sourceful.co.uk/doc/101/the-freelancer-rate-calculat... [1] https://twitter.com/panphora/status/1094081680166531072