Do you have a strong preference? I've been using CSS Modules but I'm constantly wondering if Styled Components is better -- it seems like less work to add styles, at least.
No strong preference, I like both. But styled-components beed to ve road tested in a large project before we can appraise wether they're ready for a production ready boilerplate.
Caddy is an HTTP/2 webserver written in Go that integrates with ACME and serves websites of TLS by default. It powers https://paragonie.com and manages our HTTPS certificates automatically.
A lot of the "PHP sucks" arguments focus on things that haven't been true about the language since 5.4 (or earlier), but one thing that truly did suck was dependency management (before composer came around).
Dependency management also sucks in other languages (and still sucks in those). I suspect that's why few used that as a criticism of PHP.
+1 for twig when using PHP. Also, if working in Wordpress, the combination of ACF and Timber (twig for Wordpress) will get rid of a lot of frustrations.
I've been using PHP for most of my life, and used various template engine and it always end up with one question : what is the real purpose of a template engine in PHP instead of just using PHP ? When I see the examples in twig homepage it just looks like they tried to make PHP examples verbose for the sake of it.
I don't really mind them, but I find it extremely boring to have to register in the template engine every function that you will end up using somewhere else in your code and eventually have a language with less feature than plain old PHP and an other layer of cache.
So which use cases make you need Twig, for instance ?
Okay, I've never worked with a designer that would touch code, so there is that. Macros seem a bit redundant with partial views in my opinion, except they take fixed parameters, but this is a interesting concept.
I do all my group collaboration with it, and am no longer subject to Google's whims about my data. Sandstorm predates 2016, but has really accomplished a lot in 2016.
I have way too many to list, so I figure that I'll list one old school one that I have been using for years and one that I only started using in 2016.
This year, I made my first foray into building non-trivial web applications with Angular. Despite (or perhaps because of) that, I was quickly filled with a brand new respect for good old jQuery. I have yet to find such a simple, maintainable, readable way to parse complicated DOMs.
The list is massive. But the short list is Ruby and the entire Ruby on Rails ecosystem, PostgreSQL, Linux, and bash. Upon these rocks I earn most of my living. And none of this would be possible without the GNU Compiler Collection.
I love it. To the point that I think it's application architecture to rule all architectures. I dream of a brand new Unix based OS that adopts this architecture as it's standard over MVC.
I'm increasingly convinced that redux is the wrong way to manage most state. I see the pattern get abused greatly for state that should be more localized.
Im not sure I agree (or maybe I dont understand what you're saying). For me, all state, no matter how trivial, should be on the store. For UI state that can seem excessive, but its possible to use middleware and decorators to simplify that. Local state in my experience means bugs.
The problem is when different views require the same concept of some state but they don't really want it global to the application to bleed into other views. A redux-like pattern makes it very simple to put that state into a store, but then you're stuck reseting it every time you switch views, which can make it very easy to introduce timing bugs and just increases the surface area where bugs can introduce since more code gets written for logic that ultimately is the wrong abstraction for these situations.
I suspected this would be the case when first reading about redux, and dealing with it at practice in work, the consequences can be quite bad.
Not to say that some concept of global application state is bad - one always has it. It is incorrectly making it global when you really want an instance of it for a particular view. Redux itself isn't bad as it helps manage an important situation, but it is too much of a facilitator of this antipattern when it comes to state that absolutely should not bleed across views.
I still dont think I grasp what your describing. The store isnt global. And you usually have domains on the store to namespace particular bits of state. But if need be, any part of your app can access that state if it needs to without having to dig down into your UI hierarchy which will likely change over time.
without wanting to sound patronising, but I wonder wether you're structuring things incorrectly.
I understand the feeling that it seems strange to manage all state, no matter how small, in a large global state. However, every now and then I'll work with a designer or UX person who will connect seemingly unrelated elements in a powerful way, and I'll realize how freeing the global state becomes. The potential to easily explore new relationships between UI elements is wonderful.
Edit: Also, I should mention that taking advantage of the great middleware options for isolating side effects makes redux a treat to work with. I am using redux-observables, but I have heard great things about redux-sagas as well.
I've definitely felt that when using Redux even in some very simple projects. Just last night, for instance, I felt like I was doing acrobatics just to make a simple state update because a particular branch of the state required knowledge of state that was handled by a different reducer in order to do the update. However, as I struggled with navigating that issue, it slowly became really clear to me that the patterns Redux was enforcing (and which I was trying aggressively to circumvent) were actually to my benefit, and instead of circumventing it I just thought a bit harder about how my architecture and how to properly achieve what I wanted within the Redux paradigm. There will always be cases where libraries like Redux break down and you will feel like you are trying to fit a round peg in a square hole. But, at the end of the day, it's all just functions and objects being passed around and you have to judge the value in the library in the kinds of conventions and patterns it encourages and discourages. For me -- especially since I am admittedly a mediocre programmer at best -- the structure it enforced on my code organization and logic has been a blessing.
If you are grateful for some open source projects you should try to contribute to them next year as a new years resolution either by donating your time or money to them.
I completely agree. I try to support the open source projects I depend on via financial contributions (purchasing books/training/services offered by the organizations or Patreon). I also submit pull requests for documentation updates and answer questions in forums. One of my goals for 2017 is to contribute some source code pull requests.
It's curious to me how unpopular this sentiment is here. Are there actually people who think the Web provides a better user experience in 2016 than it did in 2006? I'm frankly baffled at that and would love to hear from somebody who feels that way.
People have always made bad, unusable websites. If we wanted to prevent them from doing that we should have never moved away from Gopher.
I write SPAs for a living and a lot of the technologies mentioned in this thread are a godsend. Whenever somebody expresses the above sentiment I feel it's only because they never had to maintain a complicated web app.
Correct: we used to write websites that were as simple as it was feasible for them to be, with as few client-side requirements as possible. It's the whole idea that "complicated web apps" are good things that I dislike.
Do you think Facebook could exist if we eschewed building complicated things on the web? The alternative is not building a simpler website, it's building desktop applications. Just because some developers choose the wrong tools for the job doesn't mean the tools aren't necessary.
Indeed, it doesn't. But I think it's not the tools, it's the businesses who do not understand tech, and the engineers, who are not strong enough to say no to random, tight deadlines, accepting worse quality for the sake of shipping.
The jump from 4.5.x to 4.6.x included a huge number of commits from a small core of people, and the future looks bright. My 'thank you' is in the form of written thanks to the development team and contributors, and I'm aiming to increase my regular commitments to helping with docs and other non-dev tasks to half a day per week in 2017.
It's a remote backup tool that solved all the problems. It's basically duplicity[2] but without the unfortunate design fault of having to re-upload all your data every few months.
Our[3] customers love it and we see new deployments of it (even among existing customers) every single day.
I can't believe I excluded VS Code from my list--and I wrote the article yesterday. It really shows how much we take for granted when it comes to open source.
VS Code became my primary code/Markdown editor in 2016. It improves steadily each month [1] and already has a great extension ecosystem and community. It also spurred my switch to Markdown for all note-taking due to its powerful integrated Markdown features.
Thank you to the VS Code team and Microsoft for sponsoring the project.
If I'm picking just one it would be webpack. It might not be sexy but it wrangles so much complexity out of my projects - files for disparate technologies (JS, CSS, Vue.js templates, CSV, whatever) can all declare dependencies against one another, and somehow each one gets parsed and bundled and minimized the way it needs to be. It's pretty glorious.
Definitely Matteo Centenaro[0] and Andrea Dal Ponte[1] for their incredible contributions to Tomatoes[2], and our supporters[3] who boosted our morale and made the project sustainable.
My vote goes to Michel Weststrate for his amazing work with MobX [1]. I was really unhappy with all of the client-side data management options (Flux, redux, et al) until this came along. Many thanks Michel for making my day to day frontend life much more enjoyable!
I'm going to go with Preact [1]. I'm a 'full-stack' developer (primarily backend) who recently took my first frontend gig and my first real foray into this world has been with Preact and I really enjoy it. I don't feel as if I'm 'losing out' by not using React, since it has the same API, and have really come to believe in it's ethos as a project to keep the library size, and therefore the download + parse time, incredibly small but also providing performant functionality. The author is a great guy who's really responsive as well.
The developer of Vue.js even though I haven't finished by project just yet thanking him ahead of time for giving me an alternative to working with big company projects. Also the teams behind node and express.the team behind Mariadb for giving me an alternative to oracles MySQL. The Apache Prediction team as well so I can use machine learning without having to write everything from scratch with tensor flow.
57 comments
[ 5.0 ms ] story [ 112 ms ] thread- https://github.com/mholt/caddy
Caddy is an HTTP/2 webserver written in Go that integrates with ACME and serves websites of TLS by default. It powers https://paragonie.com and manages our HTTPS certificates automatically.
- https://github.com/twigphp/Twig
Twig is one of the sane templating languages for PHP projects that I use extensively.
- https://github.com/composer/composer
Composer revolutionized PHP development.
A lot of the "PHP sucks" arguments focus on things that haven't been true about the language since 5.4 (or earlier), but one thing that truly did suck was dependency management (before composer came around).
Dependency management also sucks in other languages (and still sucks in those). I suspect that's why few used that as a criticism of PHP.
- https://github.com/jedisct1/libsodium
Libsodium: modern cryptography that you can likely find bindings for in your favorite programming language.
I don't really mind them, but I find it extremely boring to have to register in the template engine every function that you will end up using somewhere else in your code and eventually have a language with less feature than plain old PHP and an other layer of cache.
So which use cases make you need Twig, for instance ?
It also makes it easier to separate your presentation logic from your business logic.
For example: https://github.com/paragonie/airship/blob/master/src/Cabin/B...
This uses macros and other fun things. Doing that in PHP would get messy.
https://github.com/paragonie/airship/blob/master/src/Cabin/B...
I do all my group collaboration with it, and am no longer subject to Google's whims about my data. Sandstorm predates 2016, but has really accomplished a lot in 2016.
This year, I made my first foray into building non-trivial web applications with Angular. Despite (or perhaps because of) that, I was quickly filled with a brand new respect for good old jQuery. I have yet to find such a simple, maintainable, readable way to parse complicated DOMs.
https://github.com/jquery/jquery
I first started working with the Slim Framework in March. Over those nine months, it has become an absolutely indispensable tool for me.
https://github.com/slimphp/Slim
https://github.com/reactjs/redux
I love it. To the point that I think it's application architecture to rule all architectures. I dream of a brand new Unix based OS that adopts this architecture as it's standard over MVC.
I suspected this would be the case when first reading about redux, and dealing with it at practice in work, the consequences can be quite bad.
Not to say that some concept of global application state is bad - one always has it. It is incorrectly making it global when you really want an instance of it for a particular view. Redux itself isn't bad as it helps manage an important situation, but it is too much of a facilitator of this antipattern when it comes to state that absolutely should not bleed across views.
without wanting to sound patronising, but I wonder wether you're structuring things incorrectly.
Edit: Also, I should mention that taking advantage of the great middleware options for isolating side effects makes redux a treat to work with. I am using redux-observables, but I have heard great things about redux-sagas as well.
I would add Chrome, Node.js, Babel, Webpack, Knex, MySQL.
I write SPAs for a living and a lot of the technologies mentioned in this thread are a godsend. Whenever somebody expresses the above sentiment I feel it's only because they never had to maintain a complicated web app.
Correct: we used to write websites that were as simple as it was feasible for them to be, with as few client-side requirements as possible. It's the whole idea that "complicated web apps" are good things that I dislike.
The jump from 4.5.x to 4.6.x included a huge number of commits from a small core of people, and the future looks bright. My 'thank you' is in the form of written thanks to the development team and contributors, and I'm aiming to increase my regular commitments to helping with docs and other non-dev tasks to half a day per week in 2017.
Node JS would be on it
It's a remote backup tool that solved all the problems. It's basically duplicity[2] but without the unfortunate design fault of having to re-upload all your data every few months.
Our[3] customers love it and we see new deployments of it (even among existing customers) every single day.
[1] https://borgbackup.readthedocs.io/en/stable/
[2] http://duplicity.nongnu.org/
[3] http://www.rsync.net/products/attic.html
I sometimes tell myself I should spend less time browsing HN comments but then I find little nuggets like this that really make it worthwhile.
VS Code became my primary code/Markdown editor in 2016. It improves steadily each month [1] and already has a great extension ecosystem and community. It also spurred my switch to Markdown for all note-taking due to its powerful integrated Markdown features.
Thank you to the VS Code team and Microsoft for sponsoring the project.
[1] https://code.visualstudio.com/updates
https://webpack.github.io/
[0] https://twitter.com/bugant
[1] https://twitter.com/dalpo
[2] http://www.tomato.es
[3] https://backerpass.com/tomatoes
[1] https://mobxjs.github.io/mobx/index.html
[1] https://preactjs.com/