Recently, the necessity to build a portal for my team to share the current projects and their progress came into the picture, so I tought that this...
For further actions, you may consider blocking this person and/or reporting abuse
dev.to was vanilla JS on the frontend for most of its history until recently and still doesn't use a "framework" per se, but we do now use Preact for writing new UIs.
I'm not sure I'd skip the framework if you're really looking to be productive. I went vanilla as a forcing function to keep the frontend logic simple and basic while the project's direction, and for the major performance benefits of just not including more code.
If it is indeed simply an internal portal, it is possible that you don't need stateful complicated UIs in the first place and it definitely could make sense to simplify like that.
As things have grown, the original vanilla code is probably the worst part of the codebase, and that is probably tough to avoid.
Thank you Ben, maybe I`ll go with Preact too, I believe we'll have a very basic state (maybe no state at all, things are being defined yet).
But since Dev.to is using it, I'll definetely give it a go.
Thanks again.
Since it’s an internal tool I’d probably go with React over Preact. Preact is basically a lightweight implementation of the React API, which is great for high-traffic sites, but not all that important for an internal dashboard. It would be fine but probably just easier to go with the mainstream thing.
But I’d definitely be an advocate for using plain React without a state management system like Redux. IMO this is where simple problems get complicated.
For your needs, you’re probably good with whatever you pick. Just be cautious about over-designing and over-tooling and you’ll be good. Plain ole React really is quite simple, so makes for a good choice.
The project I am on right now is currently all vanilla JS for the front end. Which is really nice in its own way for a lot of things -- and there is a chunk of it that has a decent amount of UI, which is growing, and holy shit I forgot what a big pain in the ass it is to do that kind of thing involving stateful UI stuff in pure JS without something like React. I think frameworks are often jumped to too soon or relied on too much -- ie, very few things can or should be done purely in React as all one big thing, IMHO -- but hoooo boy.
Stimulus is a project in the Rails community which is an attempt to meet in the same middle. I buy it as a pretty decent option in a lot of conventional cases, but haven’t given it a spin yet.
I don't know of open source apps that I can point to that would implement something like Clean Architecture, but I would wholeheartedly recommend Uncle Bob's approach to frameworks: don't.
At least, not in the way that framework authors recommend using it. In his words, using a framework and accepting its idiomatic contract means you also sign up to being completely bound to it. You're married to it, and a divorce can be costly.
The way he recommends approaching the problem is to have a layered approach where you treat everything that doesn't deal with your business rules as a plugin to your business rules and entities.
Say you're writing an accountint app. Why would you put your business rules into Models, which inherit ActiveRecord, which in turn implements some SQL that indirectly limits what kinds of interactions your objects can perform?
To him, the database is just a plugin, a detail. The web (HTML, JS, CSS, HTTP, etc.) is a detail. If the code that uses the framework depends on your business rules by importing from a
gem,npm,jar,dllor whatever package mechanism you use, you will never be dependent on a particular framework.Sure, building a REST server or choosing React as your view library is fine, but don't extend those objects with your logic. Create objects within the framework that depend on your logic! If you ever need to switch from Rails to Next, ASP.NET MVC or Spring, it's just a matter of binding a different frontend to the same logic.
I think you're asking the wrong questions.
David isn't saying never use frameworks, he's saying use them when you need them
So how do you know?
David goes in more depth but:
Think about your requirements and whether that needs a framework to do what it's doing.
For an MVP of this I wouldn't even think about writing any Javascript
You asked for an example.
Here is my website, it lists posts and displays them. It was so easy to write, definitely easier than anything you'd write in react
100% zero JS. Yeah sure it's a "simple blog". But a lot of websites, when you boil them down a big, are simple blogs really.
If you really need some client-side rich behaviour, then by all means a framework may serve you well. Just make sure that's what you actually need.
I think Preact is a pretty safe bet. It’s a 3kb lib based on the most popular JS view API and interchangeable with other things.
One library to help write views is not creating the situation you’re describing. I’ve been involved in projects where all the things went down like you’re describing, but this is not one of them.
Tools like Jadve AI for writing and Pixlr X for images can help you stand out on the list of top social media platforms. Services like Postmypost for scheduling and ChatBotBuilderAI for chatting with your audience save time and let you focus on being creative. Using these tools is key for anyone wanting to improve their social media game!
One of the cool things about this site is that, even when it wasn't open source, the developers discussed their thoughts behind things. Ben posted a discussion thread giving the reasons they were considering Preact, and soliciting feedback on the experience.
Thinking about going with PreactJs for dev.to
Ben Halpern
In my experience, the main point of the "don't use frameworks" posts also includes "...until you realize you need it." :)
Pro: You get to write everything from scratch
Con: You have to write everything from scratch