codeptualize

This shows a quite limited understanding of what FE development (and product design) entails these days. But, it's sort of true if you don't build anything interesting.

Same applies to every other component of a "not interesting product" btw, if all you need is a DB with some crud endpoints you can get great solutions without writing any backend code.

I think the "disrespect" is largely a left over from the time when FE was seen as styling with a little bit JS, it's a different world right now.

I don't think it's as prevalent anymore, plenty of BE devs moving towards FE, plenty of respect as well, and any decent organization realises the importance of FE in actually delivering anything.

We are turning into a narco state, and that largely runs on cash. I don't think the measures are great or will do much, but the fact that they try to do something about it is understandable. Also I really don't care about cash, I never use cash.

I personally think they should just legalize and regulate a lot of the drugs which would be much more effective. People use drugs anyway, they generally do it in a safe way, it makes no sense to keep it illegal, it leaves the whole market to crime.

Legalize, regulate, and charge fat taxes. The crime problems are a symptom of our ridiculous drug laws. If we don't solve the root issue, measures like these will not change anything.

Supabase cli has a decent diffing option to generate migrations (not sure what they use, but it’s open source), it works quite decent for schema changes.

Not as advanced as you describe though, it won’t handle your data migrations.

Will try!

It looks quite similar to table plus, any killer features I’m overlooking?

Letss gooo!! Supabase keeps on delivering things that I need.

I am regularly surprised how bad the tooling is for SQL/databases. Especially that there is no decent formatter that supports plpgsql, and doesn't absolutely mangle your queries (sometimes actually breaking your queries..).

Best options atm are imo TablePlus and DataGrip, I have tried a bunch of options in vscode and although there are useful tools, it's all not really there.

(Also excited to see what else they will release this launch week!)

Really confused by this.. $235K is not nearly enough to make even one of these apps. Unless they can get devs to work for free it's not happening.

Also Affinity exists, their suite has basically the same apps as they claim they will build, they have one-time very reasonably priced licenses. The only potential difference is that you need to pay for major version updates, from 1 to 2 took a bit under 10 years if I'm not mistaken.

Affinity has allowed me to not use Adobe for a long time, (until they bought Figma.. but well).

And it seems odd to me to clone very old software in a world that has evolved.

Anyway, always pro having more options, so good luck to them!

Fair assessment. Maybe you have found the value: it’s a library of code snippets. There is truly something to say for that, but maybe it had worked better as a documentation site (kinda ironic as their docs are not super great).

> plain old sequential code

This!! Besides the templates this is the most confusing thing, it is indeed the same as running lines of code sequentially.

P.S. for python dependencies, check out Poetry, not perfect but a lot more sane than the other options.

Often there is still a lot of programming to do, as a lot of the use cases involve some sort of integration into a bigger systems, or you might have to process larger quantities of data which gets you into queues and for example managing rate limits.

That said I 100% agree that often the basic tools are sufficient to solve these problems, and where it gets complex there are many battle tested solutions.

With peace and love, why would I not just write some code?

LLM pipelines are not very complex: it's string manipulation, api calls, and storage, there is not much more too it. All are quite easy to do, often needing nothing else but the standard library.

For more complex cases or bigger scale you have a plethora of battle tested solutions to manage things like queues, back off and retries, concurrency, etc.

Maybe it's me missing the point (again), but I wonder what the added value is of learning a new language to do things that are super easy to do in Python/JS/whatever my language of choice is? Or maybe I'm just not be your target audience, very possible.

True, you gotta respect the marketing, they definitely got that covered and actually created some real value there, a $10M seed round to be precise.

I think they got the timing right and the idea is kinda alluring as well: have everything standardized, pluggable and swappable sounds neat. Just doesn't really work.

They are also doing a great job at maintaining the mirage of adding value. Templates for example will work totally fine, as they are just f strings. It seems there are plenty of people who don't really think twice about it, and they have captured that audience very well.

There is also a low barrier to contribute as everything is kinda basic, that must help a lot as well.

Coming from a frontend background this reminds me a lot of the frontend situation some years ago when it was super common to npm install the stupidest pointless packages.

Of course some people still do, but hard lessons were learned and all experienced people I know are a lot more mindful and cautious what dependencies they add.

