codeptualize

I'd be more than happy to see small or medium projects and how these tips improved them. Any real world examples would be great.

I would also add that a lot of us do work on the bigger projects, which makes sense as bigger projects require more people. So at least in my life, and I expect many others, it is quite relevant.

I also don't believe the article qualifies that these tips are only for small to medium projects, I'd read it very differently if it did, but I would still like to see some real world examples though.

In some sense I agree, I am very mindful of the dependencies I add and I am not afraid to write something custom if that better fits the situation.

But this article is not showing me how to do that and the things listed are not going to have an impact on the complexity of my projects as these basic things are solved quite well.

> By adding an advanced framework you up the complexity by default

If you know your project will remain simple then by all means. That's often not how it works though and then you end up writing a framework yourself once the scope gets increased and features are added.

Adding to that that using a framework gives you so many things for free. There are so many aspects to a good website and leaning on a group of people specialising in all those things is often a smart move with better outcomes.

I think the initial complexity might be a little bit higher, but there often is a big return on investment later on, and also immediately in terms of productivity.

I'm not going to stop you from not using a framework, I think it's great to experience it, have been there many times before, got burned (badly), and now make different decisions.

If they did I'd honestly love to get the details and be proven wrong.

With just this list it's hard to imagine how this would work.

The only scenario where I can sort of imagine it being potentially helpful is an agency setting with many not-too-complex projects and limited ongoing development. I can imagine updating projects being a hassle. That said I don't have experience in that field, and I bet there are other ways to deal with that.

Good old times, I used to have a file watcher that would refresh the page on change using a browser extension, not anywhere near the convenience of HMR though haha.

I do agree with you, it's why I'm skeptical about the results of following this advice. I vividly remember how much things sucked, and obv the web has come a long way, but the tools have gotten even further. If I see how much mileage I get out of the tools I use on the daily, I would not be nearly as productive without them, and produce a lot more buggy, inaccessible, and shitty apps.

Thats great. Show us!! What projects, is it 8 devs per project or total, what was the impact, any downsides?

Nothing is more convincing than real world success stories.

This is fun in to theory and in simple examples, but show me a big project that applies this and how it made a difference.

There are some bold objectives at the start that would be wonderful, but I’m a bit disappointed by the advice. I really don’t see how these would work in anything other than very basic scenarios, even less how they would achieve the objectives.

I’m all for using the web platform to the max, and I’m absolutely for reducing complexity as much as possible, but I’m highly skeptical these principles will achieve that and I would not be surprised if it increases complexity by having multiple ways to do something.

With peace and love but I can’t see from this list if you actually put these principles to the test or you just assumed it will do what you hope it will.

In terms of tooling Python is a mess. Poetry is indeed quite good, but it still has issues.

I think what python misses is things like cargo, go and npm (dare I say it..), tools that handle packages and run your app in context, making that things generally just work.

Might be anecdotal, but I have had way less cross platform/binary issues in other languages. For node things are usually handled very well these days, rust just compiles stuff (or great docs with clear instructions).

It’s not just environments, it’s formatting, linting, types.

I think python used to be ahead in usability, in the last decade it has fallen behind a bit.

It’s still a good language to use because it can do so much, but I can’t say the experience is enjoyable.

I use copilot all the time, it’s really useful, but I do also think it’s overhyped a bit.

It’s quite good at boilerplate, simple functions and repetitive things (let’s say you need to write all fields of a struct).

Another scenario where I’ve found it useful is writing in a language I don’t know well. It will write a lot of the basic stuff for you, which can really speed things up. Even in languages I know well it has occasionally shown me things I wasn’t aware of. So in my experience I’ve learned more, quicker, using using copilot.

It’s not going to write anything complex and it will hallucinate and write bs code somewhat frequently, other times it writes inefficient code, so I still have to read docs. It also lacks the full context of the project limiting its utility. It’s not going to build your project for you.

That said it’s an amazing tool, like a really powerful autocomplete.

I would recommend to try it, that’s the best way to see for yourself if it brings you anything. I was skeptical as well, tried it, and have been using it for months.

I can't find an equivalent for Go. https://github.com/sqlc-dev/sqlc and https://github.com/sqlc-dev/sqlc look nice, but they are doing codegen, definitely not as sleek as Rust sqlx.

I guess it's a good example of how powerful Rust is. The "magic" that sqlx does at compile time gets really difficult if not impossible to do without macros.

Of course you could create a separate parser/builder, and codegen works as well, but definitely not as convenient and flexible.

I've been looking at Rust and Go and I understand their point. Rust is amazing but can be really challenging. It's easy to start building something, then followed by a long period of lots of frustration and wondering if I can ever get it to work, then once it finally works it's usually very solid.

Skill issue for sure, I would love to spend more time learning and practicing, but that's not always great when you need to get stuff done.

In Go it is really easy to just build the things I need, fast enough, safe enough. I expect it's somewhat the reverse of Rust, very productive and easy until it's not, but it will take you quite far! It's maybe more like Python, but with decent types, and a lot faster.

