Need advice about which tool to choose?Ask the StackShare community!
jQuery vs Webix: What are the differences?
jQuery: The Write Less, Do More, JavaScript Library. jQuery is a cross-platform JavaScript library designed to simplify the client-side scripting of HTML; Webix: A powerful JavaScript UI library that gives developers a cross-browser tool for building responsive HTML 5-based web apps. It is a cross-browser JavaScript UI widgets library. Build fast mobile and desktop web applications that run on all touch devices with HTML5 framework.
jQuery and Webix belong to "Javascript UI Libraries" category of the tech stack.
jQuery is an open source tool with 52K GitHub stars and 18.4K GitHub forks. Here's a link to jQuery's open source repository on GitHub.
What is jQuery?
What is Webix?
Need advice about which tool to choose?Ask the StackShare community!
Why do developers choose jQuery?
- Cross-browser1.3K
- Power808
- Open source662
- Plugins610
- Easy459
- Popular397
Why do developers choose Webix?
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using jQuery?
What are the cons of using Webix?
What companies use jQuery?
What companies use Webix?
Sign up to get full access to all the companiesMake informed product decisions
What tools integrate with jQuery?
What tools integrate with Webix?
Sign up to get full access to all the tool integrationsMake informed product decisions
Late in 2014, around the time of the Series D, the WeWork engineering team had grown to 14, and while the backend was modernized with Rails and Active Admin CMS, the main website was lacking. The new headcount provided enough capacity to address the aging WordPress website.
As the team experimented with front-end technologies, they implemented a new signup flow with Angular, and other flows, including the Market Page, in React and Redux. The team says of that time: “If you’re following closely, yes, this means that in one rails app we had pages that included one or many of the following: jQuery, Angular, and React.”
By mid-2015, around the time of the Series E, the Digital department at WeWork had grown to more than 40 people to support the company’s growing product needs.
By then, they’d migrated the main website off of WordPress to Ruby on Rails, and a combination React, Angular, and jQuery, though there were efforts to move entirely to React for the front-end.
The backend was structured around a microservices architecture built partially in Node.js, along with a combination of Ruby, Python, Bash, and Go. Swift/Objective-C and Java powered the mobile apps.
These technologies power the listings on the website, as well as various internal tools, like community manager dashboards as well as RFID hardware for access management.
The client-side stack of Shopify Admin has been a long journey. It started with HTML templates, jQuery and Prototype. We moved to Batman.js, our in-house Single-Page-Application framework (SPA), in 2013. Then, we re-evaluated our approach and moved back to statically rendered HTML and vanilla JavaScript. As the front-end ecosystem matured, we felt that it was time to rethink our approach again. Last year, we started working on moving Shopify Admin to React and TypeScript.
Many things have changed since the days of jQuery and Batman. JavaScript execution is much faster. We can easily render our apps on the server to do less work on the client, and the resources and tooling for developers are substantially better with React than we ever had with Batman.
#FrameworksFullStack #Languages
The front end for Heap begun to grow unwieldy. The original jQuery pieces became difficult to maintain and scale, and a decision was made to introduce Backbone.js, Marionette, and TypeScript. Ultimately this ended up being a “detour” in the search for a scalable and maintainable front-end solution. The system did allow for developers to reuse components efficiently, but adding features was a difficult process, and it eventually became a bottleneck in advancing the product.
Today, the Heap product consists primarily of a customer-facing dashboard powered by React, MobX, and TypeScript on the front end. We wrote our migration to React and MobX in detail last year here.
#JavascriptUiLibraries #Libraries #JavascriptMvcFrameworks #TemplatingLanguagesExtensions
I'm building a new process management tool. I decided to build with Rails as my backend, using Sidekiq for background jobs. I chose to work with these tools because I've worked with them before and know that they're able to get the job done. They may not be the sexiest tools, but they work and are reliable, which is what I was optimizing for. For data stores, I opted for PostgreSQL and Redis. Because I'm planning on offering dashboards, I wanted a SQL database instead of something like MongoDB that might work early on, but be difficult to use as soon as I want to facilitate aggregate queries.
On the front-end I'm using Vue.js and vuex in combination with #Turbolinks. In effect, I want to render most pages on the server side without key interactions being managed by Vue.js . This is the first project I'm working on where I've explicitly decided not to include jQuery . I have found React and Redux.js more confusing to setup. I appreciate the opinionated approach from the Vue.js community and that things just work together the way that I'd expect. To manage my javascript dependencies, I'm using Yarn .
For CSS frameworks, I'm using #Bulma.io. I really appreciate it's minimal nature and that there are no hard javascript dependencies. And to add a little spice, I'm using #font-awesome.