- nuxt (or next if you prefer react)
- tailwind (atomic css)
- node
- express
- passport (Use cookie based auth keeping the session in your storage. I wouldn’t waste time on JWT. There’s a decent amount of complexity if you want both the security of being able to revoke access to a bad actor and the convenience of long lived sessions, and at the end the auth server will most likely need to access storage and use cookies for that anyway (eliminating the benefits of JWT). So I’d start with cookie based auth and build up complexity as needed.)
- postgres
- On the Node side, I don’t recommend adding the complexity of an ORM at first (or ever). The node pg driver will give you arrays of objects back for rows. It’s convenient enough not to need the extra overhead of an ORM.
- As a side note, Postgres has modules for you to implement a decent first version of a lot of things, such as search for example, before you need to reach for a dedicated solution. This makes it amazing for startups in my opinion, as you can explore ideas very quickly.
- statsd / grafana (to monitor your app and learn from the behavior of your users)
- docker-colpose.yml to make spinning up your dev environment with node / db / stats as simple as “docker-compose up”
- DigitalOcean for hosting
- Use their dokku image
- Set up daily backups to Spaces since your DB will be hosted here at first too
- dokku for deployment with the Postgres, letsencrypt and grafana modules
- deployments are as easy as “git push master dokku”
No surprises here this year: es6 & typescript, react & vue. I think I’d put redux and graphql in different categories as they’re not mutually exclusive. Nevertheless, I’m happy to see excitement for the latter.
I follow the check-in model from Adobe [1]. It isn’t a hard set of requirements, but is more of a set of topics that help guide the conversation. It’s especially helpful as a starting point for people new to management, like myself.
A check-in meeting is made up of three parts: (1) setting expectations, (2) providing feedback, (3) having a development conversation.
Status reports are explicitly not a part of this conversation. Those are easy to talk about, but have little value for your employee, and if you’re already doing daily stand-ups, they have little value for you too.
The first two topics are fairly self-explanatory, yet take time to learn to do well. The expectations must be clear, finite and actionable. Much has been written about the art and science of giving good feedback. I use a model where we talk about the Specific thing that happened, followed by Asking questions to understand their perspective, talking about the Impact of their actions on themselves and the people they have affected, and finally talking about what I expect them to Do now or in the future. (aka SAID)
The development conversation is the time for you to listen. This is where you learn about the professional skills they are working on growing (whether it’s public speaking, a particular career path or, say, a machine learning course, to name a few) and finding ways to help and facilitate those. If done right, you learn a lot about the person, their goals, aspirations, and will be in a better position to make a positive meaningful impact on their life.
The check-in is most effective if it’s guided by the employee. This encourages people to come with topics they care about and gives them the ability to focus more time on a particular aspect of the meeting which may be more important at that time.
I think it's a beautiful, thought out, polished and well built set of UI components. If that's what I needed for my next project, I wouldn't hesitate to use it. The docs are excellent too. There's so much attention to detail here. There's an immense amount of love poured into this project, even the code snippets are interactive.
The title of this submission is a bit misleading. This script parses the .vue file and extracts the three sections into x-template script, Vue.component script and a style. These are not standalone in the sense that they cannot exist without vue and vue-template on the page (the later is large and unnecessary when compiling with webpack). Essentially this does what the vue webpack plugin does naïvely and without many of the features like support for different template / JS / style language compilation (e.g. Babel and sass).
Gosh,there is so much half assed redundancy in js world that no wonder that so many beginners feel lost.
This does seem a bit too experimental to actually be useful.
Some vue based projects are actually nice and easy for beginners to be productive (like Nuxt), but the whole vue ecosystem has never clicked with me even after I toyed with it for at least 2 or 3 times.
> Gosh,there is so much half assed redundancy in js world that no wonder that so many beginners feel lost.
Beginners feel lost because the JavaScript world has learned nothing from Java's ant. These insane build/asset pipelines that take forever to run are the bane of the JS world.
It's like nobody remembers you can just write a JavaScript,then link it to an HTML without 35 compilation steps.
We are no longer just trying to toggle a modal or show a popup.
The requirement for frontend has changed dramatically and now we need to handle entire UI flow, interactivity, data synchronization, and even some business logic like filtering and validations with JS, HTML and CSS.
There's no web app for air traffic controller yet, but pretty much everything else has a web app with a huge set of feature and non-feature requirements.
> We are no longer just trying to toggle a modal or show a popup.
> The requirement for frontend has changed dramatically and now we need to handle entire UI flow, interactivity, data synchronization, and even some business logic like filtering and validations with JS, HTML and CSS.
What does it have to do with using Babel/Webpack and what not? it hasn't.
The DOM is plenty and enough to implement MVC on top of it without requiring 200 libraries from NPM. Developers have been writing complex GUI apps for more than 4 decades without the need for a specific framework, how did they manage to do so yet everybody needs some complex framework in the browser? no they don't. Most of these web apps are forms.
Now I'm not saying don't use react and whatever pipeline you are using. But downloading node and all these stuff isn't what a beginner should be exposed to. Beginners should learn basic principles of front-end development which includes the DOM.
> Do you think an app like Photoshop or 3DSMax uses a react like framework on top of whatever C++ GUI they are using?
Yes I think so. Why else would they require 1GB of space to install them and specific hardware to run them efficiently? As a matter of fact, they require rendering libraries from graphics card companies. The difference is that they use their own proprietary frameworks instead of open sourcing them.
> How many apps can boast about being as complex on the web? most of these web apps are forms.
Not a lot, but quite significant nontheless. For example google docs, office 365, Facebook, Amazon, and many cloud solutions for enterprise. I agree most of web apps out there are just fancy forms and don't really need any frameworks, but there are legitimate use cases for them.
Edit for your updated comment:
Yes, I fully agree that web developers should start from basics, not frameworks and libraries. Cheers.
I'm literally in charge of a team of 3 devs that does that. React complicated our stack, slowed things down both development wise and in terms of inefficient asset management, so we reverted to vanilla JS and never looked back.
What kind of app is it? Is it an SPA or a mostly-HTML website with some bells and whistles?
I've been through the whole gamut -- pure JS, jQuery, Backbone, Angular1, and React. I love React because it's by far the most pleasant experience for my work. You would not get me to go back to pure JS over pain of death, it's just a non-starter for the types of apps we're building.
> As a matter of fact, they require rendering libraries from graphics card companies.
in order to render graphics. The DOM already gives you all that for free.
> For example google docs, office 365, Facebook, Amazon, and many cloud solutions for enterprise
Not even VSCode uses a specific framework, which demonstrate my point. Yes, they use Monaco editor for their text editor but this is a very specific library for a specific purpose, this isn't a generic view framework like react and co.
> Not even VSCode uses a specific framework, which demonstrate my point. Yes, they use Monaco editor for their text editor but this is a very specific library for a specific purpose, this isn't a generic view framework like react and co.
I think your argument is a bit flawed here. They don't use a generic framework for VSCode not because they don't need a framework, but probably because a generic framework is not good enough for handle the complexity on their level that they need to invent their own framework.
So, my point is:
Simple app, fancy forms: No framework should be required, just use VanillaJS, jQuery, or d3.js.
More complex apps that solves a generic problem (CRUD with heavy client side interactivity): Generic framework.
Extremely complex and specialized apps: Write your own framework.
The infuriating thing about React is that, by itself, it has a very high power to complexity ratio. By far the best out of any of the big front-end tools. But for some reason the community absolutely insists on piling 10 tonnes of crap on top of it until it covers every use case under the sun and no single app is using more than 5% of the rubbish they pull in from NPM.
I agree we can do much simpler. That's why I'm building some conventions to load vue components asynchronally (with each part - html, js and css - separated).
This is why despite trying Vue first and liking it, after learning React, I would always use it in the future.
Vue really requires you invest in its ecosystem a lot more to structure your entire frontend (and Nuxt even more so), whereas React feels and operates much more strictly as a JS library.
The basic benefit of Vue is that it comes with much of the React boilerplate already abstracted away behind syntactic sugar. But once you learn to do that yourself with React, it's no slower to start building. It just takes a longer learning curve to get to that point.
After using each in production for about two years I came to the opposite conclusion.
For me the React experience includes tons of bikeshedding over which accessories (routing, state management, etc) to pair it with and how to wire those up.
The Vue experience started simple and scaled up nicely as we reached the point that we needed more stuff, since there’s an official library for basically everything and it all works very nicely together.
It’s pretty subjective I guess but interesting how different development experiences can be.
> For me the React experience includes tons of bikeshedding over which accessories (routing, state management, etc) to pair it with and how to wire those up.
This is React's biggest strength IMO, that it doesn't handle routing, state, etc. It just makes your UI a function of state. How an app needs to manage state can vary wildly, but it's all the same to React.
> This does seem a bit too experimental to actually be useful
I use it for 3 years ...
I've just updated it, to make css scopable, and decided to release it to the public.
I've got a "big app", with more thant 50 components, with vuetify, vue-router & vuex, 2 websockets and a lot of fetch ... it works as expected (btw I've never used vue-cli/nodejs/webpack with them ;-)
I'm in the opposite boat. I don't care to learn all the "magic" cli tools that frontend frameworks provide. This looks great to me, even if it does little.
One thing that caught my attention is Julia’s value of work / life balance and the humanization (if that’s the right word) of programming. She very deliberately didn’t work on this in her spare time (underlining that coding isn’t the only important thing in her life) and when she did build the prototype she explicitly wanted to do it at a weekend coders retreat with other “wonderful” people around (as opposed to secluding oneself in a room and coming out of it with a solution).
Same here. I had to do a double take when she mentioned that. She is a pretty accomplished individual and I always assumed that a lot of her personal time was taken up doing programming related activities. Now I know you don't necessarily need to sacrifice all your personal time to become HN famous.
I'm glad she mentioned that too, sometimes it feels like there's cultural pressure thag if you aren't hacking in every non-work hour then you're a slacker…
It’s possible and is what Charles and MITM proxies do. Specifically, Charles generates its own certificates for sites, which it signs using a Charles Root Certificate. So the clients of this proxy would accept the proxy’s CA and continue as usual. This of course does make browsing less secure, as a compromised proxy negates the security of https of all of the proxied websites. A slightly more secure but less efficient caching solution is to install the proxy locally, but then, of course, the cache isn’t shared.
Can local certificates not be restricted to the few domains you want cached, so that the user can be sure their browser isn't using the local proxy's certificate for anything other than the sites approved on the certificate (like Wikipedia)? I would've thought this is possible, but if not, I feel like browsers should implement the ability to restrict local certificates to specific sites. It shouldn't be hard. They'd obviously have to still upgrade their browsers but then they wouldn't have to twiddle their thumbs waiting for every website to implement its own service workers (or not end up doing so).
Yes, come to think of it, that’s possible either manually or with a PAC file. It seems like a decent compromise too to whitelist the proxied sites the weakened security of which you are willing to tolerate, at least in the case where the alternative is not being able to teach/learn in that area, as in Eric’s case.
- node - express - passport (Use cookie based auth keeping the session in your storage. I wouldn’t waste time on JWT. There’s a decent amount of complexity if you want both the security of being able to revoke access to a bad actor and the convenience of long lived sessions, and at the end the auth server will most likely need to access storage and use cookies for that anyway (eliminating the benefits of JWT). So I’d start with cookie based auth and build up complexity as needed.)
- postgres - On the Node side, I don’t recommend adding the complexity of an ORM at first (or ever). The node pg driver will give you arrays of objects back for rows. It’s convenient enough not to need the extra overhead of an ORM. - As a side note, Postgres has modules for you to implement a decent first version of a lot of things, such as search for example, before you need to reach for a dedicated solution. This makes it amazing for startups in my opinion, as you can explore ideas very quickly.
- statsd / grafana (to monitor your app and learn from the behavior of your users)
- docker-colpose.yml to make spinning up your dev environment with node / db / stats as simple as “docker-compose up”
- DigitalOcean for hosting - Use their dokku image - Set up daily backups to Spaces since your DB will be hosted here at first too
- dokku for deployment with the Postgres, letsencrypt and grafana modules - deployments are as easy as “git push master dokku”