191–200 of 453 posts
And also you should learn packaging to include dependencies by mentioning those in a single file. Parcel bundler has been working very good for me as it is fast (webpack is complicated and not fast) and incremental build is a fraction of a second.
Earlier quoted context omitted.
No, not right. I have work on a daily base with redux unfortunately. Redux is not too hard, but it's poor in design. Also you will have to give up redux soon, the hype is over and better things are at the horizon. There is definitely some pride in dev's working with redux, once they understand it they feel like they've grown as a developer. Do you really think redux is the holy grail of stores? If you're really smart…
You haven't explained why it's "poor in design".
My safe enterprise monolith stack for long term maintainability and high productivity is: Backend: Django Realtime/DB: Realm + Postgres Frontend: Angular Surprised few have mentioned Angular yet. It is highly opinionated unlike React, and backed by a giant unlike Vue. Seems like a safer enterprise choice.
Agree on that point , I like Angular because it's opinionated compared to React.
> and backed by a giant unlike Vue
Strongly disagree , Vue is backed by many large corporations and unlike AngularJS was designed to guarantee backward compatibility.
AngularJS not being compatible with Angular is what has killed for good the frameworks and left thousands of entreprises in dust when they believed angular would become a standard because "it's backed by a giant".
Workings for banking sector , I've many customers build CRM or KYC applications on top of Nuxt. Developers love the Vue ecosystem.
> Seems like a safer enterprise choice.
Strongly disagree here as well.
Angular is a great framework but it has absolutely unacceptable build size,
A "Hello World" using Angular 7 with Ivy Rendering is 500KB+ ( tested this morning ). This is not acceptable for modern frameworks to be that big.
Vue and React stay largely under 100KB in terms of build size.
They are lots of scenarios where picking Angular over Vue & React would made things more complex for a project.
- On the frontend, use React with TypeScript. Create React App now makes it dead easy. Just do: npx create-react-app myapp --typescript - Do not use redux until you know React well. You might not need it. If you do need it, use `redux-starter-kit` offered by the core Redux team. - For backend, just use Django (or Rails). Elixir's Phoenix is also very well thought out. - If you use node: express, sequelize. Async/awai…
> - Do not use redux until you know React well. You might not need it. Indeed, I would say not using redux at all. I never understood why redux has become so popular, IMAO it's such poor design. It forces you to use switch statements, reducers, mapStateToProps(why?), etc.. Tons of boilerplate in order to set 1 single variable. Not talking about how to put data from the backend into the store in a SSR app.. I'm now us…
MobX is a much better fit for most react apps IMHO. Redux could be good, if you have a database [id] driven application, but for most people is way too restrictive.
If you are working in a small team, and are using Redux, you are probably making life harder than it has to be.
For static websites, https://getstatik.com/ For “dynamic” websites, Mithril ( https://mithril.js.org/ ) and Redux written in Haxe ( https://haxe.org/ ) on the front end with Rocket ( https://rocket.rs/ ) and SQLite on the backend, proxied behind nginx with Let’s Encrypt on the backend. Personal projects hosted on a VM at Linode, company projects hosted on VMs at Google Cloud. It’s a somewhat unique stack but I love i…
Its an interesting stack, for sure. I'm only surprised by the sqlite choice. With such a concurrent and speedy backend, what do you do about concurrent writes and the lack of row/page level locking in sqlite?
I am looking at React on the front-end instead of vue, due to how much easier it is to hire for react.
The isomorphic/universal rendering is really awesome for node on the server, one set of templates vs two, plus it seems like the GraphQL stuff is way more mature on node. We're not currently using GraphQL, but having that option open to us is nice.
Combined with all the success stories from Linkedin, Paypal and even Walmart around moving stuff to node, it's also an easy decision to defend.
I'm not a huge fan of debugging node, that could be a bit improved, but overall I am happy with the choice to try to build everything in node unless there's a compelling reason not to.
Earlier quoted context omitted.
We've been following this stalk for quite a while and are super happy with it. But there's huge downside: It's really hard to find Django/ Python engineers - let alone phoenix devs. Right now I'm considering a move to JVM. But the frameworks i've seen are all far behind Django. Any thoughts?
Play framework (with Slick or Quill for data access) can get you most of the way there, but you won't have Django's out-of-the-box admin interface, have to roll your own. If you add in Akka or Akka Typed then you can pass state changes for connected websocket clients (i.e. for a SPA/Redux based frontend), which is quite awesome. Scala and Scala.js are a powerful combination if you want to do everything in the same la…
Do you have any recommendations?
If you go for React, I would highly recommend Mobx for state management. And create-react-app + yarn eject to get started. CRA is a joy to work with. Mobx is a bit more difficult to grok and debug for newcomers than Redux, but it's really really fast, easy to test and requires little boilerplate. On the other hand you get reactive state management by default in Vue. If you use Node for the backend I can recommend usi…
I am surprised no one has mentioned Pyramid and SQLAlchemy yet. SQLAlchemy is by far the most complete ORM/Query-Builder I have used (yes, I have tried out Rails, Django and Hibernate). Also Pyramid's traversal routing is awesome to build REST-applications and ACL authorization. What ever stack you decide on, I recommend to stay away from too much magic as it complicates debugging and understanding the framework comp…
Lots of folks love sqlalchemy. I just don't get it. I only have to use it infrequently, but when I do, I spend very little time crafting my SQL and a much longer time translating it to sqlalchemy's query builder. Even a join is a PITA.
Regarding the joins:
j=t_user.join(t_address, t_user.c.id==t_address.c.user_id)
select([...], from_obj=j)