11 ms·
Lightweight JavaScript Framework Review (For Django Developers)
- deleted 3y ago[deleted]
- pier25 3y ago> Say no to the heavy frontend solutions such as React, Vue, Svelte, Angular I get the author is looking for some integration with Django and server-rendered HTML but Svelte is definitely not heavy and v5 is going to produce even less JS code.
- paulddraper 3y agoSvelte had it's own language and compiler.
- pier25 3y agoIt has a compiler, yes, but if you know HTML and JS you already know like 99% of the language.
- willsmith72 3y agoI wanna know more about what's "heavy" and what's not, and why choose lighter solutions over heavier. Are we talking purely bytes? Popularity? Typical codebase size? Browser performance? And whichever it is, why are we prioritising it?
- paulddraper 3y agoHeavy as in "conceptually heavy" -- complex, steep learning curve, extra build steps, bringing in non-Django paradigms. I.e. looking for solutions that "render HTML in Django, and use Javascript to enhance the server-rendred [sic] HTML." HTMX is the most popular solution.
- em-bee 3y ago"conceptually heavy" -- complex, steep learning curve, extra build steps, bringing in non-Django paradigms which i think is, for the most part an exaggeration. if someone feels that learning a new framework is heavy and has a steep learning curve, then either they are juniors that need more practice and experience, or they have never tried learning a second framework, or they have become lazy. (but here i'd also like to blame employers that don't give their developers time to learn new stuff)
- aragilar 3y agoOr simply what integrates well with an existing framework. The "lightweight" examples given allow for non-JS templating on the backend (in this case Python, but the article looks at other non-JS languages), whereas other frameworks require build steps/"SSR" and effectively require a REST or other API framework.
- em-bee 3y agosee my comment here for a response: https://news.ycombinator.com/item?id=39157910 https://news.ycombinator.com/item?id=39157910 btw, i use frontend frameworks without bundlers/build steps, but load then statically straight into the browser. that may seem a bit wasteful, but it dramatically simplifies the maintenance needs for a site, guaranteeing that the site will keep running and be maintainable for the forseeable future.
- deleted 3y ago[deleted]
- Vinnl 3y agoI imagine it's not so much about learning curve, but about the number of concepts to keep in mind while working on your code. If an application has lots of client-side state (and the framework to support that), for example, that means you have a whole additional lifecycle of your code to reason about. Whereas if it at most sets a disabled attribute on a button, that's conceptually a whole lot lighter.
- pier25 3y agoI assumed size which is probably what most people would associate with "heavy".
- PrimeMcFly 3y ago> I wanna know more I want to know more. Let's try to maintain a high level of writing and communication here.
- AlexeyBelov 3y ago> Let's Let us.
- PrimeMcFly 3y agoContractions are proper English. Your "correction" is not one. Nice try though.
- ttymck 3y agoDefine heavy
- mcintyre1994 3y agoI thought Vue was in that lighter space where you can easily add it to a server side app too. Last I hacked on Livebook they were using it for the more complex front end widgets for example, and that’s primarily a Phoenix Liveview app.
- whizzter 3y agoYeah, Vue is my go-to lightweight option and while using Vue with pre-build steps adds a bit of complexity you can also use Vue without any build steps(95% of my Vue usage). And then putting something like Phoenix liveview,etc into the lightweight category, really feels like putting things in categories via rumors or smth.
- sapling-ginger 3y agoFor an article about "lightweight javascript", it mentions the bundle sizes of its examples exactly zero times. Probably because the livewire bundle alone is like 40kb, comparable to react+react-dom's 45kb.
- pier25 3y agoA big difference though is that the Livewire lib is downloaded only once and includes Alpine for client side stuff. With React you still need a ton of JS with components and other libs.
- CharlesW 3y agoVue 3 is 16kb, or 27kb if you use everything. It feels like "heavy" refers primarily to cognitive load (a legit factor, of course).
- fijiaarone 3y ago45kb (zipped!) for document.createElement() with a babel transpiler build process.
- fijiaarone 3y agoExcuse me, I forgot that react-dom also ships with an implementation of document.appendChild()
- no_wizard 3y agoDo any of these have an ecosystem of accessibility tested components that pass the muster, e.g. like React Aria[0]? This is my minimum requirement of any ecosystem in 2024. It’s really important to get this right. [0]: https://react-spectrum.adobe.com/react-aria/getting-started.html https://react-spectrum.adobe.com/react-aria/getting-started....
- siliconc0w 3y agoI've been using Django Unicorn and been reasonably happy with it. I have run into some bugs and weird behavior but it's extremely pleasing to build even fairly sophisticated interfaces without any JS or the need for web-sockets.
- winrid 3y agoI had a nice experience at first but have moved away. Decent codebase with dozens of components, throwing it out. It's too fragile and breaks too often. Users will send screenshots of broken UIs and I feel helpless - not a good situation.
- miiiiiike 3y agoThe Django community goes out of its way not to learn JavaScript. I’ve been a Django developer since 2008; I was allergic to JavaScript (for good reasons) too. After almost five years of front-end development I can tell you that most of those reasons stopped being valid sometime between 2017 and 2020. JavaScript is a great experience now. I didn’t do it willingly. Front-end developers are expensive and hard to size up if you don’t know what Flexbox or a Promise is. If you’re going to be doing anything web related you might as well get comfortable with the fact that learning JavaScript, TypeScript, CSS, Sass, HTML, and something like RxJS is going to make you a better developer and your life easier.
- mutagen 3y agoNot just Django, the .NET and some other traditional server side communities have done their best to avoid JavaScript. Despite the churn, there are some great core technologies for the front end. Native browser functionality is much better than it used to be.
- miiiiiike 3y agoOh yeah, .NET [0] too. Layers upon layers of abstractions in C# just to be able to accomplish a fraction of what you could easily do in JavaScript. [0]: I was a C# developer for five years, but, with Mono, because I wanted to make sure I wouldn’t be employable.
- mattmanser 3y agoI don't feel that's really true. Try using the native date control or the number control. You also still can't easily style the select component. In React MUI, for example, they completely give up on it and use styled divs instead. But what would I know, I'm one of those incompetent .Net developers.
- em-bee 3y agobut that's a browser problem, not a frontend framework issue. you'd have the same limitation without a frontend framework, wouldn't you?
- teaearlgraycold 3y agoAnyone else actually having a great experience with full-stack typescript?
- winrid 3y agoIt can be nice, but TS the language lets you get really fancy and dealing with excited library developers gets old fast. Also the TS compiler tends to be buggy and break in weird ways with minor version changes.
- teaearlgraycold 3y agoI just try to not use too many libraries given the npm ecosystem. Sometimes you do need excited devs. When the domain is complicated I’d rather have fancy types than static analysis black holes.
- winrid 3y agoI don't think the choice is hard to understand types vs no types with most runtimes.
- presentation 3y agoIt’s great, except that the compiler’s really slow and that trickles down to editor slowdowns, slow CI, etc. Also need to understand it well enough both to understand complex types, but also to know not to go overboard with types. Built a couple businesses already on it.
- preommr 3y ago+1 I've found ts to be a good all-round project language. If I need something with performance, then golang if it's quick/dirty, rust if I need some more complex data modelling.
- winrid 3y agoUnicorn is nowhere near production ready. The main author makes major changes in untyped Python and JS without any unit tests and every minor version change has had major regressions that can be hard to catch.
- alfor 3y agoHTMX is gaining a lot of traction but is barely mentionned. Seem to be a good pattern of adding what is needed and otherwise keep things as they are. Do not have a lot of experience with it but I would gladly ditch our vue.js build process and docker image for the little web we actualy need to do.
- whizzter 3y agoAfter trying out htmx (for perhaps the wrong project), my feeling is kinda the opposite, it really didn't add much (if you want to just add css-animations to your otherwise static backend it's probably fine) but didn't help squat with actual work tasks (data and events updating the view), I ended up adding Vue to parts of it (and wrote another task with Vue from the start). One difference for me is that I only pick Vue for projects that are large enough to need fully front-end logic but small enough not to need a build-step (And one could equally well go for React once a project is large enough to need a build step), this is where Vue really shines since you get the auto updating goodess but don't need to burden yourself with any build script complications.
- hendi_ 3y agoWe've build (and open-sourced) our own livecomponents[1] for Django and based it on htmx. That way we got a ton of client side functionality for free and didn't have to reinvent the wheel. Just this week we've retired our old react based webapp and replaced it with our Django livecomponents. htmx is awesome! [1] https://github.com/om-proptech/livecomponents https://github.com/om-proptech/livecomponents
- drcongo 3y agoThat looks fun, thanks. Gonna try it out when I get a chance.
- tuan 3y agoI'm wondering why these frameworks keep using HTML as a "communication language" between server and client ? I meant server sends a HTML fragment to client for it to parse and update the current DOM. It makes sense for traditional web frameworks like Django to respond to client request with HTML, because it relies on browser's understanding of HTML text. But if these frameworks ship with JS anyway, why don't they use something else, like a data structure that is native in the programming language that they are written in, to describe the UI. Their JS component can parse that and render the UI. The JS component is basically just a templating engine on client side without all the routing, state management, etc complexities of a SPA framework. I feel like not using HTML for server and JS component could simplify a lot of things. I guess my assumption here is that both server side programming languages and JS could use a better data structure to communicate than HTML text. I'm not familiar with these new frameworks or have ever implemented a frontend framework, so I apologize for this probably silly question.
- csande17 3y agoThe approach you're describing is pretty much how frameworks like React work. I think there are two main reasons why the more lightweight options don't go for this: 1. In the React space, you have to write two conversion steps: first you have to convert your app's data to some wire format (JSON objects or something) on the server, then you have to convert the wire format into HTML on the client ("render" the UI). This is more complex than a single step where you just convert the app's data to HTML on the server. 2. For best performance, the server needs to be able to generate HTML and send it to the client on the initial page load. (React calls this "server-side rendering"; its approach to it doesn't really work for lightweight frameworks because it requires you run JavaScript on the server.) Once you have that capability, you might as well use it as much as possible, rather than implementing a separate code path just for JavaScript.
- rpmisms 3y agoI've heard great things about HTMX+Django.
- PrimeMcFly 3y agoI've yet to come across a use case where I would need or improve things by using HTMX
- rpmisms 3y agoTheoretically, you could have a single-file SPA using HTMX, Alpine JS, and Tailwind.
- PrimeMcFly 3y agoThat sounds gross. Why would anyone want that.
- rpmisms 3y agoFor fun? I did something similar to build a small site for a non-profit. Looks nice, easy to maintain, fun to build.
- strogonoff 3y agoI would be wary of mixing two frameworks in one project, since that would require the intersection of relevant skills from future developers or maintainers. One must be sufficiently familiar with both ends (and any idiosyncrasies of how they are used in this instance) in order to jump in and push changes that don’t mess everything up. If coming from Django side (which I did), consider whether you really need a separate framework for the front-end. Nowadays, JavaScript isn’t that hairy, and browser runtime comes with tons of batteries and syntax sugar that make it easy to write complex things. Maybe you want to use a small library like React (which is, of course, not a framework) for certain widgets, or even introduce an extra build step and write TypeScript, but sticking to vanilla overall can be key to managing cognitive load for others or your future self. Yes, maybe you’d need to write a tiny bit of boilerplate (much less than in IE6 days!), but on bright side—basic language reference (e.g., MDN) would be enough for anyone to grasp how it is generally put together. If you are considering using a framework and your front-end part is sufficiently complex for that then consider if you should rather architect it as a separate project. Putting strong boundaries in place can help keep it manageable, problems are isolated to one side, and it’d be more easy to find someone who is best at Django or best at (insert your front-end framework of choice) in future.
- em-bee 3y agoi strongly agree with the separation into two projects. that's the real advantage of frontend frameworks. for me backends are now only providing a REST or GraphQL API and no more HTML templating at all. the HTML stuff is done only in the frontend. that also takes care of the problem of overlapping skills. sure, you need to learn a new framework, but really, it is not that big of a deal. if you have been creating complete websites from CSS/HTML to the backend, it really doesn't change that much. your CSS/HTML skills apply unchanged, and the only thing that is new is javascript itself and a new templating system. the problem (as other commenters noted) stems from backend frameworks trying hard to avoid javascript. so they will try to do as much as they can in the backend, and i can imagine that throwing a full frontend framework into that is going to be challenging. i never tried it. as soon as i started using frontend frameworks 10 years ago, i was done with server side HTML generation.
- jamestimmins 3y agoSolid article, although part of the conclusion is a pitch to purchase the author's book on Django + Hotwire, so perhaps take with a grain of salt.