Feed powered byStream Blue Logo Copy 5Created with Sketch.
JavaScript

JavaScript

Application and Data / Languages & Frameworks / Languages

Decision at Stream about Go, Stream, Python, Yarn, Babel, Node.js, ES6, JavaScript, Languages, FrameworksFullStack

Avatar of nparsons08
Node.js Engineer & Evangelist at Stream ·
GoGo
StreamStream
PythonPython
YarnYarn
BabelBabel
Node.jsNode.js
ES6ES6
JavaScriptJavaScript
#Languages
#FrameworksFullStack

Winds 2.0 is an open source Podcast/RSS reader developed by Stream with a core goal to enable a wide range of developers to contribute.

We chose JavaScript because nearly every developer knows or can, at the very least, read JavaScript. With ES6 and Node.js v10.x.x, it’s become a very capable language. Async/Await is powerful and easy to use (Async/Await vs Promises). Babel allows us to experiment with next-generation JavaScript (features that are not in the official JavaScript spec yet). Yarn allows us to consistently install packages quickly (and is filled with tons of new tricks)

We’re using JavaScript for everything – both front and backend. Most of our team is experienced with Go and Python, so Node was not an obvious choice for this app.

Sure... there will be haters who refuse to acknowledge that there is anything remotely positive about JavaScript (there are even rants on Hacker News about Node.js); however, without writing completely in JavaScript, we would not have seen the results we did.

#FrameworksFullStack #Languages

26 upvotes·1.4K views

Decision at Soluto about Docker Swarm, Kubernetes, Visual Studio Code, Go, TypeScript, JavaScript, C#, F#, .NET

Avatar of Yshayy
Software Engineer ·
Docker SwarmDocker Swarm
KubernetesKubernetes
Visual Studio CodeVisual Studio Code
GoGo
TypeScriptTypeScript
JavaScriptJavaScript
C#C#
F#F#
.NET.NET

