mottomotto's comments

I think it's only a red flag if you don't want to work remotely. I've been doing it for about 1.5 years straight now with a 6 month stint in the past a couple years ago. With a wife and young kids, it's great. I can have lunch with them. I don't have to deal with as much office politics. My employer keeps us fairly well informed about the health of the startup.

Are there pain points? Yes, communication can be difficult and the transition can be difficult for managers. People seem to really vary in their ability to comprehend how async communication can work (as in, what needs to be a group announcement on a call versus just an update in Slack or email).

So I personally wouldn't see the change as a red flag. Having had my current experience, I would be delighted and would be considering where to move to maximize taking advantage of being remote. But it really is a "your experience may vary" based on what you're looking for.

I think it requires a different mindset in that with programming, I can, for many tasks but not all, kind of get in the zone and crank things out. But (for me) design is not like that. It's more experimental, a bit slower paced, requires a lot of subjective decisions and iterations. And sometimes the changes are very minor -- it's no code refactoring typically. But a number of small changes can have a big impact (just like code in a way). I think part of the problem is the decision tree is very big and the subjectivity makes it easy to go down the wrong path. So it's easy to dismiss it as too hard and settle for subpar.

I think all of that is fine as long as you pick it up again another day and keep on trying to make it better. I was all set to hire a designer to help with my most recent side project but I wanted to tidy it up a bit first and I ended up really happy with my changes and decided not to go with a designer.

So I think it is about effort and being willing to approach it as something different that takes time and relaxed effort to improve at.

As a side note, I'd recommend not studying (or accepting as ideal) designers output before evaluating it critically. A lot seem fixated still on print and ship static screens that often overlook user experience (or don't convey it at all). When I see things like more than 3 to 4 different font sizes on a web page design, I start to suspect the designer is more print-orientated. Obviously this is subjective and I'm talking about an initial design. Sometimes such a variety of font sizes is required but I wouldn't expect that early on. The hint here is that simplicity is incredibly powerful in design and it is more accessible to beginners so even if you think 10 font sizes on a page is fine, you might not want to go that path as a beginner.