It seems to me that this space, and maybe data science more broadly, is currently in that situation. Maybe it's the lack of coding skills, maybe it's the transition from one-off research notebooks to production applications, or maybe it's just the norm to have big do it all libraries (like pandas, scikit etc), idk, but I expect the same lessons will be learned.

For Langchain I wonder how they will keep up with changes in all the things they have their abstractions on. I guess having a huge community helps, but that doesn't help you with compatibility. It would not surprise me if that will get really ugly.

I have looked for the value and never really found it.

It seems to mostly be (bad) abstractions around things you could easily do without langchain.

Take one of the most important llm things: prompt templates. What does langchain add over a simple function and an f string? Maybe I'm missing the point, but I can't find anything.

Anyway, it seems people like it so who am I to judge, but I don't like making our codebase dependent on a huge new library with unnecessary abstractions and little or no value add.

Build, build, build, and build some more, then build, oh and you should build more.

It's taking on a challenge big or small and seeing it through no matter what it takes. You'll get stuck for hours, days, sometimes weeks, you'll get frustrated, tired, annoyed, but you just refuse to give up and eventually get it done.

Those are the moments that bolster your confidence and you realize you are capable of achieving seemingly impossible things.

That confidence of "sure I can figure it out" is what you need to feed and grow as a programmer and probably in many other professions.

Best way imo is to pick reasonable small contained projects, and slowly ramp up and take on bigger challenges. If you take on too much, shelve it, do something smaller, then return to it later.

It takes a lot of time, effort and perseverance, but as long as you keep going you'll get there in the end.

Would it be possible to share your tests and results?

It depends on the project and what you are looking for.

If I’m looking out of curiosity I either try to find the entry point and/or the “core” logic (the code that does the main thing the project does).

But usually I’m interested in something specific and then I’ll use search or click around based on naming. Then it’s mostly just tracing function calls until you find what you are looking for.

Some tips:

- Read the docs if available!

- Read docs on the language/framework/libraries used

- package.json and similar requirement files contain a lot of info

- Knowing “standard” structures for languages and frameworks helps: for example phoenix projects often have similar structures

- Searching often works really well if you know a name or keyword

- If it’s a webapp or website, the browser devtools can reveal class names, api routes and other things that you can search for in the code

- Generally interfaces (ui, cli, apis etc) are great starting points to find out how things work

I think the way to learn it is to do it a lot. Important is to have a purpose: fix a bug, figure out how it works, make a change. Reading code without purpose is not that useful imo.

And write more code, debug more, learn new languages and frameworks (do make sure to also specialize, aim for T shape).

> but that's what the user expects their scroll bar to look like!

You base that on..? I’ve had users complain about their native scrollbars more than once. Native scrollbars can make things look very broken.

In terms of responsiveness, true for a normal website, but sometimes impossible in more complex ui elements (like I said, not the page scroll, but in page scrollable elements)

I would really like to see some research on this idea that people prefer native elements, it’s not what I see in user tests and the feedback I get. My experience is that people want a functioning app that doesn’t look broken.

My whole point is: we should be able to provide a great experience that’s accessible and allows the user to give their preferences (like prefers reduced motion).

I agree with many points but there is definitely a need for custom scrollbars.

The reality is that if you have scrolling in the page (like a column layout for example), you kinda have to customize the scrollbars. If only to not break your layout as scrollbars are completely different everywhere, hidden, different widths, some ugly, some nice, no reliable way to detect the situation, it's a mess.

I would opt for more options: give us better tools to style (around) scrollbars, give us the tools to honor what the user prefers, to know when and when not to blend it in with the UI, to increase contrast, or to just leave it alone.

Just not customizing is not a realistic solution for a lot of situations.

I do this for a number of services, obviously pricing needs to be reasonable. My reasoning:

- I don't want to deal with upgrading, managing infra, backups, outages, security etc etc

- For products I rely on it's good to pay, as that (usually) means getting support if I need it

- I want the developers to continue development and maintain the product, happy to pay for that

That said I only pay for apps that are great and I need and use. If you have a crappy app that I sort of need at some point, I might try installing from source.

If possible I would suggest to look at conversion metrics instead of user provided ratings. Real validation is people signing up and using your product (regularly), you can measure that.

Of course reaching out to users is very valuable, it can help you understand them, why they use or stopped using your product, what they like/miss/etc. But to get quality insights like that you will have to ask open questions, interview them, do user tests.