Our first experience with .NET core was when we developed our OSS feature management platform - Tweek (https://github.com/soluto/tweek). We wanted to create a solution that is able to run anywhere (super important for OSS), has excellent performance characteristics and can fit in a multi-container architecture. We decided to implement our rule engine processor in F# , our main service was implemented in C# and other components were built using JavaScript / TypeScript and Go.

Visual Studio Code worked really well for us as well, it worked well with all our polyglot services and the .Net core integration had great cross-platform developer experience (to be fair, F# was a bit trickier) - actually, each of our team members used a different OS (Ubuntu, macos, windows). Our production deployment ran for a time on Docker Swarm until we've decided to adopt Kubernetes with almost seamless migration process.

After our positive experience of running .Net core workloads in containers and developing Tweek's .Net services on non-windows machines, C# had gained back some of its popularity (originally lost to Node.js), and other teams have been using it for developing microservices, k8s sidecars (like https://github.com/Soluto/airbag), cli tools, serverless functions and other projects...

17 upvotes·1 comment·26.2K views

Decision about JavaScript, Rails, Apollo, React

Avatar of holman
Zach Holman ·
JavaScriptJavaScript
RailsRails
ApolloApollo
ReactReact

Oof. I have truly hated JavaScript for a long time. Like, for over twenty years now. Like, since the Clinton administration. It's always been a nightmare to deal with all of the aspects of that silly language.

But wowza, things have changed. Tooling is just way, way better. I'm primarily web-oriented, and using React and Apollo together the past few years really opened my eyes to building rich apps. And I deeply apologize for using the phrase rich apps; I don't think I've ever said such Enterprisey words before.

But yeah, things are different now. I still love Rails, and still use it for a lot of apps I build. But it's that silly rich apps phrase that's the problem. Users have way more comprehensive expectations than they did even five years ago, and the JS community does a good job at building tools and tech that tackle the problems of making heavy, complicated UI and frontend work.

Obviously there's a lot of things happening here, so just saying "JavaScript isn't terrible" might encompass a huge amount of libraries and frameworks. But if you're like me, yeah, give things another shot- I'm somehow not hating on JavaScript anymore and... gulp... I kinda love it.

16 upvotes·3 comments·23.8K 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·2.3K views

Decision at Stitch about ES6, JavaScript, CoffeeScript, React, AngularJS

Avatar of jakestein
CEO at Stitch ·
ES6ES6
JavaScriptJavaScript
CoffeeScriptCoffeeScript
ReactReact
AngularJSAngularJS

Stitch’s frontend is used to configure data sources and destinations and monitor the status of each. Although we have been using AngularJS since its early days, we recently introduced React components into our front end, which many of our developers find easier to work with. We started using CoffeeScript when it was one of the few options for a more expressive alternative to vanilla JavaScript, but today we opt to instead write new code in ES6, which we feel is a more mature alternative.

15 upvotes·2 comments·2.3K views

Decision at Stitch about Go, Clojure, JavaScript, Python, Kubernetes, AWS OpsWorks, Amazon EC2, Amazon Redshift, Amazon S3, Amazon RDS

Avatar of jakestein
CEO at Stitch ·
GoGo
ClojureClojure
JavaScriptJavaScript
PythonPython
KubernetesKubernetes
AWS OpsWorksAWS OpsWorks
Amazon EC2Amazon EC2
Amazon RedshiftAmazon Redshift
Amazon S3Amazon S3
Amazon RDSAmazon RDS

Stitch is run entirely on AWS. All of our transactional databases are run with Amazon RDS, and we rely on Amazon S3 for data persistence in various stages of our pipeline. Our product integrates with Amazon Redshift as a data destination, and we also use Redshift as an internal data warehouse (powered by Stitch, of course).

The majority of our services run on stateless Amazon EC2 instances that are managed by AWS OpsWorks. We recently introduced Kubernetes into our infrastructure to run the scheduled jobs that execute Singer code to extract data from various sources. Although we tend to be wary of shiny new toys, Kubernetes has proven to be a good fit for this problem, and its stability, strong community and helpful tooling have made it easy for us to incorporate into our operations.

While we continue to be happy with Clojure for our internal services, we felt that its relatively narrow adoption could impede Singer's growth. We chose Python both because it is well suited to the task, and it seems to have reached critical mass among data engineers. All that being said, the Singer spec is language agnostic, and integrations and libraries have been developed in JavaScript, Go, and Clojure.

13 upvotes·931 views

Decision at Eventbrite about Backbone.js, JavaScript, Britecharts

Avatar of Golodhros
Sr. Software Engineer at Eventbrite ·
Backbone.jsBackbone.js
JavaScriptJavaScript
BritechartsBritecharts

Britecharts was created from the point of view of just using it as a JavaScript-agnostic library. That worked really well with our Backbone.js builds. We just use a render and initialize all the stuff there.

Now moving into React, we have the necessity of actually moving Britecharts into React land. That's something we're gonna start working on. That is a wrapper of our Britecharts in order to be used with React. And we are really excited about that.

12 upvotes·533 views

Decision about HTML5, Ruby, Babel, Webpack, Visual Studio Code, GraphQL, Graphcool Framework, Figma, TypeScript, JavaScript, Framework7, Css

Avatar of jdspugh
Software Engineer / Project Manager / Technical Architect ·
HTML5HTML5
RubyRuby
BabelBabel
WebpackWebpack
Visual Studio CodeVisual Studio Code
GraphQLGraphQL
Graphcool FrameworkGraphcool Framework
FigmaFigma
TypeScriptTypeScript
JavaScriptJavaScript
Framework7Framework7
#Css

I needed to choose a full stack of tools for cross platform mobile application design & development. After much research, trying different tools, and 18 years of mobile design & development, these are what I came up with that work for me today:

For the client coding I chose Framework7 because of its performance, easy learning curve and very well designed, beautiful UI widgets. I think it's perfect for solo development or small teams. I didn't like React Native. It felt heavy to me and rigid. Framework7 allows the use of #CSS, which I think is the best technology to come out of the #WWW movement. No other tech has been able to allow designers and developers to develop such flexible, high performance, customisable user interface elements that are highly responsive and hardware accelerated before. React Native contains a very limited interpretation of #CSS which I found very frustrating after using #CSS for some years already and knowing its powerful features. The other very nice feature of Framework7 is that you can even build for the browser if you want your app to be available for desktop web browsers. This is not possible with React Native yet.

JavaScript is very far from an ideal language, to say the least. To make life bearable I managed to configure TypeScript to work with the latest version of Framework7. This makes me feel like I'm back in the good old Java days. I consider TypeScript to be one of the rare best creations to come out of Microsoft in some time. They must have an amazing team working on it. It's very powerful and flexible.

For the user interface design and prototyping I use Figma. Figma has an almost identical user interface to Sketch but has the added advantage of being cross platform (MacOS and Windows). Its real-time collaboration features are outstanding and I use them a often as I work mostly on remote projects. Clients can collaborate in real-time and see changes I make as I make them. The clickable prototyping features in Figma are also very well designed and mean I can send clickable prototypes to clients to try user interface updates as they are made and get immediate feedback.

For the UI icons I use Font Awesome Pro. They have the largest selection and best looking icons you can find on the internet.

For the backend I chose Graphcool Framework. It has great customer support and a very accessible free startup plan for working on new projects. I was never a fan of relational databases so I'm very pleased to see NoSQL / GraphQL databases coming to the fore and I'm happy to use them. No more server side API development required! NoSQL databases are so much more flexible and the way I think databases were meant to be from the start.

For the IDE I use Visual Studio Code which is blazingly fast and silky smooth for editing code with the ultimate TypeScript checking (since both products are written by Microsoft).

I use Webpack and Babel to compile the JavaScript. TypeScript can compile to JavaScript directly but Babel offers a few more options and polyfills so you can use the latest JavaScript features today and compile to be backwards compatible with virtually any browser.

I use some Ruby scripts to process images with ImageMagick and pngquant to optimise for size and even auto insert responsive image code into the HTML5. Ruby is the ultimate cross platform scripting language. Even as your scripts become large, Ruby allows you to refactor your code easily and make it Object Oriented if necessary. I find it the quickest and easiest way to maintain certain aspects of my build process.

What tools do you use? Have you tried these ones?

11 upvotes·5 comments·3.1K views

Decision at Codecov about Visual Studio Code, Vue.js, CoffeeScript, JavaScript, TypeScript

Avatar of hootener
CTO at Codecov ·
Visual Studio CodeVisual Studio Code
Vue.jsVue.js
CoffeeScriptCoffeeScript
JavaScriptJavaScript
TypeScriptTypeScript

We chose TypeScript at Codecov when undergoing a recent rewrite of a legacy front end. Our previous front end was a mishmash of vanilla JavaScript and CoffeeScript , and was expanded upon haphazardly as the need arose. Without a unifying set of paradigms and patterns, the CoffeeScript and JavaScript setup was proving hard to maintain and expand upon by an engineering team. During a move to Vue.js , we decided to also make the move to TypeScript. Integrating TypeScript and Vue.js is fairly well understood at this point, so the setup wasn't all that difficult, and we felt that the benefits of incorporating TypeScript would outweigh the required time to set it up and get our engineering team up to speed.

Choosing to add TypeScript has given us one more layer to rely on to help enforce code quality, good standards, and best practices within our engineering organization. One of the biggest benefits for us as an engineering team has been how well our IDEs and editors (e.g., Visual Studio Code ) integrate with and understand TypeScript . This allows developers to catch many more errors at development time instead of relying on run time. The end result is safer (from a type perspective) code and a more efficient coding experience that helps to catch and remove errors with less developer effort.

9 upvotes·21.4K views

Decision at Kokoen GmbH about ExpressJS, Node.js, JavaScript, MongoDB, Go, MySQL, Laravel, PHP

Avatar of ASkenny
CEO at Kokoen GmbH ·
ExpressJSExpressJS
Node.jsNode.js
JavaScriptJavaScript
MongoDBMongoDB
GoGo
MySQLMySQL
LaravelLaravel
PHPPHP

Back at the start of 2017, we decided to create a web-based tool for the SEO OnPage analysis of our clients' websites. We had over 2.000 websites to analyze, so we had to perform thousands of requests to get every single page from those websites, process the information and save the big amounts of data somewhere.

Very soon we realized that the initial chosen script language and database, PHP, Laravel and MySQL, was not going to be able to cope efficiently with such a task.

By that time, we were doing some experiments for other projects with a language we had recently get to know, Go , so we decided to get a try and code the crawler using it. It was fantastic, we could process much more data with way less CPU power and in less time. By using the concurrency abilites that the language has to offers, we could also do more Http requests in less time.

Unfortunately, I have no comparison numbers to show about the performance differences between Go and PHP since the difference was so clear from the beginning and that we didn't feel the need to do further comparison tests nor document it. We just switched fully to Go.

There was still a problem: despite the big amount of Data we were generating, MySQL was performing very well, but as we were adding more and more features to the software and with those features more and more different type of data to save, it was a nightmare for the database architects to structure everything correctly on the database, so it was clear what we had to do next: switch to a NoSQL database. So we switched to MongoDB, and it was also fantastic: we were expending almost zero time in thinking how to structure the Database and the performance also seemed to be better, but again, I have no comparison numbers to show due to the lack of time.

We also decided to switch the website from PHP and Laravel to JavaScript and Node.js and ExpressJS since working with the JSON Data that we were saving now in the Database would be easier.

As of now, we don't only use the tool intern but we also opened it for everyone to use for free: https://tool-seo.com

8 upvotes·3K views