Build a PWA until you need to go native.
Pick any UI framework that you like - Material, PrimeNG, Covalent...
41–50 of 181 posts
Build a PWA until you need to go native.
Pick any UI framework that you like - Material, PrimeNG, Covalent...
> Because of limited time, and low confidence in UX design decisions, I would often follow the path of least resistance and the end product would be heavily influenced by the tools I used to build it. Angular with the Angular Material components library would be very "batteries-included". You don't have to decide how you store state, what testing framework to use, etc. Angular provides sane defaults for most things.…
Angular markets itself as a tricycle but comes with a manual in which the first chapter after the introduction instructs you to swap out your wheels for jet engines. The learning curve and hidden complexity is absolutely insane and I would only recommend choosing Angular in extreme cases where you actually need to break the sound barrier. Source: I maintain a complex Angular SPA since AngularJS/2.
I find it quite straight forward to use once you overcome the somewhat steep learning curve.
They are all a waste of time.
The important thing is that they waste users' time and not the time of the developer(s).
"Well, let's say you can shave 10 seconds off of the boot time. Multiply that by five million users and thats 50 million seconds, every single day. Over a year, that's probably dozens of lifetimes. So if you make it boot ten seconds faster, you've saved a dozen lives. That's really worth it, don't you think?" [1]
[1]: https://www.folklore.org/StoryView.py?story=Saving_Lives.txt
In this way, adding, removing, or changing your frontend framework becomes much simpler. They had a more straightforward role in your system ("when user interacts with X call module Y.foo") instead of housing most of your code, and potentially losing all that code when you start from scratch or decide to try a different framework.
Secondly, get a better idea of what your needs are. Do you just need a few UI interactions? Is it going to be heavy on state? Do you need to run a lot of AJAX requests and update the UI accordingly? Before you can know which JS framework you need, you need to know what role the JS plays in your system. If you don't do that, every framework is a potential valid answer, since the question is too vaguely defined.
Typescript doesn’t make sense if you don’t manipulate a lot of data or around the app. It can be a pain and lead to a lot of fatigue if don’t get benefits out of it. I am still using js for most of my personal front end projects, and still benefits from intellisense from libraries written in typescript even in standard .js file with VSCode and other IDEs. But 100% of my project uses Eslint (with « recommended » rules…
Forcing you to be clear and explicit about types and handling cases where "undefined" could exist is a good thing.
It might take longer to develop but I've definitely seen I get fewer run time errors once it builds. No more staring at a blank page and checking the developer console for an undefined that's brought everything to a halt.
For example, if you think you want to develop mobile apps at some point, making a good choice now that makes it difficult to do that later is perhaps not a good decision.
Then there is the question of skill sets. How many languages, technologies do you need to know? Javascript is good because it is pervasive. Terrible in many ways, (yes I'm looking at you null and this) but pervasive and most importantly improving.
Which leads us to velocity. Javascript has velocity right now. Both the improvements to the language and things like Deno. I've been using koa - not express - for years. and now there deno/oak appears likely to be a future stepping stone.
Then there is methodology. Depending on the scale of your project, the ability to make progress - as a sole or small team of developers - is vital. No progress === no product. (Love that Javascript requires three =). I don't use typescript because it inhibits my progress. I suspect that this is a personal thing. I would rather evolve code than write code (or perhaps right is the correct word). I do much better personally writing something, having it be wrong and re-writing it again. That is probably just me so your mileage may vary. The point is to know what is best for you. I am extremely opinionated not because I know what is correct, but because I know what works best for me.
I do have some danger signs. C# as much as I like the language is not a viable choice because it is company driven to a very great extent. Go is again the same as much as I am intrigued by it. Rust is very tempting if I had a need for it, and wasm makes it more interesting. But the learning curve is just more than I can handle while trying to actually accomplish things.
And I suppose that is the final issue: what is the time to market or product?
Html + CSS + Javascript in 2022 is mostly what you need. Unless your job is going to require a framework, it’s really not necessary. Maybe I’m the old curmudgeon who is more concerned about putting out something that works and get customers/revenue quickly, than messing around with the latest Javascript toolchain to ensure it builds in Docker. You csn get a ton done with Javascript and Tailwind or DaisyUI. In fact al…
I actually think vanilla JS / TS might be the best fit, here. You’ll probably be writing a lot of plain JS anyway based on my understanding of the description, so I’m not sure a framework buys you much.
I highly recommend Tailwind for CSS and Playwright for testing the real UI.