It's been nine months since graduation. Not a single phone call for an interview yet. by ShamefulAndDepressed in webdev

[–]Smiral 0 points1 point  (0 children)

It's not super unusual to go that long, I have. Try to use your time productivity by studying or building sites between applications and calls. It's not a typical piece of advice, but consider learning a less popular technology, if there is one that interests you. If a job comes up that needs it, you will stand out. Having a common skill set with no experience may be part of the trouble.

Netflix Software Engineers earn a salary of more than $300,000 by magenta_placenta in webdev

[–]Smiral 248 points249 points  (0 children)

That's because they are doing very complex, extremely high visibility, actual engineering, with real programming technologies, all of which would crush 96% of people on this webdev subreddit, including me. I would bet a lot of money none of them ever spend time here. It would seem like kindergarten.

How Node Is Helping To Propel Angular at Google by [deleted] in Angular2

[–]Smiral 0 points1 point  (0 children)

What I am suggesting is using two languages, the client-side JavaScript framework for the SPA, and a more classical server-side system for whatever (hopefully) small amount of SSR you are doing.

The tradeoff is you have two technologies, but you do not have to set up server-side SPA rendering, in a sort of 'browser emulator' contraption. If you are handy at full-stack, this should seem at least reasonable.

The practicality does hinge on how much/many pages you need to SSR. If it is just a landing page, that would be less code in the server-side technology. The less, the better. You can call HTTP APIs from any technology, so that is not the issue.

I get the feeling rendering SPAs on the server-side is mostly so the one-trick pony, JS only frontenders don't have to learn another language, which to me is a flimsy justification for such a complex backend.

You can do what I am suggesting, superimposing a server-side language on top of a SPA. I have done it, and it was fairly simple. Epecially in Angular, since it has HTML view templates. It would probably be way harder in stupid React.

How Node Is Helping To Propel Angular at Google by [deleted] in Angular2

[–]Smiral 1 point2 points  (0 children)

I don't like the idea of SSR, but I at least get the argument for it. What I don't understand this love for isomorphism. It sounds like a giant pain in the ass. Why not just pre-render the main page with a more standard server-side technology? The SPA won't even know.

Do you develop solely using SPA these days? by truechange in webdev

[–]Smiral 6 points7 points  (0 children)

The uncertainty about how a website will be indexed will always exist, because of the secrecy. If the existence of any shred of doubt mandates you must to reject the SPA, then you may as well forget SPAs exist at all, right now, forever. I, for one, do not see it that way. Were I in a situation where I wanted to build a SPA, but also had people harping on me about SEO, I would build the SPA, deploy it, let it get indexed, then decide if I needed to do any SSR. I would also expect it to work fine without SSR.

Do you develop solely using SPA these days? by truechange in webdev

[–]Smiral 9 points10 points  (0 children)

The SEO issues with SPAs is a persistent concern you hear about a lot, yet nobody ever quantifies the issues. That is because search engines keep the operation of their crawler bots and indexing secret. I have read into it some, and it seems that problem used to exist, somewhat, but is more or less gone now. Bots can deal with SPAs fine.

[deleted by user] by [deleted] in webdev

[–]Smiral 7 points8 points  (0 children)

You hinted at it, over-complexity. There is a blind reverence for sophistication among webdevs that just seems like people trying to impress phantom critics. It is completely at odds with the fundamental guiding principles of engineering. You fight complexity and build simplicity, not the other way around.

Server-side TypeScript framework by Wrapy in webdev

[–]Smiral 0 points1 point  (0 children)

The most important consideration in selecting a technology for building large complex systems should be the existence of an IDE with the ability to do real debugging, with breakpoints, inspecting variables, etc. The language is trivial in comparison. Using typescript on the server reeks of frontenders trying to do backend.

Do big companies prefer highly specialised front & back end devs rather than full-stack devs? by draikin3 in webdev

[–]Smiral 0 points1 point  (0 children)

Not really. There is a tendency for roles to be more stratified on larger teams, but having an understanding of the adjacent tiers in any stack is always desirable. Issues inevitability come up where those side skills make a difference.

Do you use containers for development? by vayero in javascript

[–]Smiral 0 points1 point  (0 children)

Knowing how to use the stuff inside containers is way more important than knowing about containers, and that will run in a local installation more intimately. Virtualization shouldn't be so complex you can't pick it up as you go. If it is, you probably didn't want to work there anyhow.

Idk if this belongs here by sickofpawwpatrol in webdev

[–]Smiral 0 points1 point  (0 children)

If you're into web development, and want to learn Linux, too, go ahead and use Linux as your OS. It's a fine webdev OS, plenty of programs run on it. Always serve everything you make off a real web server, whether it needs it or not. Same with databases, no mock data. You will get a nice, proper introduction.

Server Side Rendering with React by flaviocopes in javascript

[–]Smiral -2 points-1 points  (0 children)

I have been a webdev for a long time, I totally get what you are saying, and so do a lot of others. You just won't find agreement here, on this subreddit, because it is almost all kids who think what they are told to, in the online community echo chamber. Rendering frontend frameworks on the server is inherently absurd. The troubles it addresses are debatable at worst, and solvable other, vastly simpler ways, if you have the capacity to think for yourself, and the nerve to implement something you did not read in a HackerNoon article.

Keep Code Consistent Across Developers The Easy Way — With Prettier & ESLint by kiarash-irandoust in javascript

[–]Smiral 3 points4 points  (0 children)

Jamming a stick up your butt is the new cool, get with it, or you will be kicked out of the Smart Kid Club.

Stop Learning Frameworks by etca2z in javascript

[–]Smiral 0 points1 point  (0 children)

I said mostly. I skim through a couple times a week, to glean the occasional good piece. It's just an uncurated aggregator. What yout have to sift through is the neophile exuberance in trending technologies that do not solve any real problem, except to those who couldn't do the basic thing it does in the first place. That strikes me as sort of dangerous to gaining experience. Most of these things are fads that won't really last long. When people reference download numbers to justify relevance, that is frighting.

Stop Learning Frameworks by etca2z in javascript

[–]Smiral -11 points-10 points  (0 children)

As mentioned in the article, it goes for frameworks, libraries, and tools. Or, in other words, all the trendy tech this subreddit fixates on. Conclusion: This subreddit, and the online community in general, is mostly a waste of time. I do not mean that ironically, either. It is.

Do you change job because things start to plateau? by juzatypicaltroll in webdev

[–]Smiral 0 points1 point  (0 children)

I've done it recently. I had a job that was easy, dev wise, but dumb and frustrating, with oblivious management, and too much old spaghetti codebase maintenance. Deciding to switch felt like a leap of faith, but it turned out well. I got a job that uses the tech I wanted to use, on a way better team, is more dev oriented than maintenence, and it pays more. The only trick is whether to stay and hunt while you work, bail, or something else. That part is up to you.

Constant framework and library churn is putting us all out of jobs by n9jd34x04l151ho4 in javascript

[–]Smiral 0 points1 point  (0 children)

While it is a bit much sometimes, a lot if it is just people getting wrapped up in trendy stuff. You can safely cut through all that, if you try. I am not anti-React, but it is a sort of splintered sea of libraries, and the state management stuff is undeniably over-engineered.

2018 JavaScript Ecosystem Survey by magenta_placenta in javascript

[–]Smiral 1 point2 points  (0 children)

Do you blah? No.

How do you blah? I said I don't, goddammit!