I think both are pretty awesome for different purposes, I would also expect that once you get to a decent level of Rust experience it probably gets a lot more productive, but it takes a while to get there.

Very much agree with this. I really like how sqlx (on rust) does it. You just write normal SQL queries, and it will check and validate the types against your db. Best of both worlds.

Even though I have no clue what this binder thing is or does I quite enjoy reading well written docs like this.

I have a maxed out 13 inch M2 air, it’s a great device.

I run docker, usually with local supabase, affinity designer, framer, many many open tabs on chrome, usually two open vscode projects with some js builder and tests running, TablePlus, gitkraken, slack and some other smaller apps. On top of that I do video calls with zoom.

No issue. It’s fast. Ram does get full, but don’t notice it. It gets warm but not hot, unless you really push it.

Not having fans is really amazing.

To me this article and demo shows why we use SPA's, and how much modern frameworks actual do for you. It's hard to not see a whole lot of very basic problems in this demo that any modern framework would solve out of the box.

The "SPA bad" arguments are also largely outdated. Most apps that are build now are at least hybrid, with some SSR getting best of both worlds, urls and navigation are solved, accessibility is improving with better component libraries linters and best practices, automatic bundle splitting, highly optimized caching of static assets, build tools with hot reloading as a standard option, static exports, etc etc.

Getting a good Lighthouse score is not the flex it used to be (referring to the enhance movies demo), my all-JS Next.js app scores 100's without even trying.

The only potential argument would be users not having JS enabled, which is not relevant to most apps and use cases. In most cases you do not want to degrade the experience of most (but more likely all) of your users, and with SSR you can have it all.

Obviously build for your audience and use cases and apply technology that makes sense and I welcome experimentation with alternative approaches, but saying "spa bad" is imo not very productive.

Cool! wasn't aware. Then it is even more relevant for the article to cover this.

See https://www.youtube.com/shorts/WhLGEJ3sMNg

You can drag around the whole screen btw. If you need to go further just hold your finger at the side of the screen and it will work as if you hold the arrow keys on a keyboard.

I believe it also responds to velocity, so quick swipes will get you quite far.

On iPad you can also do a two finger drag.

