31–40 of 80 posts
Nice write-up, I look forward to seeing how Strawberry progresses. I keep a list of JS front end frameworks where no build step is required at https://unsuckjs.com/ . I'll add this there (and a few of the others mentioned in the comments here).
https://github.com/beenotung/html-template-lite
Enjoy the process of building your framework. I had similar goals when I started my no tooling / no dependencies Reactive framework https://reken.dev , 2 years ago. And I loved every bit of it. My most complicated problems were reactive DOM elements based on nested loops and recursive components. Even though Reken does pretty much what I need and grew to 7kb compressed, I am not 100% happy with the scope of the appli…
Your way to support inline logic in the text and style is interesting.
I don’t necessarily recommend it, but it’s been a good reminder to me that most of the value React provides me is literally just html-in-JS. In many cases the complexity that comes from React effects and state is unnecessary, and directly mutating DOM nodes is sometimes a lot less painful. Sometimes.
On a recent project, I’ve just been using JS template strings and .innerHTML all over the place. I don’t necessarily recommend it, but it’s been a good reminder to me that most of the value React provides me is literally just html-in-JS. In many cases the complexity that comes from React effects and state is unnecessary, and directly mutating DOM nodes is sometimes a lot less painful. Sometimes.
* Adding animations to elements. By blowing away the DOM and inserting new elements each time, you'll trigger any css `animation` for new elements entering.
* Stale data. If your template isn't re-run when some data changes for whatever reason, you'll continue to render the old data. You've got to manage the lifecycle of state updates yourself.
* To counter that, you might just re-run your templates when _anything_ changes. This works until you have a significant amount of data, then performance starts to become an issue.
This won't come up for many cases though, so for simpler apps it's definitely more than enough!
Why do we need a frontend framework? I am genuinely interested. The last project we used SSR and the sire ended up fast and snappy using a lot less energy than the previous similar project we used a JS based framework and we had all the functionality we needed.
* Chat applications, or anything where you need to have the UI react to incoming events from a socket.
* Applications where sensitive data lives in the client and you don't want to be liable for that passing through your servers.
* Anything dealing with video or audio (e.g. video chat, screen recordings.)
* Applications that are driven by peer to peer data.
* Applications with high interactivity (e.g. spreadsheets, heavy form validation, drag and drop UIs, graphic manipulation.)
It really depends on what your application is doing. If you're just a blog or an eCommerce site, it's definitely worth asking if you need a frontend framework. But for some applications it's absolutely worth it.
Earlier quoted context omitted.
Not always, some can hit the sweet spot of being simple in all phases of development and quick to learn. They are super rare though and their lessons are forgotten; industry often standardizes on inferior things with better marketing.
What are some examples?
https://medium.com/@h_locke/why-dark-mode-causes-more-access...
If the issue is not wanting to spend a bit of effort to implement prefers-color-scheme then light mode is a much better default option.
Why do we need a frontend framework? I am genuinely interested. The last project we used SSR and the sire ended up fast and snappy using a lot less energy than the previous similar project we used a JS based framework and we had all the functionality we needed.
I think the common argument is "complex interactivity". If you have sufficiently complex custom client-side interactivity (e.g. sending, receiving, manipulating and displaying data in the DOM without constantly reloading the page) then something like React or Vue is much easier and more maintainable than a bunch of custom JS. Logic for mutating and displaying data can also live on the backend and use SSR, but it has…
Why do we need a frontend framework? I am genuinely interested. The last project we used SSR and the sire ended up fast and snappy using a lot less energy than the previous similar project we used a JS based framework and we had all the functionality we needed.
I've worked on quite a few projects that would have had significantly worse user experiences if they were done in a purely SSR driven way: * Chat applications, or anything where you need to have the UI react to incoming events from a socket. * Applications where sensitive data lives in the client and you don't want to be liable for that passing through your servers. * Anything dealing with video or audio (e.g. video…
Isn't JS the worst kind of solution for security related things?