If you need or will need a web equivalent, you should look into react-native-web (and just for interest, react-native-dom but that is much more expiremental -- I'd stick with -web for actual usage). With react-native-web, you can have one code base that serves both the mobile devices and web. It takes a little bit of getting used to but I'm using it on two projects and it's really powerful.

React Native is far from dead. I suspect your conflating "React Native isn't good for Airbnb" with "React Native is dead". The reality is Airbnb already had mobile applications. They wanted to use React Native to potentially accelerate their application development. However, after a couple of years, they still had a hybrid application with both purely native screens and a some React Native screens. I think the number was roughly 200 out of 800 screens? Anyway, point is if you're in the same situation as Airbnb, yes, React Native as it stands right now might not be the ideal for making a hybrid application.

If you're not in Airbnb's shoes, React Native may be a completely viable way to build your applications. One hint is that hybrid is harder than it seems. That is is more than just a technical problem. I'm going to avoid rehashing the Airbnb articles but you can read them to get a sense of the pain points. To continue the hint though, it's worth looking at those for whom React Native is working. I've noticed most seem to be greenfield applications developed from the start in React Native.

I really hesitated to reply on this but I'm about 15+ years into my career and what the heck. On the one hand, I agree with you. On the other hand, I really disagree. The reason I disagree is we spend an immense amount of time every day working for money. Sure, many of us love what we do but we still go to work at a certain time and certain days because we have to by our agreement to get a paycheck.

So my goal is that I'm writing my own paychecks. By gaining FI, that might mean I'm just going to pay myself to watch TV and play videogames all day. Or go spend time traveling Japan and visiting all the Onsens/hot baths. Or spending time with my kids and working on my own businesses -- trying to bootstrap new ideas and just seeing what works and what doesn't (which includes working on interesting projects).

So the part of me that disagrees with you is the part that sees just how much of our life, how much of every single week day, is dedicated to one thing. And that one thing is not something I live for. I want to work on things I live for and fully believe in.

Does that make sense? I don't want to be harsh but on the surface, startups seem so awesome. Everyone is aligned and motivated along the same angles. But the reality is often much worse than one might expect. The investors are pushing the lead developer, who has health problems caused by stress, to use the new framework of the day. The cofounders are trying to figure out which management to hire. The managers are coming in and deciding to change the whole culture and bring in their people to do things their way. It just goes on and on. And nobody is really aligned in the end. There is that magic when it works but most of the time it doesn't. And it's disappointing to spend your life on things that don't ship, that fail, that aren't interesting to work on.

My goal is to live the life I want to live knowing that what I want will change over time. My biggest drive right now is to gain financial independence through both lowering my cost of living, a high savings rate and continuing to grow my income. I work full time as a software developer but have also started a business on the side with a partner. That is part of my strategy of increasing income. Recently, I've realized that business, while bootstrap profitable, is not going to grow as fast as I want so I am going to start another business (and I expect this cycle will continue until I reach FI -- it may continue beyond that as it is fun).

So my goal is overall happiness with financial independence being a key part of it. I should note that I do not strive to be excessively frugal -- just cut where it doesn't impact myself or my partner. I've also elected to have children and I think that contributes positively to my overall happiness although it can be expensive and they can take a lot of time (so I think that is very much an individual choice).

No, just find a company that is into Software Craftsmanship and sign up for an apprenticeship. There are a lot out there although you might need to move to a major city if you're not in one yet (ie Chicago, New York, LA, London, etc). Just look for the meetups and the sponsoring companies and you can take it from there.

Difference from a bootcamp: you don't pay them, typically they pay you and provide benefits but it varies. Typically leads to a job offer if everything works out well. Discuss expectations going in and timeline.

I missed you were in Turkey -- a quick Google search with "turkey software craftsmanship" reveals some options there that may or may not be active.

It is not the kind of caching that the post I'm replying to is advocating ("the entire app can live offline and even cache data in local storage"). I mentioned the caching I am doing to point out things aren't so simple. I do mean quite literally that none of my API HTTP responses have a caching header (assets are coming from CDN with very long cache life).

It might be more fruitful to try to explain why I go against that instead of simply saying I do without a rational argument that can be responded to. If anything, the thread pretty clearly revealed someone is extremely biased to server-side web frameworks and is unaware of the progression of client-side web APIs.

That really is dependent on use case though. In my current project, I want the most up to date data possible so no caching. In reality, it is cached locally in the browser state and soon, I will be pushing data to update that browser state (based on other users activity in the same tenancy).

I think generalizing to "we should be building progressive web apps" is harmful. You should do what is appropriate for your use case.

I haven't written this functionality in, it's a browser API:

https://developer.mozilla.org/en-US/docs/Web/API/History_API

https://html.spec.whatwg.org/multipage/history.html#history

None of these arguments are for a specific stack. React has little to do with any of this. We're talking about underlying technologies that enable the web to be used as a platform for application development.

My point about an ORM is that your API becomes so simple you don't require a lot of complexity that is required with server-side joins of data in order to render a view. That is gone. No need. I'm giving you examples assuming you can extrapolate them to a bigger picture.

NATS is another option but I think your requirements would lead you to NATS Streaming:

https://nats.io/documentation/streaming/nats-streaming-intro...

It doesn't offer compression as far as I know (the FAQ suggests though that one is free of course to do compression/decompression above NATS).

It's not an ugly hack at all. It works well, the browser history works properly and the interaction is just as if the pages were being fetched from the server. At any point in time, the user can do a hard reload and the page will rerender as it did before. The URLs are the same as if I was doing server-side rendering.

So I would ask you at this point to turn this all around. Look at it from my perspective. I've been doing fullstack for more than a decade (professionally, hobbyist for twice as long) so I've done plenty of server-side rendering in frameworks like Ruby on Rails, ASP.net MVC, etc. I've contributed (as lead) to open source gems that have over 800k downloads. So I have invested a lot of time into the server-side.

But today, with client-side, there is a huge simplicity factor. You can only get to it after wading through the turbulent waters of "flavor of the week" client-side projects and noise. But when you do get through that and identify your pillars to build on, this is what you have:

* all of your complexity is on the client-side for web

* you can make a simple fairly clean REST or GraphQL backend that will work with multiple clients (web, mobile, etc)

* for at least REST, you no longer really need things like an ORM on the server-side as all of the endpoints are simple and basically fetching a single data type (I use SQL with PostgreSQL so I would say a table here but it depends on implementation)

* HTTP/2 reduces the cost of small requests so complex things like GraphQL aren't really necessary -- you can stay with REST without a penalty

Is there complexity? Is it different? Does it challenge the conceptions of those used to fullstack? Yes. But there is real value and simplicity here too that you might find if you're willing to put aside your hard and fast rules and try something new.

But I have zero use for SEO-friendly pages -- all my client-side pages are behind a login-wall. It isn't one big blob of JSON -- it's multiple endpoints. With HTTP/2, multiple small requests are fast.

> build the few dynamic elements on their pages with a simpler, more robust technology

This is a horrible idea that has worked poorly for so many projects. At one potential employer, they did this and their app had a message view with a read count. They didn't care the read count didn't update -- you had to reload the whole page for it to update. Those are the kind of inconsistencies that the above approach encourages because it's not cohesive.

Can you do it? Yes. Should you? No, not in my book.

> low latency, URL routing, progressive enhancement

I've got low latency, I have client-side URL routing, I have no need for progressive enhancement -- it's just more complexity that neither I nor my customers need. These are all great ideas if you have a public website and need to cater to a wide range of visitors. I don't. I'm very happy to be able to only have to support the last couple major versions of each browse.

Well that is a whole other debate. The best thing about React is common patterns. Second best is the availability of components. I've worked with JavaScript for a long time -- the Backbone.js days were painful. It was easy to accidentally leak event binds, code yourself into a corner, etc. The jQuery days were almost better in some ways but still had some real pain points.

You missed that I'm working on SaaS and a web application. Client-side state is important -- each of my customers can load up most of their state to client-side and the performance is great. This is the whole point of client-side apps. Get rid of all that round trip latency sending HTML to the client of every click. Get rid of your complex server-side framework. Client-side is simpler if you learn and embrace it (and don't need server-side rendering). It's also much easier to have a consistent UX with client-side state.

