Feed powered byStream Blue Logo Copy 5
jQuery

jQuery

Application and Data / Libraries / Javascript UI Libraries

Decision at Heap about MobX, React, TypeScript, Marionette, Backbone.js, jQuery, TemplatingLanguagesExtensions, JavascriptMvcFrameworks, Libraries, JavascriptUiLibraries

Avatar of drob
MobXMobX
ReactReact
TypeScriptTypeScript
MarionetteMarionette
Backbone.jsBackbone.js
jQueryjQuery
#TemplatingLanguagesExtensions
#JavascriptMvcFrameworks
#Libraries
#JavascriptUiLibraries

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

18 upvotes·6.7K views

Decision at Shopify about Prototype, TypeScript, React, JavaScript, jQuery, Languages, FrameworksFullStack

Avatar of kirs
Production Engineer at Shopify ·
PrototypePrototype
TypeScriptTypeScript
ReactReact
JavaScriptJavaScript
jQueryjQuery
#Languages
#FrameworksFullStack

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

16 upvotes·1 comment·6.9K views

Decision about Fastly, Grunt, jQuery, Bootstrap, Jekyll, Let's Encrypt, Netlify, GitHub Pages, MaxCDN, StaticSiteGenerators, Webperf, GoogleFonts, CDN

Avatar of jdorfman
open source sustainer at SustainOSS ·
FastlyFastly
GruntGrunt
jQueryjQuery
BootstrapBootstrap
JekyllJekyll
Let's EncryptLet's Encrypt
NetlifyNetlify
GitHub PagesGitHub Pages
MaxCDNMaxCDN
#StaticSiteGenerators
#Webperf
#GoogleFonts
#CDN

When my SSL cert on MaxCDN was expiring on my personal site I decided it was a good time to revamp some things. Since GitHub Services is depreciated I can no longer have #CDN cache purges automated among other things. So I decided on the following: GitHub Pages, Netlify, Let's Encrypt and Jekyll. Staying the same was Bootstrap, jQuery, Grunt & #GoogleFonts.

What's awesome about GitHub Pages is that it has a #CDN (Fastly) built-in and anytime you push to master, it purges the cache instantaneously without you have to do anything special. Netlify is magic, I highly recommend it to anyone using #StaticSiteGenerators.

For the most part, everything went smoothly. The only things I had issues with were the following:

  • If you want to point www to GitHub Pages you need to rename the repo to www
  • If you edit something in the _config.yml you need to restart bundle exec jekyll s or changes won't show
  • I had to disable the Grunt htmlmin module. I replaced it with Jekyll layout that compresses HTML for #webperf

Last but certainly not least, I made a donation to Let's Encrypt. If you use their service consider doing it too: https://letsencrypt.org/donate/

8 upvotes·1 comment·5.1K views

Decision at SIA Monkey See Monkey Do about jQuery, Bootstrap, PostgreSQL, Django, Python

Avatar of cuu508
jQueryjQuery
BootstrapBootstrap
PostgreSQLPostgreSQL
DjangoDjango
PythonPython

Python Django PostgreSQL Bootstrap jQuery

Healthchecks.io is a SaaS cron monitoring service. I needed a tool to monitor my cron jobs. I was not happy with the existing options, so I wrote one. The initial goal was to get to a MVP state, and use it myself. The followup goals were to add functionality and polish the user interface, while keeping the UI and the under the hood stuff as simple and clean as possible.

Python and DJango were obvious choices as I was already familiar with them, and knew that many of Django's built-in features would come handy in this project: ORM, testing infrastructure, user authentication, templates, form handling.

On the UI side, instead of doing the trendy "React JS app talking to API endpoints" thing, I went with the traditional HTML forms, and full page reloads. I was aiming for the max simplicity. Paraphrasing Kevin from The Office, why waste time write lot JS when form submit do trick. The frontend does however use some JS, for example, to support live-updating dashboards.

The backend is also aiming for max simplicity, and I've tried to keep the number of components to the minimum. For example, a message broker or a key-value store could be handy, but so far I'm getting away with storing everything in the Postgres database.

The deployment and hosting setup is also rather primitive by today's standards. uWSGI runs the Django app, with a nginx reverse proxy in front. uWSGI and nginx are run as systemd services on bare metal servers. Traffic is proxied through Cloudflare Load Balancer, which allows for relatively easy rolling code upgrades. I use Fabric for automating server maintenance. I did use Ansible for a while but moved back to Fabric: my Ansible playbooks were slower, and I could not get used to mixing YAML and Jinja templating.

Healthchecks.io tech decisions in one word: KISS. Use boring tools that get the job done.

6 upvotes·2.9K views

Decision about Yarn, Redux.js, React, jQuery, vuex, Vue.js, MongoDB, Redis, PostgreSQL, Sidekiq, Rails, Font-awesome, Bulma.io

Avatar of cyrusstoller
YarnYarn
Redux.jsRedux.js
ReactReact
jQueryjQuery
vuexvuex
Vue.jsVue.js
MongoDBMongoDB
RedisRedis
PostgreSQLPostgreSQL
SidekiqSidekiq
RailsRails
#Font-awesome
#Bulma.io

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.

5 upvotes·5.2K views