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
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
All of this is pretty trivial to get working out-of-the-box with very little effort from a dev. So no one has to reinvent the wheel.
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.
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.
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?
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.
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.
If you're curious or want to join in, I'm running a behind-the-scenes newsletter: https://31launches.com