Metrics tell you if something works or not, reaching out to users helps you understand why it does or doesn't.

Love Modal. We use it for data processing, queues, apis, and all sorts of random things. Such a great product!

There are some degradations, just like other "engineering" like software engineering. I am pretty sure most people don't know the ins and outs of everything that makes code run, from compiler to CPU, especially not the CPU's of today, I doubt any one person fully understands them. You just know the abstraction layer you manipulate and learn techniques how you can make it do the things you it want. That is quite similar to prompt writing.

You can certainly get better at it by learning the basics of LLM models, as well as finding and applying certain methods that improve the results.

You can actually see quite a lot of difference between someone trying out some things, or someone who has spent quite a bit of time trying to make it do non standard things.

What you call "engineering" is of course up for debate, but it's not snake oil.

I find it kinda annoying. It's like a slow inaccurate autocomplete that doesn't always work.

I'm kinda puzzled why people are so excited about it, and honestly wondering if there is something wrong in my setup, or if I'm using it wrong. I have been using it for a couple of weeks now, but no improvement, and also tried quite a few strategies.

It's "ok-ish" with boilerplate-y stuff, but it's not reliable. Same as you mention; I'm quicker writing code with normal TS autocomplete than having to fix the sometimes subtle bugs it writes.

You can! They are focussing on their publishing platform, but it's open source https://github.com/TryGhost/Ghost, see the self hosting guide https://ghost.org/docs/install/

Edit: I see you mentioned no self hosting in an other comment, then it might not make sense for you as the hosted version is indeed paid.

If you don't want to use Medium or similar solutions, I would check out Ghost.

Their dashboard and editor is imo one of the best out there, really easy to use.

It's easy to host, works headless, and works well with Next.js and others (https://ghost.org/docs/jamstack/next/).

Usually the downside is that it can be a bit limiting in features , but it's perfect for blogging.

Great article, it's good to read a nuanced take on a hot topic.

I think the $ shows the tradeoff of reactivity. It makes updates sort of automatic which is great, until it's not. React on the other hand is a bit more explicit and cumbersome, until it's not. Rules of hooks vs rules of reactivity, it's all about managing triggers and dependencies, which easily gets complex. I think there might be a possibility for a mix, reactivity with escape hatches, idk.

I'm not saying they have the obligation to keep the free tier, but don't expect people to stick around.

Also free plans can definitely last, best example being Github. If Github would cut off free open source repos it would be over, and I'm pretty sure they are very aware of that.

My point is, it's a mistake to assume people will pay for something that was free and it's a misunderstanding to think there is no symbiotic relationship. Hosting a giant community can be incredibly valuable, especially when it's tech people with big budgets in your sector.

It's imo a business mistake to monetize in a way that goes against that. The community will have no issue finding a new home that does appreciate them (e.g. Github).

You can not be the main player and betray the trust of your users (free or not).

It's easy to forget the value of being an important part of a community that makes decisions on millions of $$$ in software spending, but be sure that there are plenty of companies who would love to take your place.

Reverting this incredibly dumb decision is the right course of action but there is a long way ahead to restore trust.

With these things I always wonder how many people they ignored to push this through. I am pretty sure there are plenty of people at Docker who 100% accurately predicted this, spoke up about it, and got ignored.

Nice! I think you might like it.

Ah yeah, that does take a while to unpack. I think a lot of the complexity there is dealing with a non-react library and the dynamic import(s). Binding non-react libraries can be a bit rough.

I do think it's a good example to show the big advantage of hooks, if you look at the use of the hook, super clean: https://github.com/graphql/graphiql/blob/50674292c55eadf0e61...

Great way to contain complexity and make usage really clean and simple!

I believe context predate hooks. You are right about error boundaries, probably should be revisited.

This might be controversial but imo the lack of state management in React is a pro not a con. It means the community can innovate instead of being stuck with whatever the framework provides as is standard with most other frameworks. A lean focussed but flexible API.

You can choose the flavor that works for your, patterns like React Query, SWR, Zustand, the Atom based stuff, it's all a big #win imo. I like having options.

Also I'd say changes in preferences are not exclusive to React. React did make the hook change (while still supporting the old!), but otherwise the preferred approaches are not per se exclusive to React.

I would add that there is nothing wrong with sticking to what you are using atm. You don't have to use the shiny new thing if the old works well!