Very true, I think that might be on purpose (it's an interesting topic https://www.nngroup.com/articles/ui-accelerators/).

Do agree that this one is too hard to discover, Apple doesn't really highlight it at all, while it's so incredibly useful.

Luckily there are all the engagement farmers with their ios tips and tricks, maybe that is the official Apple strategy haha, and to be fair it kinda works as people do find out that way.

Why does this not mention long press on the spacebar on ios?

It largely solves this problem.

Long press on spacebar, keep it down and move around to move the cursor. While dragging tap with a second finger to start selection mode.

My whole point is that usability is not about small details but the ability to complete a task. The big picture.

I don't use windows, I don't like it, but if [it being impossible to tell which window is focussed] doesn't impede people accomplishing the things they need to do, it's probably a cosmetic, at best a minor usability problem.

No, I don't use A/B tests for usability as they aren't very helpful to find usability problems.

A/B testing is more for conversion optimization, it's to measure how persuasive something is.

User testing is my preferred method (in it's simplest form just observing people doing a task), if that's not an option I like heuristic evaluations.

I suggest you actually look into what usability is about, you might enjoy it. Good luck with your assumptions.

The article states that usability is declining, the arguments to back that up are: things are somewhat inconsistent and I don't like [some UI patterns].

My point is that the claim is wrong, and the arguments don't support it and have little to do with usability.

This follows from a misconception that usability, UI, and user experience are the same thing, which is really showing a lack of understanding of what they actually are.

I write my comments in the hope that people will actually look into these topics more deeply as they are quite interesting and often require setting aside the preferences, gut instinct, and pet peeves this article is filled with.

>are not a UI/UX problem

Never said UI, but they are absolute usability & user experience problems. Arguably the most important ones! This is exactly what I mean by missing the big picture. What do you think has more impact on completing a task and the experience of completing that task? A working maybe slightly inconsistent toolbar, or the thing crashing and loosing your work?

> The article actually says the same thing: 'A few rogue applications didn't play by the rules,...'

Fair enough, although I would say it was a lot more than a rogue few..

> Do me a favour–try getting an older person who has not used Zoom before

Great example of something that you couldn't do and now can, times are truly great right now.

It's great that you mention old people, I have helped some learning to deal with computers, back then, and also more recently. It's so much easier now.

Old computers with the software we are talking about was/is really hard to learn for them, now with ipads and smartphones they can do so many things. Can't say I have tried zoom specifically, but Hangouts, face time, whatsapp, email, even installing games and apps, no problem at all! They can achieve so many more things because we have come so far and things are more usable than ever.

> I also feel that context switching in between multiple languages restricts my understanding to them to a very surface level

My experience is the opposite, I've always written mostly JS now TS, but I have ventured into many different languages (Objective C, Java, C#, Python, Php, Go, Rescript, probably a few more), and even though I might not know much about most of them anymore I've learned so much about programming in general, and I also know JS/TS very deeply and a bunch of other languages sufficiently to build projects.

A lot of concepts and patterns are language agnostic, and seeing the same things in a different flavors really improved my skills and ability to build projects.

But it's totally legit to just use Python. Python is an excellent choice for many kinds of projects, so if it does everything you need, go for it!

What matters most to improving your expertise is building a lot of things, and keep challenging yourself. The tools don't matter that much imo, just use what makes sense.

Also just have the confidence that you can learn something new. As your knowledge grows it will also transfer to other languages. Yes, you have a bit of a hurtle to get used to the new syntax etc, but you'll pick it up pretty quickly as you have a reference (e.g. "How do I do a dict in [new language]? is a lot easier than learning what a dict is in the first place.).

Anyway, I wouldn't stress about it either way, try it, if it doesn't work try something else, and just keep building!

There is a misconception that consistency == usability. It's an important part of usability but there is a lot more to it. Tunnel vision on consistency (or anything really) doesn't lead to good outcomes. The big picture is what matters: can someone do what they need to do?

Articles like these also have lots of opinions, no research and stats, nor have decent explanations of how much impact these "problems" actually have. Granted I have not seen much research on desktop apps, but in other fields things have measurable improved a lot.

Even going by opinion, my memory from that time was that everything was pretty bad. How often do you lose work because of crashes or not enough undo steps? And could you do the same things you can do now? Also don't forget about all the horrible Java software that didn't use the OS UI.

People romanticize (software of) the past. The stuff I use today is magic compared to the old crap.

Obviously not everything is perfect and I do recognize/understand some of the criticism in the article, but focussing on the little things really misses the big picture that is usability: completing the task that you need to complete, and that is easier than ever.

> You're old and angry! You bet! Now get off my lawn, punk.

Fair enough, I'll see myself out.

I’m not too worried about that as I assume it’s not (just) the public but also lobby groups and industries who have an interest in this.

It’s not that hard to explain what would happen and any politician will understand doing something like this would be quite bad for their career.

I do agree that they will keep trying, but the chance of it happening seems slim, as there is just no way to implement this.

You see this time and time again, some initiative to "just introduce some backdoors, what could go wrong", and then it takes some time for people who understand what it actually means to convince them that it is in fact a really bad idea and it would be a giant disaster.

The last release of jQuery was last week. It's no longer popular, but still maintained and used.

Even if this happens to React, it means it will still be maintained and stable for at least another 15 year.

I also think React will evolve and adapt (see RSC which is kinda what you describe). The beauty of React in this aspect is that the scope is quite narrow so it can evolve, as it has done in the past.

The problem is the part where you think about the framework instead of what you are building!

For 15 years: My bet is on React, see the amount of apps currently build on React, see multiple large companies backing it, see the #huge ecosystem, all the jobs. Even if it goes out of fashion we'll see another 15 years of it.

Other mentioning React will be like jQuery supports my point: Out of fashion, but well maintained and still used a lot. (Side note: Rails is also like that imo).

Svelte does an interesting thing with the compiler, but otherwise not that revolutionary, and in some parts questionable. In terms of longevity they have a ways to go.

But 15 year longevity seems like a strange criteria to me. Is the app you are building really that important that it will need to survive 15 years, but not important enough to update it to newer tech?

I think it's also good to realize that all the options are largely similar and only differ on details. It's a different flavor of the same thing. Learn one and you will be able to pick up the others very easily.

It depends a bit on what you are building.

For most LLM apps I wouldn't use a library like that. Just write some code. Some examples;

- Prompt templates: You can just use f-strings, ninja, or whatever templating language

- Getting LLM results: openai (or your llm of choice) library, or just simple api calls

- Chains/composability: Just one line of code after another line of code, functions, loops.

- Embeddings: Depends on the database and llm you are using, but generally not that hard. There are many guides available for whatever you are using.

- Measuring token length: For a lot of things you just need to measure token count of text. For OpenAI see tiktoken.

The exception might be agents, but most apps do not need those.

You could also just look at the langchain source, figure out what you need, then just write it yourself without all the abstractions.

Also look beyond llms. LLM apps are generally not much more than text processing, data storage/fetching, and api calls. That's nothing new, all the existing pre-llm solutions for text processing, queues, concurrency, chaining, data fetching, and pretty much everything you can imagine will work just fine.

Don't get discouraged, FE is amazing, and it's only getting better imo. It's just a small number of grumpy developers stuck in the past who don't get it, just see them for what they are, wrong and ignorant.

The most optimal way to work in this industry is to deliver great working products. No one can argue with results.

If you want to strengthen your position, which is always a great idea, you can go many directions: FE + App development (react native for example), FE + backend, FE + design, FE + product, any pairing is super valuable.

Also don't underestimate the power of frontend in an organization, it's where everything comes together, its where the rubber meets the road. It's where backend and design become an actual product, it's what your clients actually see, it's what business people demo and sell.

If you do it well and take control, you can be the glue in an organization and influence literally everything.