So use what is appropriate for you use case. For mine, that is 100% client-side no doubt. You can't beat the performance for an application.

If you're on the fence about server-side rendering being needed for your webapp don't do it! As a team of two with one engineer, I decided YAGNI and instead focused on the responsiveness of the React and Redux-based web application. It is very snappy to load and our (paying) customers are happy.

You might not need SSR. I don't. I expect there will be more work to optimize it and eventually it'll be obviously a good idea. But you don't need it right now if you're working on a SaaS product.

But the problem is if you assign a rotating duty to your engineering staff, you as an engineer have no direct impact on how often you will be called due to the half-assed work of other developers. It's a rocky road. Do this too much and your staff will leave. I certainly will. Life is too short.

In short, we're all describing poor management issues. Signing up all the developers for Pagerduty is band aid. So is pushing it all onto operations. In both cases, management is making a choice to avoid dealing with something that requires ongoing effort and time.

Chasing bugs? Yes. Being on-call? No. Not unless you signed up for that. Too many companies think they can just get Pagerduty going and sign up all their engineering staff for operations duty. This is stupid for a number of reasons least of which is managed services get rid of most of the need for this and it is typically cheaper than developer time.

Do some developers on the team need to think about scale? Yes. Should all the developers be on call because perhaps the company decided to roll it's own infrastructure and someone has to deal with occasional server with full disks? No.

My experience is the opposite. I work on front end but I focus on applications. There is a lot of change but it's exciting and browser-based applications are replacing native applications more and more.

I'm getting paid very well to do this work (much more than any blue collar worker in my area). It is challenging as there are always new things to learn but some pieces are falling into place and work well (ie React, Redux/well managed client-side state, etc).

I think this time is more exciting than any other for web application development. I think comparing software development jobs to blue collar is somewhat dishonest as it ignores the high compensation aspect -- if you tried having this discussion with an actual blue collar worker, I 100% expect you would learn some new things.

You sound burned out. This is what you should do:

* figure out what drew you into this work to begin with -- figure out a path to get back to that and focus on it

* stop paying attention to all the hype and buzz -- focus on what you care about, don't dwell on overly pessimistic articles (they get page clicks and there is always something new that threatens our income)

* focus on getting better at what you do

* make a long term plan to learn more about computer science topics that are useful to your long term goal -- this kind of knowledge doesn't churn as much

* write more code -- instead of reading doom and gloom, go write code

I suspect part of your issue is working for a smaller consultancy. Go work for someone for whom the web is a core part of their business -- it is best if it is their business. As in they are 100% reliant on it and you are contributing to their product which grows their company. Focus on finding a team with experience that you can learn from rather than a slightly higher salary.

It is silly to kick JavaScript in this example because the bug* is in the library of a custom JavaScript interpreter not a common runtime.

* https://github.com/code-dot-org/JS-Interpreter/pull/23

I much prefer putting the styles in a separate {componentName}.scss file, import'ing that into the component and using the Webpack Extract Text Plugin:

https://github.com/webpack-contrib/extract-text-webpack-plug...

I guess now you have two files per component but to me, it's well worth it.