You didn't mention the techs you used (e.g. WinForms, WPF, UWP). HTML/CSS is nothing really like WinForms dev. It has some similarity to the other two but I honestly find web more flexible to layout and style.
Probably the first thing is to forget the constraints you are used to facing. For instance WPF only allows you to apply 1 style. WinForms, styles are hierarchies of data objects that you have to set properties on to apply styles. The web doesn't work in either of these ways. (You can set properties in javascript to apply a limited set of styles, but it is not as common.)
Desktop apps are commonly a mix between front-end and back-end concerns. If you haven't already been developing this way, you have to start separating those two concerns mentally. Because browser-based apps are basically untrusted code (anyone can hit F12 and modify the code, or send their own requests off), only the server-side is allowed to access files, query the database, etc. The desktop equivalent would be to develop separate libraries responsible for business logic, infrastructure, etc. But basically those libraries move to the server-side, and what remains on the front are UI manipulations and collecting user data necessary to interact with the back-end.
Browser-based front-ends are all the rage right now. But there is still a very popular class of server-side tech that is a mixture of front-end and back-end. The general formula is rendering templated HTML/CSS on the server side, with controllers to execute business workflows, access databases, etc. Examples: Ruby/Rails, ASP.NET MVC/Razor, Python/Django, PHP/Laravel.
Going the browser-based route, you might want to specialize in either front-end or back-end at first. Back-end means setting up things like web APIs, executing business use case workflows, integrating with database, email, etc., serializing and deserializing responses and requests, and so on. Nothing much to do with HTML/CSS. Javascript (via Node.js), Ruby, C#, Go, etc. (pretty much anything) could be used for back-end services. Just search for web api with your chosen language. They each have their own hosting/routing libraries to pickup.
If you want to specialize and UI is your thing, feel free to dive into HTML/CSS. It might be a good idea to use a CSS framework to get you going. Examples: the ubiquitous Bootstrap or my favorite Semantic UI. These come with pre-built CSS classes which you can apply to HTML to make many common controls. They have good documentation with a lot of examples. In the desktop world, these would be similar (but not quite as heavy as) using Telerik or DevExpress control toolkits. Then as you learn more about CSS, you can venture into customizing the pre-built styles. And if you find you really like it you can venture into scratch-built layouts. I still use CSS frameworks for business apps... it's just a lot quicker to get up and going.
The HTML and CSS are just the presentation part of the UI. The only game in town for programmatically controlling these is JavaScript (or something that compiles to it). There are utterly ridiculous numbers of JS-based technologies. For me, the right one currently is Elm. But popular component-based UI frameworks are Vue, React, Angular. They each have their own learning track and opinionated abstractions to commit to memory. (Elm does not make you learn very many non-portable things.) My advice is pick one and learn it. No matter what you pick, it will invariably get voted out of popularity in a year, so don't dwell on longevity too much. Whichever you pick, use a starter app like Create ??? App. Where the ??? is Elm, Vue, React, Angular, etc. That will get you jump-started with a working, deployable app. And you can dive deeper as needed from there.
Edit: If you're looking for databinding though (something the Telerik / DevExpress controls do), you won't find it. That's left up to the language or framework you are using. I much prefer to handle this anyway rather than spending a lot of time trying to figure out the right data binding expressions to accomplish exactly what I want to do. It is pretty straightforward in Elm, for instance.
-- in UpdateSearchSubmitted->{model|results=Loading}![Api.searchmodel.apiConfig{search=model.search,page=model.page,pageSize=model.pageSize}]SearchReturned(Errerr)->{model|results=LoadFailederr}![]SearchReturned(Okok)->{model|results=Loadedok}![]-- in viewviewmodel=-- semantic celled tabletable[class"ui celled table"][thead[][...]-- header stuff,tbody[](casemodel.resultofLoading->-- display a spinner or loading messageLoadFailederr->-- display an error message, could be elsewhereLoadeddata->-- toRow: fn to convert data to table rowList.maptoRowdata),tfoot[][...]-- pager stuff]
Born and raised in Montana. I love drawing and technology. I lost my job in home construction due to the economic downturn. It was then that I realized I loved to code.
tons of great information here. thank you very much for it. the idea in my head was the employer would choose the tech, I would get an entry level position, and then learn. I fear I am wrong.
I believe that experience is worth a lot more than just the frameworks you used to get it. Sure, your knowledge might be mostly entwined with WebForms or WPF or something. But you probably still had to do the core bits common to every developer. You wrote decision logic and you integrated with external systems. (External meaning: database, file, email, web requests, etc.) IMO, UI frameworks are external systems too. :)
It feels like a tremendous loss of experience to move to a different set of tools, but the core experience that makes a developer is still underneath all that.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You didn't mention the techs you used (e.g. WinForms, WPF, UWP). HTML/CSS is nothing really like WinForms dev. It has some similarity to the other two but I honestly find web more flexible to layout and style.
Probably the first thing is to forget the constraints you are used to facing. For instance WPF only allows you to apply 1 style. WinForms, styles are hierarchies of data objects that you have to set properties on to apply styles. The web doesn't work in either of these ways. (You can set properties in javascript to apply a limited set of styles, but it is not as common.)
Desktop apps are commonly a mix between front-end and back-end concerns. If you haven't already been developing this way, you have to start separating those two concerns mentally. Because browser-based apps are basically untrusted code (anyone can hit F12 and modify the code, or send their own requests off), only the server-side is allowed to access files, query the database, etc. The desktop equivalent would be to develop separate libraries responsible for business logic, infrastructure, etc. But basically those libraries move to the server-side, and what remains on the front are UI manipulations and collecting user data necessary to interact with the back-end.
Going the browser-based route, you might want to specialize in either front-end or back-end at first. Back-end means setting up things like web APIs, executing business use case workflows, integrating with database, email, etc., serializing and deserializing responses and requests, and so on. Nothing much to do with HTML/CSS. Javascript (via Node.js), Ruby, C#, Go, etc. (pretty much anything) could be used for back-end services. Just search for web api with your chosen language. They each have their own hosting/routing libraries to pickup.
If you want to specialize and UI is your thing, feel free to dive into HTML/CSS. It might be a good idea to use a CSS framework to get you going. Examples: the ubiquitous Bootstrap or my favorite Semantic UI. These come with pre-built CSS classes which you can apply to HTML to make many common controls. They have good documentation with a lot of examples. In the desktop world, these would be similar (but not quite as heavy as) using Telerik or DevExpress control toolkits. Then as you learn more about CSS, you can venture into customizing the pre-built styles. And if you find you really like it you can venture into scratch-built layouts. I still use CSS frameworks for business apps... it's just a lot quicker to get up and going.
The HTML and CSS are just the presentation part of the UI. The only game in town for programmatically controlling these is JavaScript (or something that compiles to it). There are utterly ridiculous numbers of JS-based technologies. For me, the right one currently is Elm. But popular component-based UI frameworks are Vue, React, Angular. They each have their own learning track and opinionated abstractions to commit to memory. (Elm does not make you learn very many non-portable things.) My advice is pick one and learn it. No matter what you pick, it will invariably get voted out of popularity in a year, so don't dwell on longevity too much. Whichever you pick, use a starter app like Create ??? App. Where the ??? is Elm, Vue, React, Angular, etc. That will get you jump-started with a working, deployable app. And you can dive deeper as needed from there.
Didn't know about Semantic UI, thanks :D
Exceptionally good quality and variety of controls there. Even the CSS-only distribution, which is what I use.
How are they doing in the department of "table with server side pagination" ?
It's like the great classic for admin applications :D
Pretty good on that front, as far as the UI elements.
semantic-ui.com/collections/table....
Edit: If you're looking for databinding though (something the Telerik / DevExpress controls do), you won't find it. That's left up to the language or framework you are using. I much prefer to handle this anyway rather than spending a lot of time trying to figure out the right data binding expressions to accomplish exactly what I want to do. It is pretty straightforward in Elm, for instance.
Thanks for the explanation. I'm using Bulma through buefy right now in a Vue app but I'm not 100% satisfied. Semantic UI's approach is interesting.
tons of great information here. thank you very much for it. the idea in my head was the employer would choose the tech, I would get an entry level position, and then learn. I fear I am wrong.
I believe that experience is worth a lot more than just the frameworks you used to get it. Sure, your knowledge might be mostly entwined with WebForms or WPF or something. But you probably still had to do the core bits common to every developer. You wrote decision logic and you integrated with external systems. (External meaning: database, file, email, web requests, etc.) IMO, UI frameworks are external systems too. :)
It feels like a tremendous loss of experience to move to a different set of tools, but the core experience that makes a developer is still underneath all that.